Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@Julia.DE>
To: shaver@neon.ingenia.ca (Mike Shaver)
Cc: linux@cthulhu.engr.sgi.com
Subject: Re: MAP_AUTOGROW
Date: Fri, 20 Jun 1997 20:42:52 +0200 (MET DST)	[thread overview]
Message-ID: <199706201842.UAA31057@kernel.panic.julia.de> (raw)
In-Reply-To: <199706201817.OAA30967@neon.ingenia.ca> from "Mike Shaver" at Jun 20, 97 02:17:29 pm

> Thus spake Ralf Baechle:
> > > "Your" mkdep.c uses MAP_AUTOGROW, which doesn't appear in my Intel
> > > kernel sources.
> > > 
> > > This makes it kinda hard to xcompile. =)
> > > 
> > > I'm going to try just removing the reference, and see if it breaks anything.
> > 
> > Uhh...  That's an ugly hack which I added to make the things run on
> > IRIX and Solaris.  I knew that it has some problems ...
> 
> If I add something like:
> #ifndef MAP_AUTOGROW
> #define MAP_AUTOGROW 0
> #endif
> 
> to the file and commit it, will that work OK?

No, that's also an incorrect solution.  Let me explain the bug in mkdep.
When mkdep processes a file it does not read it into memory but it uses
open(2) and mmap(2) and then parses the file using a highly optimized
state machine.  When mkdep reaches the end of the file the state machine
may access some bytes beyond the mapped file.  Under normal circumstances
this makes no problems.  If however the excess bytes are on the next page
the mkdep will be sent a SIGBUS.

This only happens on systems where the mmap does strictly conform to
standards like IRIX or Solaris.  For Linux mkdep uses a little trick,
it tries to make more of the file than the file is long and Linux honors
that trick by not sending the signal for an attempted access to the
trailing bytes.  By my (very strict) interpretation of POSIX / XPG4 Linux
does the wrong thing and mkdep is based on this special Linux behaviour.

The way I glue this by using MAP_AUTOGROW is also broken ...

  Ralf

WARNING: multiple messages have this Message-ID (diff)
From: Ralf Baechle <ralf@Julia.DE>
To: Mike Shaver <shaver@neon.ingenia.ca>
Cc: linux@cthulhu.engr.sgi.com
Subject: Re: MAP_AUTOGROW
Date: Fri, 20 Jun 1997 20:42:52 +0200 (MET DST)	[thread overview]
Message-ID: <199706201842.UAA31057@kernel.panic.julia.de> (raw)
Message-ID: <19970620184252.4UPIJSDH4DJPyUkhmeQSR_MNcdIwWaV8JWYYczS8me0@z> (raw)
In-Reply-To: <199706201817.OAA30967@neon.ingenia.ca> from "Mike Shaver" at Jun 20, 97 02:17:29 pm

> Thus spake Ralf Baechle:
> > > "Your" mkdep.c uses MAP_AUTOGROW, which doesn't appear in my Intel
> > > kernel sources.
> > > 
> > > This makes it kinda hard to xcompile. =)
> > > 
> > > I'm going to try just removing the reference, and see if it breaks anything.
> > 
> > Uhh...  That's an ugly hack which I added to make the things run on
> > IRIX and Solaris.  I knew that it has some problems ...
> 
> If I add something like:
> #ifndef MAP_AUTOGROW
> #define MAP_AUTOGROW 0
> #endif
> 
> to the file and commit it, will that work OK?

No, that's also an incorrect solution.  Let me explain the bug in mkdep.
When mkdep processes a file it does not read it into memory but it uses
open(2) and mmap(2) and then parses the file using a highly optimized
state machine.  When mkdep reaches the end of the file the state machine
may access some bytes beyond the mapped file.  Under normal circumstances
this makes no problems.  If however the excess bytes are on the next page
the mkdep will be sent a SIGBUS.

This only happens on systems where the mmap does strictly conform to
standards like IRIX or Solaris.  For Linux mkdep uses a little trick,
it tries to make more of the file than the file is long and Linux honors
that trick by not sending the signal for an attempted access to the
trailing bytes.  By my (very strict) interpretation of POSIX / XPG4 Linux
does the wrong thing and mkdep is based on this special Linux behaviour.

The way I glue this by using MAP_AUTOGROW is also broken ...

  Ralf

       reply	other threads:[~1997-06-20 18:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <199706201817.OAA30967@neon.ingenia.ca>
1997-06-20 18:42 ` Ralf Baechle [this message]
1997-06-20 18:42   ` MAP_AUTOGROW Ralf Baechle
1997-06-24 16:38   ` Some simple hardware questions Alex deVries
1997-06-24 16:44     ` David S. Miller
1997-06-24 16:48       ` Bob Mende Pie
1997-06-24 16:54       ` Martin Knoblauch
1997-06-24 16:48     ` Bob Mende Pie
1997-06-24 16:48     ` Martin Knoblauch
1997-06-24 17:03     ` William J. Earl
1997-06-24 22:29     ` Miguel de Icaza
1997-06-24 23:05       ` Ralf Baechle
1997-06-24 23:02         ` Miguel de Icaza
1997-06-24 23:05         ` Ralf Baechle

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=199706201842.UAA31057@kernel.panic.julia.de \
    --to=ralf@julia.de \
    --cc=linux@cthulhu.engr.sgi.com \
    --cc=shaver@neon.ingenia.ca \
    /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