public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Peterson <dsp@llnl.gov>
To: Jens Axboe <axboe@suse.de>
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 11:06:38 -0700	[thread overview]
Message-ID: <200305081106.38002.dsp@llnl.gov> (raw)
In-Reply-To: <20030508062942.GB823@suse.de>

On Wednesday 07 May 2003 11:29 pm, Jens Axboe wrote:
> This is convoluted nonsense, bhtail->b_reqnext is NULL by definition. So
> a simple
>
> 	bh->b_reqnext = NULL;
>
> is much clearer.

Ok, that's fine with me.  Setting it explicitly to NULL is also correct
and perhaps a bit more clear.

> >                         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?

Ok, agreed that 2.5 does not need the patch.

> 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.

I would argue that __make_request() is where the insertion of the buffer_head
into the request structure is performed, and setting the b_reqnext field of
the buffer_head to its proper value is an integral part of performing the
insertion.  Why not keep all of the insertion logic in one place rather than
distribuing it throughout the code and requiring all callers of
__make_request() to remember to initialize b_reqnext?  Localizing the
insertion logic makes the code clearer, more compact, and easier to maintain.

-Dave

      reply	other threads:[~2003-05-08 17:54 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
2003-05-08 18:06   ` Dave Peterson [this message]

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=200305081106.38002.dsp@llnl.gov \
    --to=dsp@llnl.gov \
    --cc=axboe@suse.de \
    --cc=davej@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox