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] [day] [month] [year] [list]
Message-ID: <20131116102947.GC18306@pd.tnic>
Date:	Sat, 16 Nov 2013 11:29:47 +0100
From:	Borislav Petkov <bp@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-edac <linux-edac@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [GIT PULL] A minor amd64_edac fix for 3.13

And just to test whether you're getting emails from me, I'll send this
one again from my other mail address to try to maximize the probability
of some version actually reaching you :-)

On Fri, Nov 15, 2013 at 06:02:59PM -0800, Linus Torvalds wrote:
> [ This was in my spam collection. I don't quite know why, but it might
> signify problems with your email setup. Quite often, when gmail is
> unhappy about kernel developer emails, it's been because their email
> provider ends up doing something odd.
> 
> But the headers actually have "spf=pass" and "dkim=pass", so it's
> nothing obvious. ]

Hmm, strange. Does this mean, you don't get other emails from my email
address or only this pull request? Say, do you have this one, for
example:

http://marc.info/?l=linux-kernel&m=138442829620489&w=2

where I ask you whether you're fine with Mauro and me playing interim
EDAC maintainers?

> That said, I don't much like the patch either. The "fixed' version
> looks worse than the original. If it's an unsigned type, no extra code
> will be generated,

Yes, correct, in both cases I have here:

.L779:
        .loc 1 1579 0
        cmpb    $4, %r10b       #, alias_channel
        ja      .L859   #,
.L847:

> and if it's a signed type, it's correct. In either way, the code looks
> good, and the range test means that people reading it don't even need
> to worry about whether the type is signed or not.
>
> If this patch was written because of some f*cking broken compiler
> warning, then just tell the compiler to shut the hell up about it.
> This is a clear example of where compiler warnings are actually making
> things worse.

Yeah, no, the compiler's fine here. Dave raised the issue about not
testing unsigned's for < 0:

http://www.spinics.net/lists/kernel/msg1597525.html

And I took it because it is less code in the .c source file to look at.
But I certainly don't care all that much whether the < 0 test is there
or not as long as the produced code is identical so...

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

--
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