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
next prev parent 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 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.