On Fri, Oct 02, 2015 at 03:09:33PM +0200, Johannes Thumshirn wrote:
> Having the list_move() outside of the host_lock was purely by
> accident. Interestingly the stressing didn't mind it. But yes you're
> right, __scsi_remove_target() should be made host_lock() save for being
> called under the hos
Christoph Hellwig writes:
>> -list_for_each_entry(starget, &shost->__targets, siblings) {
>> +list_for_each_entry_safe(starget, tmp, &shost->__targets, siblings) {
>> if (starget->state == STARGET_DEL)
>> continue;
>> if (starget->dev.parent
> - list_for_each_entry(starget, &shost->__targets, siblings) {
> + list_for_each_entry_safe(starget, tmp, &shost->__targets, siblings) {
> if (starget->state == STARGET_DEL)
> continue;
> if (starget->dev.parent == dev || &starget->dev == d
On 10/02/2015 10:21 AM, Johannes Thumshirn wrote:
> Removing a SCSI target via scsi_remove_target() suspected to be racy. When a
> sibling get's removed from the list it can occassionly happen that one CPU is
> stuck endlessly looping around this code block
>
> list_for_each_entry(starget, &shost-
Removing a SCSI target via scsi_remove_target() suspected to be racy. When a
sibling get's removed from the list it can occassionly happen that one CPU is
stuck endlessly looping around this code block
list_for_each_entry(starget, &shost->__targets, siblings) {
if (starget->state == STARGE
5 matches
Mail list logo