Re: kernel stack torture
Gerard Roudier (groudier@iplus.fr)
Wed, 14 Feb 1996 23:42:13 +0000 (GMT)
On Wed, 14 Feb 1996, Mark Hahn wrote:
> On Tue, 13 Feb 1996, Gerard Roudier wrote:
> > Imagine the following:
> > - a process initiate lots of IO requests (up to 64) asynchronously and sleep.
> > (NR_REQUESTS=64)
> > - another process try do an IO request.
> >
> > What may happen?
> > - The kernel stack of the second process (4K) may be to short if it has to
> > queue and complete recursively all the requests.
>
> but what's consuming stack space? the 'complete recursively' part
> doesn't make sense. the requests themselves don't consume stack
> space, and a completing request can't be interrupted by completing
> request.
>
>
> > With NR_REQUESTS=64 and Drew's scsi driver or ncrBsd2Linux, I get a kernel
> > stack corruption (it's an overflow) every 2 Bonnie tests.
>
> I run bonnie a lot on scsi systems, and have never seen a stack problem.
>
> > I try with NR_REQUESTS=10. I ran 10 times Bonnie without any kernel stack
> > problem.
>
> well, that's probably just because the system will go slower, since more
> processes will be sleeping, waiting for a request to become free.
> have you determined whether this corruption you see happens during
> bonnie's parallel seekers phase?
>
> > I am not quite sure, but it seems to me that the whole process of a scsi
> > command (queue, interrupt, complete) may take at least 300 bytes of kernel
> > stack. So NR_REQUESTS should not be greater than 16.
>
> I may well be missing something, but I don't see how the requests consume
> stack, and how they could all keep interrupting each other.
>
> besides, doesn't the scsi top-half actually remove requests from the
> blk.h request queue immediately?
>
bdflush code have been changed in linux-1.3.XX.
I see in this new code, that lots of calls to ll_rw_block(WRITE, ...) or
ll_rw_block(WRITEA, ...) may be done without waiting on buffers and then
the process set itself in a sleeping state.
So, up to NR_REQUESTS=64 requests may be queued for a scsi disk(s).
When an interrupt occurs, it is serviced in the context of the current process
which is obvious in the running state.
My goal is not to fix the problem, but to give informations to Linux
maintainers.
Now, what do you think about that? (Tell me if I am quite wrong)
The interrupt routine calls
rw_intr() file linux/drivers/scsi/sd.c
which calls requeue_sd_request() file linux/drivers/scsi/sd.c
which calls scsi_do_cmd() file linux/drivers/scsi/scsi.c
which calls internal_cmnd() file linux/drivers/scsi/scsi.c
which calls sti() and loop 1*HZ (10) ms
then calls restore_flags()
My hard disk has an access time of 9ms (< 10ms).
Is it possible that multiples nested interrupts will occurs during this
interval of 10 ms of interrupt enabled time?
If such events occur for the same current (running) process, its kernel stack
may overflow, because all the pending requests are recursively queued and
completed in the context of this process.
My diagnostic may be wrong but the kernel stack problem is real on my machine
even with the standard distribution of linux 1.3.XX.
I never have any problem with linux-1.2.13.
Regards, Gerard.