All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: linux-kernel@vger.kernel.org, dm-crypt@saout.de
Subject: Re: [PATCH?] make __bio_add_page check q->max_hw_sectors
Date: Sun, 10 Oct 2004 10:14:16 +0200	[thread overview]
Message-ID: <20041010081412.GA14636@suse.de> (raw)
In-Reply-To: <20041010115004.A5282@freya>

On Sun, Oct 10 2004, Adam J. Richter wrote:
> 	On an dm-crypt partiton on an IDE disk, 2.6.9-rc3 and
> 2.6.9-rc3-bk9 repeatedly generate the following error, which
> does not occur in 2.6.9-rc1:
> 
> 	bio too big for device dm-0 (256 > 255)
> 
> 	The stack trace looked something like this:
> 
> submit_bio
> mpage_bio_submit
> mpage_readpages
> readpages
> do_page_cache_readahead
> filemap_nopage
> do_no_page
> handle_mm_fault
> 
> 	Around 2.6.9-rc3, a new field q->max_hw_sectors was
> added to struct request_queue.  I was able to make this
> problem disappear by the following patch, which adds a
> check of this new field to __bio_add_page.  (I've edited
> this patch to hide other differences in my fs/bio.c, so
> it may be necessary to apply it by hand if patch fails.)
> 
> 	I do not understand the intended difference between
> the new max_hw_sectors field and max_sectors, so it is unclear
> to me if it is a bug that my dm-crypt request_queue has
> q->max_hw_sectors < q->max_sectors.  If q->max_hw_sectors
> is supposed to be guaranteed to be greater than or equal
> to q->max_sectors, then the real bug is elsewhere and my
> patch is unnecessary.

That's exactly correct, ->max_sectors must never be bigger than
max_hw_sectors, that is the real bug.

-- 
Jens Axboe


  reply	other threads:[~2004-10-10  8:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-10 18:50 [PATCH?] make __bio_add_page check q->max_hw_sectors Adam J. Richter
2004-10-10  8:14 ` Jens Axboe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-10-11  2:29 Adam J. Richter

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=20041010081412.GA14636@suse.de \
    --to=axboe@suse.de \
    --cc=adam@yggdrasil.com \
    --cc=dm-crypt@saout.de \
    --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 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.