[linux-cifs-client] [PATCH 4/4] cifs: convert oplock breaks to use slow_work facility

Jeff Layton jlayton at redhat.com
Sat Sep 12 05:59:53 MDT 2009


On Fri, 11 Sep 2009 08:14:08 -0400
Jeff Layton <jlayton at redhat.com> wrote:

> Currently, when an oplock break comes in there's a chance that the
> oplock break job won't occur if the allocation of the oplock_q_entry
> fails. There are also some rather nasty races in the allocation and
> handling these structs.
> 
> Rather than allocating oplock queue entries when an oplock break comes
> in, add a few extra fields to the cifsFileInfo struct. Get rid of the
> dedicated cifs_oplock_thread as well and queue the oplock break job
> to the slow_work thread pool.
> 
> This approach also has the advantage that the oplock break jobs can
> potentially run in parallel rather than be serialized like they are
> today.
> 
> Signed-off-by: Jeff Layton <jlayton at redhat.com>
> ---
>  fs/cifs/Kconfig     |    1 +
>  fs/cifs/cifsfs.c    |   95 +++------------------------------------------------
>  fs/cifs/cifsglob.h  |   12 +++----
>  fs/cifs/cifsproto.h |    4 --
>  fs/cifs/cifssmb.c   |    1 +
>  fs/cifs/connect.c   |    1 -
>  fs/cifs/dir.c       |    2 +
>  fs/cifs/file.c      |   71 +++++++++++++++++++++++++++++++++++++-
>  fs/cifs/misc.c      |   29 +++++++++++-----
>  fs/cifs/transport.c |   50 ---------------------------
>  10 files changed, 103 insertions(+), 163 deletions(-)
> 

Steve,

Attached is a new version of this patch. It's still very close to
the old version. The only difference is that it has the oplock break
job take and hold a reference to the tcon until it completes. With
the other patch, there was a small possibility that the tcon could
vanish while the oplock break job is running. This should fix by
ensuring that the tcon can't go away until the oplock break job
completes.

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list