public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Arne Jansen <lists@die-jansens.de>
Cc: linux-scsi@vger.kernel.org
Subject: Re: reusing bios
Date: Sat, 12 Mar 2011 14:48:01 +0100	[thread overview]
Message-ID: <4D7B7991.2090305@kernel.dk> (raw)
In-Reply-To: <4D7B7636.5010206@die-jansens.de>

On 2011-03-12 14:33, Arne Jansen wrote:
> Jens Axboe wrote:
>> On 2011-03-12 10:29, Arne Jansen wrote:
>>> Hi,
>>>
>>> I'm trying to re-use struct bio after completion, including the
>>> allocated pages. Normally I re-initialize the fields bi_sector,
>>> bi_size, bi_next, bi_flags, bi_comp_cpu and bi_bdev.
>>> This works perfectly well, as long as no media errors are encountered.
>>> After a media error, all subsequent reads with this bio fail. Are
>>> there any more fields that need to get re-initialized? Or, better,
>>> is there a function to reset the bio?
>>
>> bio_init()? Sounds like you are not setting BIO_UPTODATE when resetting
>> it.
>>
> 
> bio_init does way too much, as it discards the io_vec, refcnt, destructor,
> private etc.
> I set the flags to 1 << BIO_UPTODATE, but that proved to be fatal, too, as
> it clobbers the POOL_FLAGS, which leads to an oops when the last reference
> drops. These bio-beasts are just not made to be reused. One needs way too
> much internal knowledge to reinitialize them properly.
> Therefore, I'd really like to have a call like bio_reinit, which keeps the
> io_vec and all the owners private information, but resets the parts that
> get used by the stack like bi_next. Would that make sense?

The thing is, you can't really reuse without violating the allocator
principle of finite life times. Otherwise you risk hanging the system.
If you want to reuse, the bio should come out of your own pool or
through the bio_kmalloc() interface, not from bio_alloc() with the
default pool.

So there is no reinit, as there hasn't been a good use case for that.
The fact that flags has pool information in the top bits is a sure sign
you are violating that.

-- 
Jens Axboe


  reply	other threads:[~2011-03-12 13:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-12  9:29 reusing bios Arne Jansen
2011-03-12 10:08 ` Jens Axboe
2011-03-12 13:33   ` Arne Jansen
2011-03-12 13:48     ` Jens Axboe [this message]
2011-03-12 13:58       ` Arne Jansen
2011-03-14 22:10         ` Dan Williams

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=4D7B7991.2090305@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lists@die-jansens.de \
    /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