[stgt] tgtd segfault with software RAID, hard resetting link

[Tomasz Chmielewski]

Chris Webb schrieb:
> Chris Webb <chris at arachsys.com> writes:
> 
>>> I see a null pointer dereference in bs_rdwr_request():
> [...]
>>> What's odd is that switch(cmd->scb[0]) didn't fail back on line 70, but was
>>> valid and equal to WRITE_* or we wouldn't have got there. length and ret are
>>> both 524288 here for what it's worth. I tried using a device mapper zero target
>>> becoming error target, but couldn't reproduce the segfault with this.
> [...]
>> I've now also seen a segfault from a similar null pointer dereference at line
>> 125, in the dprintf, following a read from a hanging md device:
> 
> Given that both of these look like the cmd struct being cleared up (client
> disconnect?) while a read/write is hanging waiting for a backing device, and
> then the cleared struct being used when the io returns, I've papered over
> the cracks with the following hideous hack to avoid the null pointer
> dereference when printing messages and so on. It's clearly nothing like the
> right fix, though.

Hi Chris,

I tested your patch a bit and with it applied, I could not reproduce the 
segfault any more.

Which is good.


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