Current qc_defer implementation may lead to infinite recursion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tejun,

due to your commit 31cc23b34913bc173680bdc87af79e551bf8cc0d libata now
sets max_host_blocked and max_device_blocked to 1 for all devices it
manages. Under certain conditions this may lead to system lockups due to
infinite recursion as I have explained to James on the scsi list (kept
you cc-ed). James told me that it was the business of libata to make
sure that such a recursion cannot happen.

In my discussion with James I imprudently claimed that this was easy to
fix in libata. However, after giving the matter some thought, I'm not at
all sure as to what exactly should be done about it. The easy bit is
that max_host_blocked and max_device_blocked should be left alone as
long as the low level driver does not provide the ->qc_defer() callback.
But even if the driver has defined this callback, ata_std_qc_defer() for
one will not prevent this recursion on a uniprocessor, whereas things
might work out well on an SMP system due to the lock fiddling in the
scsi midlayer.

As a conclusion, the current implementation makes it imperative to leave
max_host_blocked and max_device_blocked alone on a uniprocessor system.
For SMP systems the current implementation might just be fine but even
there it might just as well be a good idea to make the adjustment
depending on ->qc_defer != NULL.

Any ideas?

Regards,

Elias
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux