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

Chris Webb chris at arachsys.com
Wed Apr 8 13:51:52 CEST 2009

Guessing that this bug might be the same as the one I'm seeing, I've reproduced
it here with tgtd running under gdb. In my case, the drive actually vanished
completely underneath the md because it got so upset! I see a null pointer
dereference in bs_rdwr_request():

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to LWP 6871]
  bs_rdwr_request (cmd=0x8077ce8) at bs_rdwr.c:98
  98                              if (((cmd->scb[0] != WRITE_6) && (cmd->scb[1] & 0x8)) ||
  (gdb) p cmd
  $1 = (struct scsi_cmd *) 0x8077ce8
  (gdb) p cmd->scb
  $2 = (uint8_t *) 0x0

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.

This isn't code I'm at all familiar with, so I hesitate to suggest what might
be going on.


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

More information about the stgt mailing list