bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: exec and bzip2


From: Roland McGrath
Subject: Re: exec and bzip2
Date: Wed, 1 Apr 2009 16:49:03 -0700 (PDT)

A few notes.  I'll leave it to you how to put them all together.

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.  For normal use,
you really want a proper decompression translator that is smarter about
memory use and does not do such eager decompression of the whole file.
Then exec would not think about it at all.

The code predates the isolation of decompressor code into the (kind of)
reasonable libz and bzlib library interfaces.  Surely we don't want to keep
those guts around in the exec sources and should be using libraries instead.

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.  That doesn't have to do with what the
contents of the file are, but with the fs backing it.

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.  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.

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.


Thanks,
Roland





reply via email to

[Prev in Thread] Current Thread [Next in Thread]