lkml.org 
[lkml]   [2010]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH UPDATED 38/40] cifs: use workqueue instead of slow-work
On Sun, 24 Jan 2010 17:25:18 +0900
Tejun Heo <tj@kernel.org> wrote:

> Hello,
>
> On 01/22/2010 08:45 PM, Jeff Layton wrote:
> >> @@ -584,13 +583,18 @@ is_valid_oplock_break(struct smb_hdr *bu
> >> pCifsInode->clientCanCacheAll = false;
> >> if (pSMB->OplockLevel == 0)
> >> pCifsInode->clientCanCacheRead = false;
> >> - rc = slow_work_enqueue(&netfile->oplock_break);
> >> - if (rc) {
> >> - cERROR(1, ("failed to enqueue oplock "
> >> - "break: %d\n", rc));
> >> - } else {
> >> - netfile->oplock_break_cancelled = false;
> >> - }
> >> +
> >> + /*
> >> + * cifs_oplock_break_put() can't be called
> >> + * from here. Get reference after queueing
> >> + * succeeded. cifs_oplock_break() will
> >> + * synchronize using GlobalSMSSeslock.
> >> + */
> >> + if (queue_work(system_single_wq,
> >> + &netfile->oplock_break))
> >> + cifs_oplock_break_get(netfile);
> >> + netfile->oplock_break_cancelled = false;
> >> +
> >
> > I think we want to move the setting of netfile->oplock_break_cancelled
> > inside of the if above it.
> >
> > If the work is already queued, I don't think we want to set the flag to
> > false. Doing so might be problematic if we somehow end up processing
> > this oplock break after a previous oplock break/reconnect/reopen
> > sequence, but while the initial oplock break is still running.
>
> Hmmm.... I can surely do that but that would be different from the
> original code. slow_work_enqueue() doesn't distinguish between
> successful enqueue and the one which got ignored because the work was
> already queued. With conversion to queue_work(), there's no failure
> case there so setting oplock_break_cancelled always is equivalent to
> the original code. Even if changing it is the right thing to do, it
> should probably be done with a separate patch as it changes the logic.
> Are you sure it needs to be changed?
>

I'm pretty sure we do. This flag only gets set to true if there's a
reconnection event. If there is one, then any oplock break queued up
before that happened is now invalid and shouldn't be sent.

It's a fairly minor point however. Even if we send the oplock break,
it's very unlikely to be treated as valid by the server as I don't
think the file would have a chance to be reopened prior to that.

If this is the way that the code works now, then let's go ahead with
your version and I'll plan to queue up a separate patch to change that
behavior after your changes go in.

Thanks,
--
Jeff Layton <jlayton@redhat.com>


\
 
 \ /
  Last update: 2010-01-24 13:17    [from the cache]
©2003-2011 Jasper Spaans