[linux-cifs-client][patch] get security descriptor results in oplock break

[simo]

On Sat, 2008-03-15 at 10:29 -0500, Shirish Pargaonkar wrote:
> On 3/15/08, simo <idra at samba.org> wrote:
> >
> > On Thu, 2008-03-13 at 12:32 -0500, Shirish Pargaonkar wrote:
> > > With cifsacl mount option, when a file is created on the Windows server,
> > > exclusive oplock is broken right away because the get cifs acl code
> > > again opens the file
> > > to obtain security descriptor.
> > > The client does not have the newly created file handle or inode in any
> > > of its lists yet
> > > so it does not respond to oplock break and the server waits for its
> > > set duration and
> > > then responds to the second open.
> >
> > Can you elaborate more on this point?
> > The CIFS client should never be in a state where it cannot respond to an
> > oplock break as that may cause serious problems on a network, are there
> > other cases you have seen in the code where we could be unable to reply
> > to an oplock break?
> >
> > Simo.
> >
> > --
> > Simo Sorce
> > Samba Team GPL Compliance Officer <simo at samba.org>
> > Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>
> >
> >
> 
> cifs client should/does respond to the oplock break request.
> Just not in this particular case.  We are in cifs_create, and before inode is
> added to any list, the second open happens in cifs_get_inode_info in order
> to obtain security descriptor info to determine mode and uid/gid (from sid, that
> code is not yet there) which results in oplock break.

Thanks for clarifying.
Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>