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.0710171111040.26902@woody.linux-foundation.org>
Date:	Wed, 17 Oct 2007 11:13:23 -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:
> >
> >  - remove the "memset()" you had added earlier. It's bogus. It cannot be 
> >    the right thing. If the sg list wasn't initialized correctly much 
> >    earlier, trying to initialize it late is pointless - it contains crap.
> 
> It's required to clear output members (like dma_len and so on), since
> some of the IOMU code really wants that initialized.

No it's NOT!

The whole point here is that the sg had *already* better be cleared.

If it wasn't cleared before, that's a bug regardless of anything else. So 
a memset() is guaranteed to be either a no-op or hiding another bug!

So yes, those members had better be zero. It's just that they had better 
be zero long before that memset! The memset should have been done when 
allocating the SG list.

> If you prefer the old next_sg approach to my alternative, that is fine
> with me. But we do need the memset().

Really? Explain why. Entering that code with a non-initialized SG list is 
a bug to begin with.

		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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ