[linux-cifs-client] merge activity since 2.6.26

[Jeff Layton]

On Wed, 6 Aug 2008 17:18:27 -0500
"Steve French" <smfrench at gmail.com> wrote:

> On Wed, Aug 6, 2008 at 11:49 AM, Jeff Layton <jlayton at redhat.com> wrote:
> > On Wed, 6 Aug 2008 11:30:52 -0500
> > Ok. I count 3 missing patches, actually...
> >
> > [CIFS] spin off cifs_setattr with unix extensions to its own function
> > [CIFS] move file time and dos attribute setting logic into new function
> > [CIFS] turn cifs_setattr into a multiplexor that calls the correct function
> >
> > Let me know if it looks like the bad cp -p behavior you're seeing is
> > due to any of the patches already committed...
> 
> I merged the 0002-spin-off-cifs-setattr-with-unix-extensions ... one
> but in reviewing it was wondering if the UnixSetPathInfo call will
> break oplock - if so whether we should do the find_writable_file trick
> if the file is open or whether that risks messing up the security
> checks.
> 
> 

Good question in regards to oplocks. Those are implemented in samba on
Linux via leases, and the fcntl(2) manpage says:

       A file lease provides a mechanism whereby the process holding
       the lease (the "lease holder") is notified (via  delivery  of a
       signal) when a process (the "lease breaker") tries to open(2)
       or truncate(2) that file.

...so I'd guess that a SetPathInfo that changes the size (a truncate)
would break the lease, but size changes are handled by the
cifs_set_file_size() function and that does the find_writable_file()
trick already.

So my guess is that the answer here is no, this code will not break an
oplock (at least on samba on linux using leases, not sure about oplocks
that are handled internally).

Still, I'll plan to give it a try in the next day or so and see whether
this is correct.

-- 
Jeff Layton <jlayton at redhat.com>