All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Clements <paul.clements@steeleye.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: akpm@osdl.org, djani22@dynamicweb.hu,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [NBD] Use per-device semaphore instead of BKL
Date: Sun, 20 Nov 2005 16:42:23 -0500	[thread overview]
Message-ID: <4380EDBF.7090107@steeleye.com> (raw)
In-Reply-To: <20051120204325.GB11043@gondor.apana.org.au>

Herbert Xu wrote:
> On Sun, Nov 20, 2005 at 12:19:17PM -0500, Paul Clements wrote:
> 
>>The dropping of the lock in nbd_do_it is actually critical to the way 
>>nbd functions. nbd_do_it runs for the lifetime of the nbd device, so if 
>>nbd_do_it were holding some lock (BKL or otherwise), we'd have big problems.
> 
> 
> Why would you want to issue an ioctl from a different process while
> nbd-client is still running?

nbd-client -d (disconnect) is the main reason -- this functionality 
would be broken if we didn't allow ioctls anymore

> Allow ioctl's while nbd_do_it is in progress is a *serious* bug.  For a

Certain ioctls, yes. There's no harm in NBD_DISCONNECT, though.

> start, if someone else clears the socket then nbd_read_stat will crash.

I agree, NBD_CLEAR_SOCK from another process while nbd_do_it is running 
would cause problems. But, if the user-level tools are coded properly, 
this is not an issue.

Perhaps your ioctl lock scheme, with an exemption for NBD_DISCONNECT 
would work?

--
Paul

  reply	other threads:[~2005-11-20 21:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200511190345.jAJ3jFC3016406@shell0.pdx.osdl.net>
     [not found] ` <437F4C85.3070108@steeleye.com>
2005-11-19 22:34   ` + nbd-fix-tx-rx-race-condition.patch added to -mm tree Herbert Xu
2005-11-20  1:58     ` [NBD] Use per-device semaphore instead of BKL Herbert Xu
2005-11-20 17:19       ` Paul Clements
2005-11-20 20:43         ` Herbert Xu
2005-11-20 21:42           ` Paul Clements [this message]
2005-11-20 22:08             ` Herbert Xu
2005-11-21  1:12               ` Paul Clements

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=4380EDBF.7090107@steeleye.com \
    --to=paul.clements@steeleye.com \
    --cc=akpm@osdl.org \
    --cc=djani22@dynamicweb.hu \
    --cc=herbert@gondor.apana.org.au \
    --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 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.