On Thu, Dec 05, 2013 at 02:52:34PM -0800, Kent Overstreet wrote:
> that's a null pointer deref; if Matthias could get the exact line number it
> happened on we could tell what variable was null. I _think_ it's *sg because
> it's running off the end of the scatterlist; if that's the case (and you should
> verify that that is what's happening, then what's going on is bcache is sending
> down a bio larger than what the device expects.
found the kernel config value CONFIG_DEBUG_BUGVERBOSE, tried again with
3.12.3 and 3.13-rc3. The backtrace now spells the line number:
kernel BUG at drivers/scsi/scsi_lib.c:1048!
1028 static int scsi_init_sgtable(struct request *req, struct scsi_data_buffer *sdb,
1029 gfp_t gfp_mask)
1030 {
1031 int count;
1032
1033 /*
1034 * If sg table allocation fails, requeue request later.
1035 */
1036 if (unlikely(scsi_alloc_sgtable(sdb, req->nr_phys_segments,
1037 gfp_mask))) {
1038 return BLKPREP_DEFER;
1039 }
1040
1041 req->buffer = NULL;
1042
1043 /*
1044 * Next, walk the list, and fill in the addresses and sizes of
1045 * each segment.
1046 */
1047 count = blk_rq_map_sg(req->q, req, sdb->table.sgl);
1048 BUG_ON(count > sdb->table.nents);
1049 sdb->table.nents = count;
1050 sdb->length = blk_rq_bytes(req);
1051 return BLKPREP_OK;
1052 }
Regards
Matthias
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
