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

[Andrew Morton]

(Adds Ian to cc)

Steven French <sfrench at us.ibm.com> wrote:
>
> 
> 
> 
> 
> 
> >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