Re: [bug] block subsystem related crash with latest -git

[Jens Axboe <jens.axboe@oracle.com>]

On Wed, Oct 17 2007, Linus Torvalds wrote:
> 
> 
> On Wed, 17 Oct 2007, Jens Axboe wrote:
> > 
> > For the chain elements - yes, definitely! But we also want to clear dma
> > mapping output values, at least sparc64 wants that. You could argue that
> > the IOMMU code should be fixed up, but I don't think we should mix the
> > two.
> > 
> > So we need the memset() in blk_rq_map_sg() AS WELL AS the initial sg
> > table clear. I'm not arguing about the latter, we clearly do need that.
> 
> I still don't see your argument.
> 
> The SG table is *already*zeroed*.
> 
> The fact that output values will be changed later is irrelevant. They 
> haven't been changed *before* - or at least you haven't given a reasonable 
> explanation for why they should have.
> 
> So explain to me why the memset() in blk_rq_map_sg() helps, considering 
> that the memory must have been zeroed at allocation time anyway? Tell me 
> what it is that fills any of the fields we don't already initialize, and 
> that can happen *before* that memset?

Ah ok, I see why you are confused. The SCSI case is one, it allocs and
frees the sg table each time. The entries are thus always initialized
when they end up in blk_rq_map_sg(). However, other drivers allocate one
at driver init time and use that one all the time. It needs to be
initially cleared, but it wont be cleared before each request mapping.
And that is fine, as long as we do clear entries in blk_rq_map_sg().

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/