All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.org>
To: Mark Hemment <markhe@veritas.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch] 4GB I/O, cut three
Date: Wed, 30 May 2001 15:40:34 +0200	[thread overview]
Message-ID: <20010530154034.E17136@suse.de> (raw)
In-Reply-To: <20010530152412.C17136@suse.de> <Pine.LNX.4.21.0105301431530.7153-100000@alloc>
In-Reply-To: <Pine.LNX.4.21.0105301431530.7153-100000@alloc>; from markhe@veritas.com on Wed, May 30, 2001 at 02:37:15PM +0100

On Wed, May 30 2001, Mark Hemment wrote:
> On Wed, 30 May 2001, Jens Axboe wrote:
> > On Wed, May 30 2001, Mark Hemment wrote:
> > >   This can lead to attempt_merge() releasing the embedded request
> > > structure (which, as an extract copy, has the ->q set, so to
> > > blkdev_release_request() it looks like a request which originated from
> > > the block layer).  This isn't too healthy.
> > > 
> > >   The fix here is to add a check in __scsi_merge_requests_fn() to check
> > > for ->special being non-NULL.
> > 
> > How about just adding 
> > 
> > 	if (req->cmd != next->cmd
> > 	    || req->rq_dev != next->rq_dev
> > 	    || req->nr_sectors + next->nr_sectors > q->max_sectors
> > 	    || next->sem || req->special)
> >                 return;
> > 
> > ie check for special too, that would make sense to me. Either way would
> > work, but I'd rather make this explicit in the block layer that 'not
> > normal' requests are left alone. That includes stuff with the sem set,
> > or special.
> 
> 
>   Yes, that is an equivalent fix.
> 
>   In the original patch I wanted to keep the change local (ie. in the SCSI
> layer).  Pushing the check up the generic block layer makes sense.

Ok, so we agree.

>   Are you going to push this change to Linus, or should I?
>   I'm assuming the other scsi-layer changes in Alan's tree will eventually
> be pushed.

I'll push it, I'll do the end_that_request_first thing too.

-- 
Jens Axboe


      reply	other threads:[~2001-05-30 13:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-29 14:07 [patch] 4GB I/O, cut three Jens Axboe
2001-05-29 14:11 ` Jens Axboe
2001-05-30  9:43 ` Mark Hemment
2001-05-30  9:55   ` Jens Axboe
2001-05-30 10:59     ` Mark Hemment
2001-05-30 14:26       ` andrea
2001-05-30 18:42         ` Rik van Riel
2001-05-30 18:57           ` Andrea Arcangeli
2001-05-30 18:57           ` Yoann Vandoorselaere
2001-05-30 19:18             ` Andrea Arcangeli
2001-05-30 19:23               ` Rik van Riel
2001-05-30 14:00     ` Andrea Arcangeli
2001-05-30 14:06       ` Jens Axboe
2001-05-30 18:36     ` Rik van Riel
2001-05-30 13:03 ` Mark Hemment
2001-05-30 13:24   ` Jens Axboe
2001-05-30 13:37     ` Mark Hemment
2001-05-30 13:40       ` Jens Axboe [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=20010530154034.E17136@suse.de \
    --to=axboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markhe@veritas.com \
    /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.