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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.0.999.0710171156060.26902@woody.linux-foundation.org>
Date:	Wed, 17 Oct 2007 11:58:14 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jens Axboe <jens.axboe@...cle.com>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [bug] block subsystem related crash with latest -git

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?

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