public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Paul Clements <paul.clements@steeleye.com>,
	linux-kernel@vger.kernel.org, nbd-general@lists.sourceforge.net
Subject: Re: [PATCH] nbd: correct disconnect behavior
Date: Tue, 02 Jul 2013 02:19:38 -0500	[thread overview]
Message-ID: <1372749578.5019.8@driftwood> (raw)
In-Reply-To: <20130626162107.9237360f7646ec25f23cf5aa@linux-foundation.org> (from akpm@linux-foundation.org on Wed Jun 26 18:21:07 2013)

On 06/26/2013 06:21:07 PM, Andrew Morton wrote:
> On Wed, 19 Jun 2013 17:09:18 -0400 (EDT) Paul Clements  
> <paul.clements@steeleye.com> wrote:
> 
> > Currently, when a disconnect is requested by the user (via  
> NBD_DISCONNECT
> > ioctl) the return from NBD_DO_IT is undefined (it is usually one of
> > several error codes). This means that nbd-client does not know if a
> > manual disconnect was performed or whether a network error occurred.
> > Because of this, nbd-client's persist mode (which tries to  
> reconnect after
> > error, but not after manual disconnect) does not always work  
> correctly.
> >
> > This change fixes this by causing NBD_DO_IT to always return 0 if a  
> user
> > requests a disconnect. This means that nbd-client can correctly  
> either
> > persist the connection (if an error occurred) or disconnect (if the  
> user
> > requested it).
> 
> This sounds like something which users of 3.10 and earlier kernels
> might want, so I added the Cc:stable tag.  Please let me know if
> you disagree.
> 
> > --- a/drivers/block/nbd.c
> > +++ b/drivers/block/nbd.c
> > @@ -623,6 +623,8 @@ static int __nbd_ioctl(struct block_device  
> *bdev, struct nbd_device *nbd,
> >  		if (!nbd->sock)
> >  			return -EINVAL;
> >
> > +		nbd->disconnect = 1;
> > +
> >  		nbd_send_req(nbd, &sreq);
> >                  return 0;
> >  	}
> > @@ -654,6 +656,7 @@ static int __nbd_ioctl(struct block_device  
> *bdev, struct nbd_device *nbd,
> >  				nbd->sock = SOCKET_I(inode);
> >  				if (max_part > 0)
> >  					bdev->bd_invalidated = 1;
> > +				nbd->disconnect = 0; /* we're connected  
> now */
> >  				return 0;
> >  			} else {
> >  				fput(file);
> > @@ -742,6 +745,8 @@ static int __nbd_ioctl(struct block_device  
> *bdev, struct nbd_device *nbd,
> >  		set_capacity(nbd->disk, 0);
> >  		if (max_part > 0)
> >  			ioctl_by_bdev(bdev, BLKRRPART, 0);
> > +		if (nbd->disconnect) /* user requested, ignore socket  
> errors */
> > +			return 0;
> >  		return nbd->harderror;
> >  	}
> 
> hm, how does nbd work...  Hard to tell as nothing seems to be  
> documented
> anywhere :(

I wrote the busybox version, which might be a bit simpler:

   http://git.busybox.net/busybox/tree/networking/nbd-client.c

(Sorry about the #ifdefs, they're not mine.)

> afacit the code assumes that the user will run ioctl(NBD_DISCONNECT)  
> and
> then ioctl(NBD_DO_IT) and then ioctl(NBD_SET_SOCK), yes?  Does this
> change mean that if userspace calls the ioctls in an
> other-than-expected order, Weird Things will happen?  Would it be  
> safer
> to clear ->disconnect in NBD_DO_IT?
> > --- a/include/linux/nbd.h
> > +++ b/include/linux/nbd.h
> > @@ -41,6 +41,7 @@ struct nbd_device {
> >  	u64 bytesize;
> >  	pid_t pid; /* pid of nbd-client, if attached */
> >  	int xmit_timeout;
> > +	int disconnect; /* a disconnect has been requested by user */
> >  };
> 
> The cool kids are using bool lately ;)

No, they're not. The C++ guys and stuffy old ex-cobol types are, and  
think it helps. (Does any architecture anywhere _not_ use int for bool?)

Rob

  parent reply	other threads:[~2013-07-02  7:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19 21:09 [PATCH] nbd: correct disconnect behavior Paul Clements
2013-06-21  3:56 ` Rob Landley
2013-06-26 23:21 ` Andrew Morton
     [not found]   ` <CAECXXi54NUvQLY1O0oWKqgDpdXWUCCcs_4jJkRJE29DctMYVUA@mail.gmail.com>
2013-06-27 22:28     ` Andrew Morton
2013-06-27 23:25       ` Paul Clements
2013-07-02  7:19   ` Rob Landley [this message]
2013-08-26 12:54     ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2013-06-27 22:24 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=1372749578.5019.8@driftwood \
    --to=rob@landley.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nbd-general@lists.sourceforge.net \
    --cc=paul.clements@steeleye.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