Re: CVS commit: src/sys/arch

[Jaromír Doleček]

Hey Maxime,

Seems the KASSERTs() are too aggressive, or there is some other bug.

I can trigger the kassert by simply attaching to rump_ffs, setting a
breakpoint and continuing, i.e:

> rump_ffs -o log ./ffs ./mnt
> gdb rump_ffs
..
(gdb) attach RUMP_PID
(gdb) break ffs_truncate
Breakpoint 1 at 0xad0b951f: file
/usr/home/dolecek/netbsd/sys/rump/fs/lib/libffs/../../../../ufs/ffs/ffs_inode.c,
line 210.
(gdb) cont
panic: kernel diagnostic assetion "onfault == kcopy_fault || rcr2() <
VM_MAXUSER_ADDRESS" failed: file "../../../../arch/i386/i386/trap.c",
line 358

Could you please look at it?

I'll disable the KASSERT() in my local tree, so that I'll be able to
develop. But would be good idea to check what so special that gdb is
doing that it trips over.

Thank you.

Jaromir

2016-09-16 13:48 GMT+02:00 Maxime Villard <ma...@netbsd.org>:
> Module Name: src
> Committed By: maxv
> Date: Fri Sep 16 11:48:10 UTC 2016
>
> Modified Files:
> src/sys/arch/amd64/amd64: trap.c
> src/sys/arch/i386/i386: trap.c
>
> Log Message:
> Put two KASSERTs, to make sure the fault is happening in the correct
> half of the vm space when using special copy functions. It can detect
> bugs where the kernel would fault when copying a kernel buffer which
> it wrongly believes comes from userland.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.84 -r1.85 src/sys/arch/amd64/amd64/trap.c
> cvs rdiff -u -r1.278 -r1.279 src/sys/arch/i386/i386/trap.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>

[Manuel Bouyer]

On Fri, Sep 23, 2016 at 09:33:36PM +0200, Jaromír Dole?ek wrote:
> Hey Maxime,
>
> Seems the KASSERTs() are too aggressive, or there is some other bug.
>
> I can trigger the kassert by simply attaching to rump_ffs, setting a
> breakpoint and continuing, i.e:
>
> > rump_ffs -o log ./ffs ./mnt
> > gdb rump_ffs

> ...

> (gdb) attach RUMP_PID
> (gdb) break ffs_truncate
> Breakpoint 1 at 0xad0b951f: file
> /usr/home/dolecek/netbsd/sys/rump/fs/lib/libffs/../../../../ufs/ffs/ffs_inode.c,
> line 210.
> (gdb) cont
> panic: kernel diagnostic assetion "onfault == kcopy_fault || rcr2() <
> VM_MAXUSER_ADDRESS" failed: file "../../../../arch/i386/i386/trap.c",
> line 358
>
> Could you please look at it?
>
> I'll disable the KASSERT() in my local tree, so that I'll be able to
> develop. But would be good idea to check what so special that gdb is
> doing that it trips over.

This anita test run:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/i386/201609171110Z_anita.txt

also triggered the KASSERT(). As it didn't happen with newer builds I assumed
it has been fixed, but maybe it's just that it's not 100% reproductible in
this context.

--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--