User-mode Linux kernel port

hno@... said:
> Hmm... the current CVS version does not compile...
> arch/um/include/sysdep-i386/syscall.h includes sysdep/syscall.h,
> causing recursive inclusion... 

Sorry.  It's fixed now.

			Jeff

hno@... said:
> ll_rw_block: device 62:00: only 4096-char blocks implemented (1024)
> Kernel panic: VFS: Unable to mount root fs on 62:00 

Here's a greater than one-line patch that should fix it for everyone.  I 
hardcoded it to 1024 for the same reason you hardcoded it to 4096 - because 
that stupid message told me to...

				Jeff


--- ../cvs/linux/arch/um/fs/hostfs/hostfs_kern.c        Sun Mar 25 12:27:43 
2001
+++ arch/um/fs/hostfs/hostfs_kern.c     Sun Mar 25 22:07:06 2001
@@ -658,7 +658,7 @@
        kdev_t dev = sb->s_dev;
        int blocksize = get_hardblocksize(dev);
 
-       if(blocksize == 0) blocksize = 1024;
+       if(blocksize == 0) blocksize = BLOCK_SIZE;
        if(!(bh = bread (dev, 0, blocksize))) return NULL;
        if(strncmp(bh->b_data, "HOSTFS:", strlen("HOSTFS:"))) goto out;
        ret = hostfs_read_super_common(sb, bh->b_data + strlen("HOSTFS:"));
um 1094: diff -u ../cvs/linux/arch/um/drivers/ubd.c arch/um/drivers/ubd.c
--- ../cvs/linux/arch/um/drivers/ubd.c  Sun Mar 25 12:27:43 2001
+++ arch/um/drivers/ubd.c       Sun Mar 25 22:04:08 2001
@@ -26,7 +26,9 @@
 
 #define MAX_DEV (8)
 
-static int blk_sizes[MAX_DEV] = { [ 0 ... MAX_DEV - 1 ] = 512 };
+static int blk_sizes[MAX_DEV] = { [ 0 ... MAX_DEV - 1 ] = BLOCK_SIZE };
+
+static int hardsect_sizes[MAX_DEV] = { [ 0 ... MAX_DEV - 1 ] = BLOCK_SIZE };
 
 static int sizes[MAX_DEV] = { [ 0 ... MAX_DEV - 1 ] = 0 };
 
@@ -276,6 +278,7 @@
        elevator_init(&q->elevator, ELEVATOR_NOOP);
        read_ahead[MAJOR_NR] = 8;               /* 8 sector (4kB) read-ahead */
        blksize_size[MAJOR_NR] = blk_sizes;
+       hardsect_size[MAJOR_NR] = hardsect_sizes;
        ubd_gendisk.next = gendisk_head;
        gendisk_head = &ubd_gendisk;
        if (fake_major != 0){

listreader@... said:
> Have you looked at my replacement umn_helper? My cvs update suggests
> it's not in the repository yet. 

It's not.

That's a decent idea, but there are things I don't like about the 
implementation.  I'll get some comments back to you after I get back from San 
Jose.

				Jeff

hno@... said:
> Including the pte_alloc bug I have been reporting it seems. At least a
> similar bugfix to the one I proposed is there. 

No, that's a failed attempt to fix that problem.  What I'm seeing is a process 
segfault followed by various complaints about bogus swap entries when the 
process memory is freed.

I still don't have much idea what's going on there.

> Hmm.. maybe the killall5 issue fixes a shutdown bug I have been seeing
> lately when running one of our "applications" in UML.. not using
> killall5 thou but something similar. Will test shortly. 

Anything that walked the process list would hang.  The usual victims are ps 
and killall5, but it would also hit things like top.

				Jeff

Jeff Dike wrote:

> hno@... said:
> > Including the pte_alloc bug I have been reporting it seems. At least a
> > similar bugfix to the one I proposed is there.
>
> No, that's a failed attempt to fix that problem.  What I'm seeing is a process
> segfault followed by various complaints about bogus swap entries when the
> process memory is freed.
>
> I still don't have much idea what's going on there.

All I know is if I run with the pte_clear patch I sent or one similar to the one
you made involving both pte_clear and pte_none then the problem is not visible
here. As long as pte_none acts correctly on free entries it works fine, if it
errounously returns differently when the entry has been reused (cleared with
pte_clear) then things fail with the message I reported earlier.

/Henrik

Hi,

Jeff Dike wrote:

> hno@... said:
> > Including the pte_alloc bug I have been reporting it seems. At least a
> > similar bugfix to the one I proposed is there.
> 
> No, that's a failed attempt to fix that problem.  What I'm seeing is a process
> segfault followed by various complaints about bogus swap entries when the
> process memory is freed.
> 
> I still don't have much idea what's going on there.

The problem is pte_none(). A swap entry must be (!pte_none(pte) &&
!pte_present(pte)). With the SWP_* macros in pgtable.h you define which
bits can be used to encode type and offset and they must not overlap
with the bits used in pte_none() and pte_present(). So the current
pte_none() may return a wrong value for swap entries, because it masks a
bit of the swap type. So changing the definition of _PAGE_NEWPAGE should
solve the problem.

bye, Roman