Re: exec and bzip2

[Samuel Thibault]

Roland McGrath, le Wed 01 Apr 2009 16:49:03 -0700, a écrit :
> A few notes.

Thanks!

> The gzip/bzip2 hack in exec was really never intended for general use.
> It's only there for bootstrap exec to be able to use it.

Ok, so I was right in thinking that maybe I could just disable them.

> The XXX/fault problem is not specific to the gzip/bzip2 code at all.
> It's a general way in which exec is not robust against mapped file faults.
> For actual page-in failures, it is odd that you should see a problem with
> bzip2 and not with exec in general.

Yes, I'm a bit surprised too but maybe it's just chance.

I am just wondering: why are faults a problem?  The bug I'm seeing seems
to happen when there is memory pressure and I guess gnumach trying to
drop pages.  But since exec doesn't seem to use its own pager, shouldn't
the usual page-in mechanism just work?  What makes exec particular?

> Since you mentioned "offset is really bogus", I surmise that perhaps the
> real failure mode is something in decompression going haywire such that it
> is asking for an unreasonable amount in a zipread callback.

I was probably wrong putting that sentence, see below.

> If that's the issue, then the exec bug has nothing to do with fault
> handling.  It just needs to police the pointers it can try to use
> better.

It actually does: 

      n = MIN (maxread, map_buffer (e) + map_fsize (e) - contents);
      memcpy (buf, contents, n); /* XXX/fault */

And in the case I could observe the offset was just 8.

> To do the fault handling in general, you need to use something like
> hurd_catch_signal around the direct pointer accesses, or use
> hurd_safe_copyin for the memcpy cases.

Ok.

Thanks,
Samuel