Re: tgtd segfault with software RAID, hard resetting link

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

 



Chris Webb <chris@xxxxxxxxxxxx> writes:

> Tomasz Chmielewski <mangoo@xxxxxxxx> writes:
> 
> > I tested your patch a bit and with it applied, I could not reproduce the  
> > segfault any more.
> >
> > Which is good.
> 
> Great! I should stress though that it's not the correct fix, it's just a
> and-aid for the problem of scsi_cmd structs being cleared up underneath
> threads that are blocked on an IO operation, which shouldn't really be
> happening in the first place.

PS Another excellent way to trigger it is by doing a very large buffered
disk write on the target machine whilst tgtd has write-caching off. An
unbuffered write from tgtd can't complete until the large buffered write has
been flushed. If the time taken to do this is longer than 30s or so (which
it easily can be given large RAM), tgtd will crash when the write returns
after the target has already given up on the connection. I crashed tgtd
several times this way today.

Cheers,

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

[Index of Archives]     [Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]

  Powered by Linux