Re: kern/52252: uvm_km_check_empty panic when loading any module

[Anthony Mallet <tho%netbsd.org@localhost>]

The following reply was made to PR kern/52252; it has been noted by GNATS.

From: Anthony Mallet <tho%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost,
    gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/52252: uvm_km_check_empty panic when loading any module
Date: Tue, 23 May 2017 23:44:59 +0200

 On Tuesday 23 May 2017, at 21:05, Jarom=C3=ADr Dole=C4=8Dek wrote:
 >  1. make sure to rebuild your complete kernel, to make sure no
 >     obsolete .o
 >  were used - make clean && make depend && make
 
 Yes. When doing an important upgrade I usually wipe out /usr/obj (or
 move it away) and do a ./build.sh without -u.
 In this case I'm also 100% sure that I did this.
 
 >  2. make sure that DEBUG/LOCKDEBUG options between your kernel and
 >     the
 >  modules match - since DEBUG and LOCKDEBUG change size of critical
 >  kernel structures, kernel will trample over random structure
 >  contents since what module allocates is less than the kernel uses.
 >
 >  Looking on your config, it seems you do have the DEBUG and
 >  LOCKDEBUG options there, so I think that is your problem.
 
 Good point, but see below.
 For the consistency between kernel & modules, I guess it's not
 sufficient to do a ./build.sh modules, since this will not pick up the
 DEBUG option from my custom kernel, right=3F How should I proceed, then=
 =3F
 
 
 Actually, my issue started with a kernel without DEBUG nor LOCKDEBUG,
 and while trying to just "npfctl reload", with no module involved at
 all (I usually don't use modules).
 
 The panic was also in the same uvm=5Fkm=5Fcheck=5Fempty() when sljit -
 builtin in the kernel, 100% sure - was doing a uvm=5Fkm=5Falloc().
 See here for a partial backtrace:
 http://mail-index.netbsd.org/current-users/2017/04/15/msg031529.html
 
 This is after this panic that I discovered that anything trying to
 uvm=5Fkm=5Falloc() in module=5Fmap was panicing on the very first page =
 of
 module=5Fmap. I can reproduce this on my test machine (the PAPYRUS
 kernel that I sent) if needed, for clarity.