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    [W:0.024 / U:3.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site