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 |