[linux-cifs-client] Re: Fw: cifsoplockd oops in 2.6.13.4

Steven French sfrench at us.ibm.com
Thu Oct 27 02:44:06 GMT 2005






>Call Trace:
>  [<c013fc03>] find_get_pages+0x53/0x60
>  [<c014a16e>] pagevec_lookup+0x2e/0x40
>  [<c014a6e9>] invalidate_mapping_pages+0x59/0x100
>  [<c022ce5b>] CIFSSMBLock+0x7b/0x1e0
>  [<c022b452>] cifs_oplock_thread+0x112/0x214

Ian,
I just saw your post on lkml about the invalidate_mapping_pages oops
(above) in the cifs oplock thread.   The reference in the cifs code to
locking improvements, was not a reference to oplock (client caching tokens)
but to byte range locking (which is difficult to map from POSIX advisory
style to mandatory CIFS style locks, and for which the Samba team,
including myself, and others are working on network protocol extensions to
circumvent, there are two byte range locking changes, unrelated to your
issue which need to be addressed in code and are reasonably well understood
- special handling for whole file unlock (0 to MAX_OFFSET) and replay of
byte range lock state after session failure and auto-reconnection.  Neither
of these have anything to do with your report.

The cifs code that presumably is triggerring this is pretty harmless
looking
      invalidate_remote_inode(inode);
and presumably the oops is due to a problem with some of the pages in the
mapping of this inode which is not something I have seen before.

I am interested in exploring this bug more (I want to take a look at that
location in objdump and see if it is oopsing on a null page in the mapping
or not) - and I would like it if you could open a bugzilla entry
(bugzilla.samba.org or against the osdl kernel bugzilla) so we don't lose
this issue - even if it turns out to not be a cifs problem.




Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the linux-cifs-client mailing list