freebsd stable - Apr 2008 - panic with smbfs after MFC of kernel space locking

Hello and good morning,

I upgraded to 7-STABLE after the MFC of the kernel space locking. Since 
then I experience panics with programs that strongly rely in file 
locking on CIFS (smbfs) mounts:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x13bf2a8
fault code              = supervisor read data, page not present
instruction pointer     = 0x8:0xffffffff8023305a
stack pointer           = 0x10:0xffffffffc72d7920
frame pointer           = 0x10:0xffffffffc72d7950
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 42037 (perl)
[thread pid 42037 tid 100124 ]
Stopped at      lf_getblock+0x2a:       cmpq    %r12,0x8(%rbx)
db> bt
Tracing pid 42037 tid 100124 td 0xffffff00037dc350
lf_getblock() at lf_getblock+0x2a
lf_advlockasync() at lf_advlockasync+0x4f5
lf_advlock() at lf_advlock+0x47
smbfs_advlock() at smbfs_advlock+0x19a
flock() at flock+0x150
syscall() at syscall+0x256
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (131, FreeBSD ELF64, flock), rip = 0x800c0a3fc, rsp 0x7fffffffecc8,
rbp = 0x8325e8 ---

As far as I can see there were changes for all kinds of file systems 
with the MFC, but no change in the smbfs filesystem. I also couldn't 
find any change in HEAD's smbfs, so it was not a missing MFC, but 
probably the fs was missed in the changes at all.

Could anyone with a little better programming skills than me probably 
have a look at it? From the diffs of the other filesystems it seems like 
it's not a real big change, but mainly adding the function.


Thank you


-- 
| Oliver Brandmueller | Offenbacher Str. 1  | Germany       D-14197 Berlin |
| Fon +49-172-3130856 | Fax +49-172-3145027 | WWW:   http://the.addict.de/ |
|               Ich bin das Internet. Sowahr ich Gott helfe.               |
| Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! |

On 14 Apr 2008, at 08:19, Oliver Brandmueller wrote:
> Hello and good morning,
>
> I upgraded to 7-STABLE after the MFC of the kernel space locking.  
> Since
> then I experience panics with programs that strongly rely in file
> locking on CIFS (smbfs) mounts:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x13bf2a8
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x8:0xffffffff8023305a
> stack pointer           = 0x10:0xffffffffc72d7920
> frame pointer           = 0x10:0xffffffffc72d7950
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 42037 (perl)
> [thread pid 42037 tid 100124 ]
> Stopped at      lf_getblock+0x2a:       cmpq    %r12,0x8(%rbx)
> db> bt
> Tracing pid 42037 tid 100124 td 0xffffff00037dc350
> lf_getblock() at lf_getblock+0x2a
> lf_advlockasync() at lf_advlockasync+0x4f5
> lf_advlock() at lf_advlock+0x47
> smbfs_advlock() at smbfs_advlock+0x19a
> flock() at flock+0x150
> syscall() at syscall+0x256
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (131, FreeBSD ELF64, flock), rip = 0x800c0a3fc, rsp >
0x7fffffffecc8, rbp = 0x8325e8 ---
>
> As far as I can see there were changes for all kinds of file systems
> with the MFC, but no change in the smbfs filesystem. I also couldn't
> find any change in HEAD's smbfs, so it was not a missing MFC, but
> probably the fs was missed in the changes at all.
>
> Could anyone with a little better programming skills than me probably
> have a look at it? From the diffs of the other filesystems it seems  
> like
> it's not a real big change, but mainly adding the function.
I added a new vnode operation to support the new lock manager but this  
operation only needs to be implemented on filesystems that can be  
exported via NFS. I assumed that this was not the case for SMBFS.  
Could you find me a line number for lf_getblock+0x2a - something like  
this should do it:

	# gdb /boot/kernel/kernel
	(gdb) l *(lf_getblock+0x2a)