On Wed, Nov 16, 2016 at 9:05 AM, Samuel Thibault <samuel.thiba...@gnu.org>

> Samuel Thibault, on Wed 16 Nov 2016 19:50:07 +0100, wrote:
> > Samuel Thibault, on Wed 16 Nov 2016 19:46:52 +0100, wrote:
> > > The attached testcase does get the faulting address.
> >
> > And the attached testcase doesn't.
> And is fixed by the attached patch, could you try it?

OK, I've finally tested this patch!

It took me a while.  I had a lot of problems building the glibc package, so
I finally stopped trying to build the package and just built the library
with the intent of injecting it into ext2fs using LD_LIBRARY_PATH.  It took
me a while to figure out that settrans clobbers the environment, and that
bug I reported about the /proc environ files returning I/O errors certainly
didn't help.  I finally got the translator loading the library using a
trick that I want to document:

    settrans -a mnt /usr/bin/env LD_LIBRARY_PATH=/root/lib /hurd/ext2fs

The patch works, but is incomplete.  Samuel's test programs attempt to
access unmapped memory addresses, which generate KERN_MEMORY_FAILURE, but
ext2fs attempts to access mapped addresses back by a memory manager
returning faults, which generates KERN_MEMORY_ERROR, so we also need this:

--- sysdeps/mach/hurd/i386/exc2signal.c~ 2016-11-09 20:03:52.000000000 -1000
+++ sysdeps/mach/hurd/i386/exc2signal.c  2016-11-30 01:54:02.000000000 -1000
@@ -40,6 +40,7 @@
+       case KERN_MEMORY_ERROR:
          *signo = SIGSEGV;
          detail->code = posix ? SEGV_MAPERR : detail->exc_subcode;

That, along with the other patches, seems to produce an ext2fs that can
handle disk full conditions without dying!

It still exhibits some weird behavior - creating directory entries for the
files that it doesn't have the space for.

Do we have any kind of a test suite for hurd?  This seems like a nice test
- mount a ramdisk and fill it up.  We've uncovered a number of bugs trying
to do that.


Reply via email to