[1778] in linux-scsi channel archive

home help back first fref pref prev next nref lref last post

Re: Kernel stack corruption when using xxxx_command()

daemon@ATHENA.MIT.EDU (Eric Youngdale)
Tue Apr 29 08:18:02 1997

Date: 	Tue, 29 Apr 1997 08:10:07 -0400
From: Eric Youngdale <eric@andante.jic.com>
To: campbell@tirian.che.curtin.edu.au
CC: linux-scsi@vger.rutgers.edu
In-reply-to: <97Apr28.230155-0400_edt.971134-21916+1283@vger.rutgers.edu>
	(campbell@tirian.che.curtin.edu.au)


>Also I have found that if the done() function is called during the 
>####_queuecommand() processing that this also causes stack 
>corruption. ie: done() must be called after returning from the 
>relevant ####_queuecommand() request and not before.

	Yeah, you probably get the following situation that leads to
kernel stack overflow:

	Command is queued (a large number of disk writes, for
example).  Part of this is taken as the first command, and...
	Queueed to the device.  Since you are not using the queue variant,
it will wait until the command is done.
	When the command completes, it will call the completion
routines which will look to see if there are more commands to be queued.
	If there are, then we queue it.

	You will notice that nowhere in here do we come up for air, so
it effectively means that the stack just grows deeper and deeper until
either the kernel crashes or it runs out of commands to be queued.

	The real solution is to fix the problem wiht the queuecommand
variant.  I could tell you how to fix the other one, but I keep
thinking that I would like to completely remove the non-queued variant
from the code base completely.  One of these days, I may even start to
do it.

-Eric


home help back first fref pref prev next nref lref last post