From: Lou Langholtz <ldl@aros.net>
To: Paul Clements <Paul.Clements@SteelEye.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] 2.6.0 NBD driver: remove send/recieve race for request
Date: Wed, 06 Aug 2003 01:34:25 -0600 [thread overview]
Message-ID: <3F30AF81.4070308@aros.net> (raw)
In-Reply-To: <3F30510A.E918924B@SteelEye.com>
Paul Clements wrote:
> . . .
>
>>Except that in the error case, the send basically didn't succeed. So no
>>need to worry about recieving a reply and no race possibility in that case.
>>
>>
>
>As long as the request is on the queue, it is possible for nbd-client to
>die, thus freeing the request (via nbd_clear_que -> nbd_end_request),
>and leaving us with a race between the free and do_nbd_request()
>accessing the request structure.
>
>--
>Paul
>
>
Quite right. I missed that case in this last patch (when nbd_do_it has
returned and NBD_DO_IT is about to call nbd_clear_que [1]). Just moving
the errors increment (near the end of nbd_send_req) to within the
semaphore protected region would fix this particular case. An even
larger race window exists with the request getting free'd when
nbd-client is used to disconnect in which it calls NBD_CLEAR_QUE before
NBD_DISCONNECT [2]. In this case, moving the errors increment doesn't
help of course since the nbd_clear_queue in 2.6.0-test2 doesn't bother
to check the tx_lock semaphore anyway. I believe reference counting the
request (as you suggest) would protect against both these windows though.
It's ironic that I'd fixed both these races [1+2] a ways back in an
earlier patch and had forgotten about these cases in this last patch I
submitted. The earlier patch p6.2 against linux-2.5.73 looks about
right. By that patch, the call to clear the queue before NBD_DO_IT
returned was gone and it made sure the clear_queue functionality would
return -EBUSY if invoked when the socket wasn't NULL (and potentially
while nbd_send_req functionality could be called). Not that I'm arguing
we should roll in these ealier patches again. That would re-introduce
the compatibility break which I wouldn't want either.
Will you be working on closing the other clear-queue race also then?
Here's the comments I shared on this in one of these earlier patches
that didn't make it into the mainstream distro (from patch #7):
/*
* Don't allow queue to be cleared while device is running!
* Device must be stopped (disconnected) first. Otherwise
* clearing is meaningless & can lock up processes: it's a
* race with users who may queue up more requests after the
* clearing is done that may then never be freed till the
* system reboots or clear que is run again which just
* opens the race yet again.
*/
next prev parent reply other threads:[~2003-08-06 7:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-05 16:51 [PATCH] 2.6.0 NBD driver: remove send/recieve race for request Lou Langholtz
2003-08-05 19:37 ` Paul Clements
2003-08-05 22:48 ` Lou Langholtz
2003-08-06 0:51 ` Paul Clements
2003-08-06 7:34 ` Lou Langholtz [this message]
2003-08-08 5:02 ` Paul Clements
2003-08-08 5:27 ` Andrew Morton
2003-08-08 17:05 ` Paul Clements
2003-08-08 6:30 ` Lou Langholtz
2003-08-08 6:43 ` Andrew Morton
2003-08-08 6:59 ` Jens Axboe
2003-08-08 15:00 ` Paul Clements
2003-08-25 9:58 ` Jens Axboe
2003-08-08 16:47 ` Paul Clements
2003-08-08 20:07 ` [PATCH 2.6.0-test2-mm] nbd: fix send/receive/shutdown/disconnect races Paul Clements
2003-08-09 22:10 ` [PATCH 2.4.22-pre] nbd: fix race conditions 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=3F30AF81.4070308@aros.net \
--to=ldl@aros.net \
--cc=Paul.Clements@SteelEye.com \
--cc=akpm@osdl.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).