_IO_file_underflow_mmap read call for atime

_IO_file_underflow_mmap read call for atime

[Roland McGrath]

The POSIX rules for mmap on files require that mmap'ing and reading a page
set the atime.  I don't see how the rules for stdio affecting atime (via
the "underlying functions" clauses) could be violated by the libio mmap'd
buffer implementation if mmap behaves as specified.  So the read call in
_IO_file_underflow_mmap is unnecessary.  Am I missing something?

Re: _IO_file_underflow_mmap read call for atime

[Ulrich Drepper]

Roland McGrath wrote:
> The POSIX rules for mmap on files require that mmap'ing and reading a page
> set the atime.  I don't see how the rules for stdio affecting atime (via
> the "underlying functions" clauses) could be violated by the libio mmap'd
> buffer implementation if mmap behaves as specified.  So the read call in
> _IO_file_underflow_mmap is unnecessary.  Am I missing something?

The problem is timing.  mmap affects atime, yes, but at the time the 
mmap happens.  The I/O stream rules require that atime is modified at 
the time of the first read operation.

  from the fgetc spec:

   The st_atime field shall be marked for update by the first successful
   execution of fgetc( ), fgets( ), fgetwc( ), fgetws( ), fread( ),
   fscanf( ), getc( ), getchar( ), gets( ), or scanf( ) using stream that
   returns data not supplied by a prior call to ungetc( ) or ungetwc( ).

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: _IO_file_underflow_mmap read call for atime

[Jakub Jelinek]

On Tue, Jul 30, 2002 at 02:46:41PM -0700, Ulrich Drepper wrote:
> Roland McGrath wrote:
> > The POSIX rules for mmap on files require that mmap'ing and reading a page
> > set the atime.  I don't see how the rules for stdio affecting atime (via
> > the "underlying functions" clauses) could be violated by the libio mmap'd
> > buffer implementation if mmap behaves as specified.  So the read call in
> > _IO_file_underflow_mmap is unnecessary.  Am I missing something?
> 
> The problem is timing.  mmap affects atime, yes, but at the time the 
> mmap happens.  The I/O stream rules require that atime is modified at 
> the time of the first read operation.
> 
>   from the fgetc spec:
> 
>    The st_atime field shall be marked for update by the first successful
>    execution of fgetc( ), fgets( ), fgetwc( ), fgetws( ), fread( ),
>    fscanf( ), getc( ), getchar( ), gets( ), or scanf( ) using stream that
>    returns data not supplied by a prior call to ungetc( ) or ungetwc( ).

Fine, cannot we mmap at the time of the first read then (and if fall back to
non-mmap stdio if that is not possible)?

	Jakub

Re: _IO_file_underflow_mmap read call for atime

[Ulrich Drepper]

Jakub Jelinek wrote:

> Fine, cannot we mmap at the time of the first read then (and if fall back to
> non-mmap stdio if that is not possible)?

The current code decides at startup time whether to use the mmap 
functions or not.  It would be conceivable to delay this but it makes 
things more complicated.  If you want to give it a try feel free.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: _IO_file_underflow_mmap read call for atime

[Roland McGrath]

> The problem is timing.  mmap affects atime, yes, but at the time the 
> mmap happens.  The I/O stream rules require that atime is modified at 
> the time of the first read operation.

The spec gives wide latitude in how mmap can behave.  It allows st_atime to
be updated at any time between mmap and munmap.  But it only requires that
it be updated by the time of the first successful access to a mapped area.

If we assume that the mmap implementations we are using in fact also meet
the stricter criterion of updating st_atime on each read fault, then it is
safe to just use mmap and st_atime will meet the POSIX stdio rules.  I
haven't experimented on Linux, but this is certainly how mmap behaves on
GNU/Hurd.

Re: _IO_file_underflow_mmap read call for atime

[Roland McGrath]

> Fine, cannot we mmap at the time of the first read then (and if fall back to
> non-mmap stdio if that is not possible)?

That seems more desireable to me anyway.  As it stands, a program that just
calls fopen and then fileno and does not io, or just uses fopen+fclose to
test existence (I have seen such things) will map in the contents of the
file when that's never required at all. 

Re: _IO_file_underflow_mmap read call for atime

[Ulrich Drepper]

Roland McGrath wrote:

> If we assume that the mmap implementations we are using in fact also meet
> the stricter criterion of updating st_atime on each read fault, then it is
> safe to just use mmap and st_atime will meet the POSIX stdio rules.  I
> haven't experimented on Linux, but this is certainly how mmap behaves on
> GNU/Hurd.

The Linux code modifies atime when it's mapped.  So we'd need a symbol 
MMAP_ATIME_AT_ACCESS which is defined for Hurd but not for Linux.  The 
read call is only performed when the symbol is not defined.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: _IO_file_underflow_mmap read call for atime

[Ulrich Drepper]

Roland McGrath wrote:

> That seems more desireable to me anyway.  As it stands, a program that just
> calls fopen and then fileno and does not io, or just uses fopen+fclose to
> test existence (I have seen such things) will map in the contents of the
> file when that's never required at all. 

If somebody sends a patch I've no problems with this either.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: _IO_file_underflow_mmap read call for atime

[Roland McGrath]

> The Linux code modifies atime when it's mapped.

And it doesn't update atime on read faults as well?  That is permissible
behavior, but not very helpful.  It makes atime pretty useless if it's
possible there are mmap readers.  There could be a process that opened the
file and mmap'd it a year ago, and then later something does a write so
mtime > atime; then if the first process reads the new data, atime remains
unchanged and sometime contemplating mtime vs atime would conclude that the
new data has not been read by anyone.

Re: _IO_file_underflow_mmap read call for atime

[Ulrich Drepper]

Roland McGrath wrote:

> And it doesn't update atime on read faults as well?  That is permissible
> behavior, but not very helpful.  It makes atime pretty useless if it's
> possible there are mmap readers.  There could be a process that opened the
> file and mmap'd it a year ago, and then later something does a write so
> mtime > atime; then if the first process reads the new data, atime remains
> unchanged and sometime contemplating mtime vs atime would conclude that the
> new data has not been read by anyone.

I don't know enough about the implementation.  I only know that the read 
is needed if mmap happened at fopen time.  You can talk to the kernel 
people.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------