All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Matthew Wilcox <matthew@wil.cx>
Cc: "david m. richter" <richterd@citi.umich.edu>,
	linux-fsdevel@vger.kernel.org
Subject: Re: On setting a lease across a cluster
Date: Fri, 4 Jan 2008 15:53:04 -0500	[thread overview]
Message-ID: <20080104205304.GA14827@fieldses.org> (raw)
In-Reply-To: <20080104203550.GG20473@parisc-linux.org>

On Fri, Jan 04, 2008 at 01:35:50PM -0700, Matthew Wilcox wrote:
> > > > vfs_setlease()
> > > >    if (f_op->setlease())
> > > >       res = f_op->setlease()
> > > >       if (res)
> > > >          return res;
> > > >    lock_kernel()
> > > >    generic_setlease()
> > > >    unlock_kernel()
> > 
> > Why can't the filesystem call into generic_setlease() on its own?
> 
> Because (assuming we're rid of the BKL), fcntl_setlease() needs to
> acquire the spinlock and hold it while generic_setlease() runs, so
> generic_setlease() can't acquire the lock.

So, the problem is that fcntl_setlease() does

	vfs_setlease()
	fasync_helper()

which the bkl held over both, and you want to preserve that?

But what that BKL is doing is a mystery to me--the very first thing that
fasync_helper() does is kmem_cache_alloc(., GFP_KERNEL).  So you won't
be introducing any new problem if you lock those two operations
separately.  Unless I'm totally missing something.

--b.

  reply	other threads:[~2008-01-04 20:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-04 18:14 On setting a lease across a cluster Matthew Wilcox
2008-01-04 18:55 ` david m. richter
2008-01-04 19:47   ` J. Bruce Fields
2008-01-04 20:35     ` Matthew Wilcox
2008-01-04 20:53       ` J. Bruce Fields [this message]
2008-01-04 21:08         ` Matthew Wilcox
2008-01-04 21:16           ` J. Bruce Fields
2008-01-04 20:18   ` Matthew Wilcox
2008-01-05 17:44     ` david m. richter

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=20080104205304.GA14827@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=richterd@citi.umich.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.