On Wed, Apr 15, 2015 at 07:05:51PM +0200, Manuel Bouyer wrote:
> hello,
> I just got this:
> panic: kernel diagnostic assertion "(m)->m_type != MT_FREE" failed: file
> "/dsk/l1/misc/bouyer/netbsd-7/src/sys/kern/uipc_mbuf.c", line 652
> cpu0: Begin traceback...
> vpanic() at netbsd:vpanic+0x13c
>
hello,
I just got this:
panic: kernel diagnostic assertion "(m)->m_type != MT_FREE" failed: file
"/dsk/l1/misc/bouyer/netbsd-7/src/sys/kern/uipc_mbuf.c", line 652
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
kern_assert() at netbsd:kern_assert+0x4f
m_freem() at netbsd:m_freem+0xa7
ipf
> What's the best way to fix it ? fix kauth_cred_geteuid(), or audit the
> kauth_cred_geteuid() calls and handle it there ?
I guess it would be better if NOCRED/FSCRED is handled in
kauth_cred_geteuid() (and other kauth_cred_... routines).
In case of kauth_cred_geteuid(), it will be natual if 0 i
On Tue, Feb 10, 2015 at 07:49:24AM +0900, tsugutomo.en...@jp.sony.com wrote:
> Manuel Bouyer writes:
>
> > Stopped in pid 9987.1 (postdrop) at netbsd:kauth_cred_geteuid+0xd:
> > movl 4
> > 4(%rbx),%eax
> > kauth_cred_geteuid() at netbsd:kauth_cred_geteuid+0xd
> > ffs_alloc() at netbsd:ffs_alloc+0
Manuel Bouyer writes:
> Stopped in pid 9987.1 (postdrop) at netbsd:kauth_cred_geteuid+0xd:
> movl 4
> 4(%rbx),%eax
> kauth_cred_geteuid() at netbsd:kauth_cred_geteuid+0xd
> ffs_alloc() at netbsd:ffs_alloc+0x1aa
> ffs_balloc() at netbsd:ffs_balloc+0x1525
> wrsnapblk() at netbsd:wrsnapblk+0x4f
FSC
Hello,
I've seen this on a netbs-7 host:
uvm_fault(0xa4b1c460, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 8020fcb4 cs e030 rflags 10282 cr2 42 ilevel 0 rsp
a0005af29740
curlwp 0xace41180 pid 9987.1 lowest kstack 0xa0005af262c0
kernel: pa
