Re: Current qc_defer implementation may lead to infinite recursion

[Tejun Heo <htejun@gmail.com>]

Elias Oltmanns wrote:
> Tejun Heo <htejun@gmail.com> wrote:
>> Elias Oltmanns wrote:
>>> +static int piix_qc_defer(struct ata_queued_cmd *qc)
>>> +{
>>> +	static struct ata_port *ap = NULL;
>>> +	struct ata_queued_cmd qcmd[ATA_MAX_QUEUE];
>> missing static?
> 
> Oh well, I must have been too tired already yesterday. There are a few
> more things I got wrong last time. Please see the new patch at the end
> of this email.
> 
> This time I applied the patch to 2.6.24.1 and performed a
> 
> # cat large-file > /dev/null &
> # tail -f /var/log/kern.log
> 
> and aborted once the output of dump_stack() had occurred. This proves
> that piix_qc_defer() has declined the same command 100 times in
> succession. However, this will only happen if the status of all the
> commands enqueued for one port hasn't changed in the meantime. This
> suggests to me that the threads scheduled for command execution and
> completion aren't served for some reason. Any ideas?

Blocked counts of 1 will cause busy looping because when blk_run_queue()
returns because it's recursing too deep, it schedules unplug work right
away, so it will easily loop 100 times.  Max blocked counts should be
adjusted to two (needs some testing before actually submitting the
change).  But that still shouldn't cause any lock up.  What happens if
you remove the 100 times limit?  Does the machine hang on IO?

Thanks.


-- 
tejun