cvs commit: src/sys/boot/pc98/boot2 inode.h src/sys/i386/boot/dosboot inode.h src/sys/kern kern_lockf.c kern_mib.c kern_prot.c kern_resource.c subr_param.c src/sys/sys fcntl.h lockf.h proc.h resource.h resourcevar.h sysctl.h src/sys/vfs/isofs/cd9660 ...

[Richard Nyberg]

At Mon, 3 May 2004 09:06:27 -0700 (PDT),
Joerg Sonnenberger wrote:
> 
> joerg       2004/05/03 09:06:27 PDT
> 
> DragonFly src repository
> 
>   Modified files:
>     sys/boot/pc98/boot2  inode.h 
>     sys/i386/boot/dosboot inode.h 
>     sys/kern             kern_lockf.c kern_mib.c kern_prot.c 
>                          kern_resource.c subr_param.c 
>     sys/sys              fcntl.h lockf.h proc.h resource.h 
>                          resourcevar.h sysctl.h 
>     sys/vfs/isofs/cd9660 cd9660_node.h 
>     sys/vfs/nfs          nfsnode.h 
>     sys/vfs/smbfs        smbfs_node.h 
>     sys/vfs/ufs          inode.h 
>   Log:
>   POSIX lock resource limit part 3/4
>   
>   This splits "struct lockf" into the general book-keeping of ranges and
>   blocked request and the "struct lockf_range" which constists of the data
>   for a specific range. Adjust the interface of lf_advlock to remove one
>   level of pointer indirection and embedded "struct lockf" directly in the
>   inodes. Don't mess with wait channels any more.

Hello Joerg.

I'm trying to keep nnpfs of the arla project[1] up to date with dragonfly.
I have remove the indirection, but after this commit I get panics in
lf_advlock when using arla.

Here you can see how nnpfs calls lf_advlock

(kgdb) frame 6
#6  0xc0165e41 in lf_advlock (ap=0xdd317bc4, lock=0x0, size=0)
    at /usr/src/sys/kern/kern_lockf.c:144
144             struct flock *fl = ap->a_fl;
(kgdb) print *ap
$5 = {a_desc = 0xc02f2a40, a_vp = 0xdd31e0c0, a_id = 0xcfd703c0 "", a_op = 8, 
  a_fl = 0xdd317bf4, a_flags = 80}

The actual line lf_advlock panics on is probably the one checking
lock->init_done == 0, since lock is null. In rev 1.6 of kern_lockf.c
having the head == (struct lockf *)0 was supported, but it isn't
anymore. Is this intentional? Do you have any suggestion on what to
do on the nnpfs side?

Caveat: I am not really sure what lf_advlock really does or what
the meaning of the argument to it are, I'm just trying to make it
work :)

Right now I have made nnpfs return EOPNOTSUPP instead of calling
lf_advlock...

Regards,
        -Richard

[1] http://www.stacken.kth.se/project/arla/