linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: "Steve French" <smfrench@gmail.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] cifs: fix oopses and mem corruption with concurrent mount/umount (try #4)
Date: Thu, 30 Oct 2008 13:42:35 -0400	[thread overview]
Message-ID: <20081030134235.6d1276ae@barsoom.rdu.redhat.com> (raw)
In-Reply-To: <524f69650810301025t3f3b7fb6t10d96b6567a67715@mail.gmail.com>

On Thu, 30 Oct 2008 12:25:36 -0500
"Steve French" <smfrench@gmail.com> wrote:

> This is much better since it doesn't regress the tcon sharing (which we
> still need to extend for the shared superblock case) - I particularly like
> the new routines to put (free) the tcon and put the smb session, but think
> the locking gets more complicated (with little performance gain) moving from
> one global spinlock covering tcon/smb-session/cifs-tcp-socket to one
> embedded within each structure, and also could be confusing since the cifs
> tcp socket is already protected by a semaphore and now would have a spinlock
> too.   I think we greatly increase the chance of deadlock having to nest
> spinlocks.
> 

lockdep is pretty good about warning you if you're in danger of deadlock
(and I generally always have lockdep turned on).

I really think the fine-grained locking is the best scheme. It's pretty
clear how it should work. If you're walking or altering the lists
(and/or changing the refcounts) then you need to take the locks that
protect them. (granted, I probably need to do another respin that adds
some comments to this effect).

I think we want to resist having locks that protect too many things.
With that, we end up with the locks held over too much code. Not only is
that generally worse for performance, but it can paper over race
conditions.

-- 
Jeff Layton <jlayton@redhat.com>

  parent reply	other threads:[~2008-10-30 17:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1225379793-23283-1-git-send-email-jlayton@redhat.com>
     [not found] ` <524f69650810301025t3f3b7fb6t10d96b6567a67715@mail.gmail.com>
2008-10-30 17:26   ` Fwd: [PATCH 0/4] cifs: fix oopses and mem corruption with concurrent mount/umount (try #4) Steve French
2008-10-30 17:42   ` Jeff Layton [this message]
2008-10-30 17:51     ` Steve French
2008-10-30 18:01       ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081030134235.6d1276ae@barsoom.rdu.redhat.com \
    --to=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smfrench@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).