Subject: coda kernel panics: ok for l to be NULL?
To: None <tech-kern@netbsd.org>
From: Greg Troxel <gdt@ir.bbn.com>
List: tech-kern
Date: 03/09/2006 12:45:23
I am running relatively recent current with extra KASSERTs in
coda_venus.  The variable l is passwd in as struct lwp, and used as follows:

int
venus_close(void *mdp, CodaFid *fid, int flag,
	struct ucred *cred, struct lwp *l)
{
    int cflag;
    DECL_NO_OUT(coda_close);		/* sets Isize & Osize */
    ALLOC_NO_OUT(coda_close);		/* sets inp & outp */

    KASSERT(l != NULL);
    INIT_IN(&inp->ih, CODA_CLOSE, cred, l->l_proc);
    inp->Fid = *fid;
    CNV_OFLAG(cflag, flag);
    inp->flags = cflag;

    error = coda_call(mdp, Isize, &Osize, (char *)inp);

    CODA_FREE(inp, coda_close_size);
    return error;
}

INIT_IN's use of l (as 4th arg p) is

	  (in)->pid = p ? p->p_pid : -1; \
          (in)->pgid = p ? p->p_pgid : -1; \


which resulted in:

NetBSD/i386 (inexact.ir.bbn.com) (console)

login: panic: kernel diagnostic assertion "l != NULL" failed: file "/n0/gdt/NetBSD-current/src/sys/coda/coda_venus.c", line 247
Stopped in pid 3663.1 (ktr 0xc0b10380) at       netbsd:cpu_Debugger+0x4:        p
opl     %ebp
db> bt
cpu_Debugger(c042776e,cab0be08,0,0,cab0be1c) at netbsd:cpu_Debugger+0x4
panic(c045f2c0,c0416262,c0425c7d,c043ff40,f7) at netbsd:panic+0x12c
__assert(c0416262,c043ff40,f7,c0425c7d,0) at netbsd:__assert+0x2e
venus_close(c04ae440,c0bb0308,2,ca220f18,0) at netbsd:venus_close+0x173
coda_close(cab0be94,0,cab0bebc,c035b038,c040ae60) at netbsd:coda_close+0xcc
VOP_CLOSE(cb149160,2,ca220f18,0,ca236708) at netbsd:VOP_CLOSE+0x36
vn_close(cb149160,2,ca220f18,0,cb3c5968) at netbsd:vn_close+0x45
vn_closefile(ca236708,0,c0b7b3f0,0,cb3c58f8) at netbsd:vn_closefile+0x29
closef(ca236708,0,c04225f9,0,c0b103d0) at netbsd:closef+0x127
ktrace_thread(c0b10380,563000,c056d000,0,c010017c) at netbsd:ktrace_thread+0x106


So, is it legitimate for vnode ops to happen without a struct lwp *?
If so, I should just do

l ? l->l_proc : NULL

for the calls, wrapping it in a CODA_MAYBE_PROC ifdef to follow the
style :-)

Also, I find that pwd does not work inside coda, but haven't tracked
that down - "ktrace pwd" while in coda reliably panics the system.