public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Andrew Morton <akpm@digeo.com>
Cc: alan@lxorguk.ukuu.org.uk, marcelo@conectiva.com.br,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.4.21-pre7 ide request races
Date: Mon, 14 Apr 2003 12:17:47 +0200	[thread overview]
Message-ID: <20030414101747.GR9776@suse.de> (raw)
In-Reply-To: <20030414030751.7bf17b04.akpm@digeo.com>

On Mon, Apr 14 2003, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > We've had some problems with request corruption on IDE in the past, IBM
> > traced these to stack corruption. In various places, the IDE code does
> > something ala:
> > 
> > submission:
> > 	struct request rq;
> > 
> > 	...
> > 	ide_do_drive_cmd(drive, &rq, ide_wait);
> > 
> > ide_end_request:
> > 	...
> > 	blkdev_release_request()
> > 
> > which works fine, as long as the stack persists for the
> > blkdev_release_request() call, but it may not if the task has already
> > exited (CPU0 may be waiting in ide_do_drive_cmd(), CPU1 gets the
> > completion interrupt, task is woken, and exits, CPU0 now calls
> > blkdev_release_request()). The result is random stack corruption (or
> > request list corruption, rq->q may have been scrippled!), not good.
> > 
> 
> Those locally allocated requests are foul, and the patch is a good cleanup,
> but is a simpler fix more appropriate?
> 
> The bug is in end_that_request_last(), yes?
> 
> void end_that_request_last(struct request *req)
> {
> 	if (req->waiting != NULL)
> 		complete(req->waiting);
> 	req_finished_io(req);
> 
> 	blkdev_release_request(req);
> }
> 
> Wouldn't it be simpler to just do:
> 
> void end_that_request_last(struct request *req)
> {
> 	struct completion *c = req->waiting;
> 
> 	req_finished_io(req);
> 	blkdev_release_request(req);
> 	if (c)
> 		complete(c);
> }
> 
> 
> I vaguely seem to remember being told months ago why this wasn't right ;)

How would that solve the problem? The request could be gone even before
end_that_request_last() is run, that is the issue.

-- 
Jens Axboe


  reply	other threads:[~2003-04-14 10:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-14  9:34 [PATCH] 2.4.21-pre7 ide request races Jens Axboe
2003-04-14 10:07 ` Andrew Morton
2003-04-14 10:17   ` Jens Axboe [this message]
2003-04-14 10:23     ` Andrew Morton
2003-04-14 10:27       ` Jens Axboe
2003-04-14 10:58         ` Jens Axboe
2003-04-14 16:15         ` Mike Anderson
2003-04-14 19:02           ` Jens Axboe

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=20030414101747.GR9776@suse.de \
    --to=axboe@suse.de \
    --cc=akpm@digeo.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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