From: "Steve French" <smfrench@gmail.com>
To: "Jeff Layton" <jlayton@redhat.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 12:51:03 -0500 [thread overview]
Message-ID: <524f69650810301051j7400a3f6m1840d06924ab8e89@mail.gmail.com> (raw)
In-Reply-To: <20081030134235.6d1276ae@barsoom.rdu.redhat.com>
On Thu, Oct 30, 2008 at 12:42 PM, Jeff Layton <jlayton@redhat.com> wrote:
> 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.
I agree that it is trivially worse for performance to have a single
spinlock protecting the three interrelated structures (cifs tcp, smb
and tree connection structs), but since they point to one another and
frequently have operations that require us to use all three lists -
to do things like iterate through all tree connections within a
particular smb session, or iterate across all cifs smb sessions within
each cifs tcp session - it makes code more complicated to have to grab
and unlock multiple spinlocks in the correct order every time across
all exit paths etc.
--
Thanks,
Steve
next prev parent reply other threads:[~2008-10-30 17:51 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
2008-10-30 17:51 ` Steve French [this message]
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=524f69650810301051j7400a3f6m1840d06924ab8e89@mail.gmail.com \
--to=smfrench@gmail.com \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).