[linux-cifs-client] Refactored change notification handling and implemented multishot

[Steven French]

> I created a cifs_dnotify_thread to handle the incoming change
> notification responses, so now it works like oplock handling. On top of
> that I added multishot capability - the dnotify thread will re-request
> notification if DN_MULTISHOT was specified.

Sounds promising, I will review it.

> A couple questions: I noticed a lot of the oplock code holds the
> GlobalMid_Lock when doing list operations, should I take care of doing
> that in my list operations too?
Yes - as long as the code does not block.

> Also, the oplock code uses a kmem_cache for the queue. Is that just to
> keep track of how much memory is being used and possibly catch memory
> leaks?
Yes - and presumably is fast when you are allocating the same size units.
It does not make sense when the chunks are variable size.

Not sure if notify is ever sent on files, but for the case of notify on
files (if valid) -
we should probably check (if you don't do it already) that the file is
oplocked
before sending the notify.  Sending notify on oplocked files is probably
not
necessary.  Although it will take some careful coding to avoid races
(we would then presumably need to send the (async) notify request just
before the oplock break
acknowledgement from the client to the server - but we have to be careful
that the server
can handle this), and if one can do notify on files then we may also have
to check the notify state
before we issue a close of the handle.   Because opening a file a second
time, even
from the same client, triggers an oplock break response, this may turn out
to be a moot point
until we add a reference count on the client cifs_file struct to avoid
sending two identical
open requests (and causing the server to break the oplock, preventing us
from caching on the
client, unnecessarily).

Another issue I noticed relating to oplock ... we don't check the device
characteristics flag
coming back from one of the trans2 QFSInfo calls coming back from mount -
if the volume
is marked as a readonly should we bother to send notify or oplock requests?


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