lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1107031121440.28411-100000@netrider.rowland.org>
Date:	Sun, 3 Jul 2011 11:29:51 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Andi Kleen <andi@...stfloor.org>
cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Dave Jones <davej@...hat.com>, <linux-scsi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <axboe@...nel.dk>, <rjw@...k.pl>,
	<linux-usb@...r.kernel.org>
Subject: Re: Linux 3.0 oopses when pulling a USB CDROM

On Sun, 3 Jul 2011, Andi Kleen wrote:

> > On my system, at least, the scsi_device's refcount dropped to 0 at the 
> > right time.  That wasn't the problem.  The NULL pointer occurs because 
> > the request_queue is used after the scsi_device has been removed from 
> > visibility; among other things, __scsi_remove_device() sets 
> > sdev->request_queue->queuedata to NULL.
> > 
> > As the comment says, this causes the request function to reject all I/O 
> > requests -- but not before trying to dereference the NULL pointer!
> 
> Your explanation completely contradicts what James wrote earlier.

Yes, it does.  I'm claiming that James was on a wrong track or looking
in the wrong direction.

> Maybe it's good if you guys come up with a common avenue of debugging
> before I try further.

It will be interesting to hear what James has to say about all this...

> > Would you like to try this patch to see if it fixes the problem?  As I 
> > said before, I'm not certain it's the best thing to do, but it worked 
> > on my system.
> 
> I can try next week.

Okay.

> Is this patch likely to fix the RCU stall?

I have no idea.  All I know about this RCU stall is what you wrote 
before, i.e., that it happened once.  No debugging information or 
anything else.  However if it happens again with the patch in place, 
we'll be in a good position to figure the cause and fix it.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ