public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Dave Peterson <dsp@llnl.gov>
Cc: linux-kernel@vger.kernel.org, davej@suse.de
Subject: Re: [PATCH] fixes for linked list bugs in block I/O code
Date: Thu, 8 May 2003 08:29:42 +0200	[thread overview]
Message-ID: <20030508062942.GB823@suse.de> (raw)
In-Reply-To: <200305071622.36352.dsp@llnl.gov>

On Wed, May 07 2003, Dave Peterson wrote:
> I found a couple of small linked list bugs in __make_request() in
> drivers/block/ll_rw_blk.c.  The bugs exist in both kernels
> 2.4.20 and 2.5.69.  Therefore I have made patches for both
> kernels.  The problem is that when inserting a new buffer_head
> into the linked list of buffer_head structures maintained by
> "struct request", the b_reqnext field is not initialized.
> 
> -Dave Peterson
>  dsp@llnl.gov
> 
> 
> ========== START OF 2.4.20 PATCH FOR drivers/block/ll_rw_blk.c ===========
> --- ll_rw_blk.c.old     Wed May  7 15:54:58 2003
> +++ ll_rw_blk.c.new     Wed May  7 15:58:07 2003
> @@ -973,6 +973,7 @@
>                                 insert_here = &req->queue;
>                                 break;
>                         }
> +                       bh->b_reqnext = req->bhtail->b_reqnext;

This is convoluted nonsense, bhtail->b_reqnext is NULL by definition. So
a simple

	bh->b_reqnext = NULL;

is much clearer.

>                         req->bhtail->b_reqnext = bh;
>                         req->bhtail = bh;
>                         req->nr_sectors = req->hard_nr_sectors += count;
> @@ -1061,6 +1062,7 @@
>         req->waiting = NULL;
>         req->bh = bh;
>         req->bhtail = bh;
> +       bh->b_reqnext = NULL;
>         req->rq_dev = bh->b_rdev;
>         req->start_time = jiffies;
>         req_new_io(req, 0, count);

Bart already covered why 2.5 definitely does not need it. I dunno what
to say for 2.4, to me it looks like a BUG if you pass in a buffer_head
with uninitialized b_reqnext. Why should that member be any different?

In fact, from where did you see this buffer_head coming from? Who is
submitting IO on a not properly inited bh? To me, that sounds like not a
block layer bug but an fs bug.

-- 
Jens Axboe


  parent reply	other threads:[~2003-05-08  6:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-07 23:22 [PATCH] fixes for linked list bugs in block I/O code Dave Peterson
2003-05-07 23:42 ` Bartlomiej Zolnierkiewicz
2003-05-08  0:09   ` Dave Peterson
2003-05-08  0:26     ` Bartlomiej Zolnierkiewicz
2003-05-08  0:38       ` Dave Peterson
2003-05-08  1:17         ` Bartlomiej Zolnierkiewicz
2003-05-08 17:47           ` Dave Peterson
2003-05-08  6:29 ` Jens Axboe [this message]
2003-05-08 18:06   ` Dave Peterson

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=20030508062942.GB823@suse.de \
    --to=axboe@suse.de \
    --cc=davej@suse.de \
    --cc=dsp@llnl.gov \
    --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