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

[Shirish Pargaonkar]

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.

Regards,

Shirish