exception in interrupt during elv_completed_request. (3.0)

DISCUSSION Dave Jones 4 participants 8 messages Aug 8, 2011 – Aug 15, 2011 Block layer

Share & tools

Dave Jones

author

2011-08-08 14:58 UTC #0 lore raw

Jens,

We got a report of a panic from a user when he plugged in his usb drive,
https://bugzilla.redhat.com/attachment.cgi?id=517141

any ideas what happened here ?

Dave

Jens Axboe

2011-08-08 15:03 UTC #1 lore raw

Quoted 6 lines · Dave Jones

Jens,
We got a report of a panic from a user when he plugged in his usb drive,
https://bugzilla.redhat.com/attachment.cgi?id=517141
any ideas what happened here ?

2.6.40?

Looks like the recent SCSI removal oopses, perhaps it happened when he yanked it instead of directly on insertion?

Signature · 1 line

Jens Axboe

Dave Jones

author

2011-08-08 15:13 UTC #2 lore raw

Quoted 9 lines · Jens Axboe

Quoted 6 lines · Dave Jones
Jens,
We got a report of a panic from a user when he plugged in his usb drive,
https://bugzilla.redhat.com/attachment.cgi?id=517141
any ideas what happened here ?
2.6.40?

it's 3.0 in all but name. didn't want to risk breaking dumb userspace in an update for older fedora releases. It does have the scsi_dispatch_cmd fix that went into 3.0.1, but otherwise block/ should be stock 3.0

Quoted 2 lines

Looks like the recent SCSI removal oopses, perhaps it happened when he yanked it instead of directly on insertion?

sorry my bad, yes, this was on device removal.

according to the user, he did everything right, and unmounted safely.
https://bugzilla.redhat.com/show_bug.cgi?id=728872

Dave

Jens Axboe

2011-08-08 15:16 UTC #3 lore raw

Quoted 7 lines · Dave Jones

Quoted 6 lines · Jens Axboe
Quoted 5 lines · Dave Jones
Jens,
We got a report of a panic from a user when he plugged in his usb drive,
https://bugzilla.redhat.com/attachment.cgi?id=517141

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
any ideas what happened here ?
2.6.40?
it's 3.0 in all but name. didn't want to risk breaking dumb userspace in an update for older fedora releases. It does have the scsi_dispatch_cmd fix that went into 3.0.1, but otherwise block/ should be stock 3.0

Quoted 7 lines

Quoted 2 lines
Looks like the recent SCSI removal oopses, perhaps it happened when he yanked it instead of directly on insertion?
sorry my bad, yes, this was on device removal.
according to the user, he did everything right, and unmounted safely.
https://bugzilla.redhat.com/show_bug.cgi?id=728872

James?

Signature · 1 line

Jens Axboe

Greg KH

2011-08-09 05:45 UTC #4 lore raw

Quoted 22 lines · Jens Axboe

Quoted 7 lines · Dave Jones
Quoted 6 lines · Jens Axboe
Quoted 5 lines · Dave Jones
Jens,
We got a report of a panic from a user when he plugged in his usb drive,
https://bugzilla.redhat.com/attachment.cgi?id=517141
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
any ideas what happened here ?
2.6.40?
it's 3.0 in all but name. didn't want to risk breaking dumb userspace in an update for older fedora releases. It does have the scsi_dispatch_cmd fix that went into 3.0.1, but otherwise block/ should be stock 3.0
OK
Quoted 3 lines
Quoted 2 lines
Looks like the recent SCSI removal oopses, perhaps it happened when he yanked it instead of directly on insertion?

Quoted 6 lines

Quoted 4 lines
sorry my bad, yes, this was on device removal.
according to the user, he did everything right, and unmounted safely.
https://bugzilla.redhat.com/show_bug.cgi?id=728872
James?

Should be resolved in 3.0.1 now.

If not, please let James, and me, know.

greg k-h

Dave Jones

author

2011-08-09 12:48 UTC #5 lore raw

Quoted 24 lines · Greg Kroah-Hartman

Quoted 23 lines · Jens Axboe
Quoted 6 lines · Dave Jones
Quoted 6 lines · Dave Jones
Quoted 5 lines
Jens,
We got a report of a panic from a user when he plugged in his usb drive,
https://bugzilla.redhat.com/attachment.cgi?id=517141
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
any ideas what happened here ?
2.6.40?
it's 3.0 in all but name. didn't want to risk breaking dumb userspace in an update for older fedora releases. It does have the scsi_dispatch_cmd fix that went into 3.0.1, but otherwise block/ should be stock 3.0
OK
Quoted 5 lines
Quoted 2 lines
Looks like the recent SCSI removal oopses, perhaps it happened when he yanked it instead of directly on insertion?
sorry my bad, yes, this was on device removal.

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
according to the user, he did everything right, and unmounted safely.
https://bugzilla.redhat.com/show_bug.cgi?id=728872
James?
Should be resolved in 3.0.1 now.
If not, please let James, and me, know.

Are you talking about the scsi_dispatch_cmd fix ? this is something else.

Dave

James Bottomley

2011-08-09 13:48 UTC #6 lore raw

Quoted 28 lines · Dave Jones

Quoted 27 lines · Greg Kroah-Hartman
Quoted 26 lines · Jens Axboe
Quoted 6 lines · Dave Jones
Quoted 6 lines · Dave Jones
Quoted 5 lines
Jens,
We got a report of a panic from a user when he plugged in his usb drive,
https://bugzilla.redhat.com/attachment.cgi?id=517141
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
any ideas what happened here ?
2.6.40?
it's 3.0 in all but name. didn't want to risk breaking dumb userspace in an update for older fedora releases. It does have the scsi_dispatch_cmd fix that went into 3.0.1, but otherwise block/ should be stock 3.0
OK
Quoted 7 lines
Quoted 2 lines
Looks like the recent SCSI removal oopses, perhaps it happened when he yanked it instead of directly on insertion?
sorry my bad, yes, this was on device removal.
according to the user, he did everything right, and unmounted safely.
https://bugzilla.redhat.com/show_bug.cgi?id=728872

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
James?
Should be resolved in 3.0.1 now.
If not, please let James, and me, know.
Are you talking about the scsi_dispatch_cmd fix ? this is something else.

I'm not so sure ... it looks like a stray block put coming after queue teardown to me. elevator_exit() will NULL e->ops but blk_put_request() uses it unconditionally.

That's more a fix like this, isn't it?

James

---

block/elevator.c +1 -1

index a3b64bc..de4bde9 100644
@@ -812,7 +812,7 @@ void elv_completed_request(struct request_queue *q, struct request *rq)
 	 */
 	if (blk_account_rq(rq)) {
 		q->in_flight[rq_is_sync(rq)]--;
-		if ((rq->cmd_flags & REQ_SORTED) &&
+		if ((rq->cmd_flags & REQ_SORTED) && e->ops &&
 		    e->ops->elevator_completed_req_fn)
 			e->ops->elevator_completed_req_fn(q, rq);
 	}

Dave Jones

author

2011-08-15 17:48 UTC #7 lore raw

Quoted 31 lines · James Bottomley

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
Looks like the recent SCSI removal oopses, perhaps it happened when he yanked it instead of directly on insertion?
sorry my bad, yes, this was on device removal.
according to the user, he did everything right, and unmounted safely.
https://bugzilla.redhat.com/show_bug.cgi?id=728872
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
James?
Should be resolved in 3.0.1 now.
If not, please let James, and me, know.
Are you talking about the scsi_dispatch_cmd fix ? this is something else.
I'm not so sure ... it looks like a stray block put coming after queue teardown to me. elevator_exit() will NULL e->ops but blk_put_request() uses it unconditionally.
That's more a fix like this, isn't it?
James
---
block/elevator.c +0 -0
index a3b64bc..de4bde9 100644

block/elevator.c void elv_completed_request(struct request_queue *q, struct request *rq) · line 818

Quoted 8 lines

block/elevator.c +1 -1

@@ -812,7 +812,7 @@ void elv_completed_request(struct request_queue *q, struct request *rq)
 	 */
 	if (blk_account_rq(rq)) {
 		q->in_flight[rq_is_sync(rq)]--;
-		if ((rq->cmd_flags & REQ_SORTED) &&
+		if ((rq->cmd_flags & REQ_SORTED) && e->ops &&
 		    e->ops->elevator_completed_req_fn)
 			e->ops->elevator_completed_req_fn(q, rq);
 	}

I did a build with this change for the user seeing the problem. Apparentely, it didn't change anything.

Dave