Oliver Brandmueller
2008-Apr-14 07:20 UTC
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)