All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lou Langholtz <ldl@aros.net>
To: linux-kernel@vger.kernel.org
Cc: alan@redhat.com, marcelo@conectiva.com.br
Subject: [PATCH] network block device driver, kernel 2.4
Date: Sun, 13 Apr 2003 03:32:29 -0600	[thread overview]
Message-ID: <3E992EAD.6050102@aros.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

Here's a simple patch to nbd.c to fix some of the potential for oopses 
(and possible corruption) should the nbd-client that handed off a socket 
exit (implicitly closing the socket), while the driver is still sending 
requests onto that socket. The oops can easily be seen when root runs 
"nbd-client -d /dev/nbX" after /dev/nbX has been setup and still has a 
bunch of I/O buffered up (and is sending requests to the socket to 
handle the queue). This patch doesn't change functionality.

Louis D. Langholtz

[-- Attachment #2: nbd.diff --]
[-- Type: text/plain, Size: 1431 bytes --]

--- linux-2.4.20/drivers/block/nbd.c	2002-08-02 18:39:43.000000000 -0600
+++ linux/drivers/block/nbd.c	2003-04-13 02:24:26.000000000 -0600
@@ -26,6 +26,8 @@
  *   reduce number of partial TCP segments sent. <steve@chygwyn.com>
  * 01-12-6 Fix deadlock condition by making queue locks independant of
  *   the transmit lock. <steve@chygwyn.com>
+ * 03-04-12 Fix some possible ways to oops from the nbd-client closing the
+ *   socket it gave us while we're still using that socket. <ldl@aros.net>
  *
  * possible FIXME: make set_sock / set_blksize / set_size / do_it one syscall
  * why not: would need verify_area and friends, would share yet another 
@@ -153,7 +155,7 @@
 	int result;
 	struct nbd_request request;
 	unsigned long size = req->nr_sectors << 9;
-	struct socket *sock = lo->sock;
+	struct socket *sock;
 
 	DEBUG("NBD: sending control, ");
 	request.magic = htonl(NBD_REQUEST_MAGIC);
@@ -163,6 +165,8 @@
 	memcpy(request.handle, &req, sizeof(req));
 
 	down(&lo->tx_lock);
+	sock = lo->sock;
+	if (!sock) goto error_out; /* we got cleared */
 
 	result = nbd_xmit(1, sock, (char *) &request, sizeof(request), req->cmd == WRITE ? MSG_MORE : 0);
 	if (result <= 0)
@@ -402,7 +406,10 @@
 		if (!file)
 			return -EINVAL;
 		lo->file = NULL;
+		/* ensure we're not in critical section of nbd_send_req() */
+		down(&lo->tx_lock);
 		lo->sock = NULL;
+		up(&lo->tx_lock);
 		fput(file);
 		return 0;
 	case NBD_SET_SOCK:

                 reply	other threads:[~2003-04-13  8:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=3E992EAD.6050102@aros.net \
    --to=ldl@aros.net \
    --cc=alan@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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.