global_oplock_break: comment and possible bug

[jonathan bright]

my last post was rather terse.
a key point is that reply_mknew() is not protected by
the QUEUE_IN_OPLOCK flag.

any comments on the following scenario:

windows clients WC1 and WC2 have a file open with a
shared oplock each.  WC3 comes in and tries to open up the
file with no oplock.  open_mode_check() for WC3 results in
WC1 breaking to no oplock.  further suppose that the share
mode check for WC3 vs. WC1 fails for some reason.  if
now WC1 decides to write to the file, the call 
release_level_2_oplocks_on_change() will return without
breaking WC2s shared oplock.  which if true, sounds bad.

jon

--
jonathan bright
jonathan.bright at onebox.com
415.820.7322 - voicemail/fax
www.brightconsulting.com