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
