All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: James Bottomley <James.Bottomley@suse.de>
Cc: Vineet Agarwal <checkout.vineet@gmail.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	open-osd <osd-dev@open-osd.org>
Subject: Re: [PATCH 1/1] libosd: Fix blk_put_request locking again
Date: Thu, 10 Dec 2009 13:53:43 +0200	[thread overview]
Message-ID: <4B20E147.3050005@panasas.com> (raw)
In-Reply-To: <4B177E0C.60407@panasas.com>

On 12/03/2009 10:59 AM, Boaz Harrosh wrote:
> On 12/01/2009 05:36 PM, Boaz Harrosh wrote:
>>
>> So libosd has decided to sacrifice some code simplicity for the sake of
>> a clean API. One of these things is the possibility for users to call
>> osd_end_request, in any condition at any state. This opens up some
>> problems with calling blk_put_request when out-side of the completion
>> callback but calling __blk_put_request when detecting a from-completion
>> state.
>>
>> The current hack was working just fine until exofs decided to operate on
>> all devices in parallel and wait for the sum of the requests, before
>> deallocating all osd-requests at once. There are two new possible cases
>> 1. All request in a group are deallocated as part of the last request's
>>    async-done, request_queue is locked.
>> 2. All request in a group where executed asynchronously, but
>>    de-allocation was delayed to after the async-done, in the context of
>>    another thread. Async execution but request_queue is not locked.
>>
>> The solution I chose was to separate the deallocation of the osd_request
>> which has the information users need, from the deallocation of the
>> internal(2) requests which impose the locking problem. The internal
>> block-requests are freed unconditionally inside the async-done-callback,
>> when we know the queue is always locked. If at osd_end_request time we
>> still have a bock-request, then we know it did not come from within an
>> async-done-callback and we can call the regular blk_put_request.
>>
>> The internal requests were used for carrying error information after
>> execution. This information is now copied to osd_request members for
>> later analysis by user code.
>>
>> The external API and behaviour was unchanged, except now it really
>> supports what was previously advertised.
>>
>> Reported-by: Vineet Agarwal <checkout.vineet@gmail.com>
>> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
> 
> James Hi
> 
> Linus has locked the 2.6.32 Kernel. I absolutely must have this patch
> submitted in this merge window. The all of exofs patches depend on it.
> Please submit ASAP
> 
> Boaz
> 

James I'm reminding you of this patch.
If you do not have another round of patches for the merge window, then please
submit it through rc-fixes. It is a very important bug-fix for exofs.

Thanks
Boaz

  reply	other threads:[~2009-12-10 11:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-01 15:30 [PATCH 0/1] libosd bug fixing Boaz Harrosh
2009-12-01 15:36 ` [PATCH 1/1] libosd: Fix blk_put_request locking again Boaz Harrosh
2009-12-03  8:59   ` Boaz Harrosh
2009-12-10 11:53     ` Boaz Harrosh [this message]
     [not found] ` <425904320912020131k46b34cdfmfa64a25196a5b44e@mail.gmail.com>
2009-12-02  9:35   ` [PATCH 0/1] libosd bug fixing Vineet Agarwal
2009-12-02 17:16   ` Boaz Harrosh

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=4B20E147.3050005@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@suse.de \
    --cc=checkout.vineet@gmail.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=osd-dev@open-osd.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.