All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: James.Bottomley@HansenPartnership.com, jens.axboe@oracle.com,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 2/3] block: unexport blk_rq_append_bio
Date: Thu, 12 Feb 2009 11:14:02 +0200	[thread overview]
Message-ID: <4993E85A.20805@panasas.com> (raw)
In-Reply-To: <20090212174124S.fujita.tomonori@lab.ntt.co.jp>

FUJITA Tomonori wrote:
> On Thu, 12 Feb 2009 10:24:42 +0200
> Boaz Harrosh <bharrosh@panasas.com> wrote:
> 
>> FUJITA Tomonori wrote:
>>> On Wed, 11 Feb 2009 19:55:31 +0200
>>> Boaz Harrosh <bharrosh@panasas.com> wrote:
>>> static void _abort_unexecuted_bios(struct request *rq)
>>> {
>>> 	struct bio *bio;
>>>
>>> 	while ((bio = rq->bio) != NULL) {
>>> 		rq->bio = bio->bi_next;
>>> 		bio_endio(bio, 0);
>>> 	}
>>> }
>>>
>> No TOMO! The above is because I can start mapping a request even with simple map_kern
>> and then fail and do not execute the request. If so, when I do a put_request() with a
>> bio I'm leaking the bio. The above should be put inside put_request() so not
>> to leak bios, but until then It's here.
>>
>> It has nothing to do with our discussion.
> 
> Seem that you don't understand what I talk about (and James, I think).
> 
> Of course, I understand the reason why you need that function.
> 
> The point is that OSD should not know how a request links bios.
> 
> OSD ULD should focus on OSD protocol processing. It should not know
> the details of requests, bio, etc. OSD ULD should use the proper
> helper functions of the block layer if OSD ULD uses the block layer
> service.
> 

What? I'm talking about a BUG, here. What do you suggest that I leak bios
until a fix to block is accepted?

And again this is unrelated. Even if I do exactly as you suggest which is
use block API minus append_bio I still have that BUG. That must be fixed.

Please stop talking about above code. This is a different thread, unrelated
to blk_rq_append_bio() removal.

> 
> OSD ULD should focus on OSD protocol processing.

Which is what it does exactly. You ask me to interfere at OSD level and
set policy on memory structures. What I did is let osd_write/read just be
a transparent pipe between the upper layer FS code and the low level block
layer. Proof of that, any kind of implementation you suggested is that much
more code at OSD level? Today it is dead simple.

Boaz

  reply	other threads:[~2009-02-12  9:14 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-13 16:23 [PATCH 0/3] remove scsi_req_map_sg FUJITA Tomonori
2008-12-13 16:23 ` [PATCH 1/3] " FUJITA Tomonori
2008-12-13 16:23   ` [PATCH 2/3] block: unexport blk_rq_append_bio FUJITA Tomonori
2008-12-13 16:23     ` [PATCH 3/3] block: unexport bio_add_pc_page FUJITA Tomonori
2009-02-10 17:43     ` [PATCH 2/3] block: unexport blk_rq_append_bio James Bottomley
2009-02-10 18:19       ` James Bottomley
2009-02-11  0:21         ` FUJITA Tomonori
2009-02-11  8:17         ` Boaz Harrosh
2009-02-11  8:19           ` Boaz Harrosh
2009-02-11  9:15           ` Boaz Harrosh
2009-02-11 14:32             ` FUJITA Tomonori
2009-02-11 14:52               ` Boaz Harrosh
2009-02-11 15:01                 ` FUJITA Tomonori
2009-02-11 15:07                   ` Boaz Harrosh
2009-02-11 15:21                     ` FUJITA Tomonori
2009-02-11 15:41                       ` Boaz Harrosh
2009-02-11 16:04                         ` FUJITA Tomonori
2009-02-11 16:30                           ` James Bottomley
2009-02-11 17:55                             ` Boaz Harrosh
2009-02-12  1:30                               ` FUJITA Tomonori
2009-02-12  8:24                                 ` Boaz Harrosh
2009-02-12  8:28                                   ` [RFD] blk_rq_map_pages new API Boaz Harrosh
2009-02-12  9:19                                     ` Boaz Harrosh
2009-02-12  9:50                                       ` FUJITA Tomonori
2009-02-12 10:20                                         ` FUJITA Tomonori
2009-02-12 11:34                                           ` Boaz Harrosh
2009-02-12  8:41                                   ` [PATCH 2/3] block: unexport blk_rq_append_bio FUJITA Tomonori
2009-02-12  9:14                                     ` Boaz Harrosh [this message]
2009-02-12  9:50                                       ` FUJITA Tomonori
2009-02-12 12:19                                         ` [PATCH] [RFC] block: Don't let blk_put_request leak BIOs Boaz Harrosh
2009-02-12 13:49                                           ` Boaz Harrosh
2009-02-12 13:56                                             ` Boaz Harrosh
2009-02-12 17:27                                               ` [PATCH 1/2] " Boaz Harrosh
2009-02-12 17:30                                                 ` [PATCH 2/2] [RFC] libosd: Don't let osd abuse block internals, now that it's fixed Boaz Harrosh
2009-02-12 14:48                               ` [PATCH 2/3] block: unexport blk_rq_append_bio James Bottomley
2009-02-12 16:51                                 ` Boaz Harrosh
2008-12-15  7:28 ` [PATCH 0/3] remove scsi_req_map_sg Jens Axboe
2008-12-18  8:14   ` FUJITA Tomonori

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=4993E85A.20805@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@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.