<br><br><div class="gmail_quote">On Fri, Aug 21, 2009 at 5:36 AM, Jeff Layton <span dir="ltr"><<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, 20 Aug 2009 19:42:42 -0500<br>
Steve French <<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>> wrote:<br>
<br>
> Why don't we have a reference to this inode already? We can't have an<br>
> oplock break unless the file is open, if the file is open then we have a<br>
> reference to the inode ...<br>
><br>
<br>
</div>Well, you have a reference when the entry goes onto the list. There's<br>
no guarantee that you'll still have one when cifs_oplock_thread goes to<br>
take it off the list however. The file could have been closed by then<br></blockquote><div><br>An oplock response is handle based so we need to make sure the fid<br>is valid (if not, throw away the oplock response, except for the case<br>
of batch oplock which we don't use yet). Seems odd to lock the<br>inode when we really need the fid (file struct)<br><br>We could mark the file struct (similar to the write pending flag) and<br>delete such an entry off the oplockq in close (if we are closing<br>
a file with an oplock pending)<br></div></div><br><br clear="all"><br>-- <br>Thanks,<br><br>Steve<br>