[GIT PULL] A minor amd64_edac fix for 3.13

[GIT PULL] A minor amd64_edac fix for 3.13

[Borislav Petkov]

Hi Linus,

please pull this one minor thing which has been lying around since
forever... (at least it feels like it - I almost forgot about it :-)).

Thanks.

--
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:

  Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_for_3.13

for you to fetch changes up to c3e511e4c4d9cb962976f63d37816ff8e8efacc5:

  amd64_edac: Remove superfluous condition check. (2013-09-19 09:55:20 +0200)

----------------------------------------------------------------
A minor correctness fix.

----------------------------------------------------------------
Aravind Gopalakrishnan (1):
      amd64_edac: Remove superfluous condition check.

 drivers/edac/amd64_edac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 3c9e4e98c651..bbd1913ce27c 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -1576,7 +1576,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt *pvt, unsigned range,
 					     num_dcts_intlv, dct_sel);
 
 	/* Verify we stay within the MAX number of channels allowed */
-	if (channel > 4 || channel < 0)
+	if (channel > 4)
 		return -EINVAL;
 
 	leg_mmio_hole = (u8) (dct_cont_base_reg >> 1 & BIT(0));

-- 
Regards/Gruss,
    Boris.

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

Re: [GIT PULL] A minor amd64_edac fix for 3.13

[Linus Torvalds]

[ 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. ]

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

             Linus


On Sun, Nov 10, 2013 at 4:26 AM, Borislav Petkov <bp@alien8.de> wrote:
> Hi Linus,
>
> please pull this one minor thing which has been lying around since
> forever... (at least it feels like it - I almost forgot about it :-)).
>
> Thanks.
>
> --
> The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
>
>   Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_for_3.13
>
> for you to fetch changes up to c3e511e4c4d9cb962976f63d37816ff8e8efacc5:
>
>   amd64_edac: Remove superfluous condition check. (2013-09-19 09:55:20 +0200)
>
> ----------------------------------------------------------------
> A minor correctness fix.
>
> ----------------------------------------------------------------
> Aravind Gopalakrishnan (1):
>       amd64_edac: Remove superfluous condition check.
>
>  drivers/edac/amd64_edac.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 3c9e4e98c651..bbd1913ce27c 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -1576,7 +1576,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt *pvt, unsigned range,
>                                              num_dcts_intlv, dct_sel);
>
>         /* Verify we stay within the MAX number of channels allowed */
> -       if (channel > 4 || channel < 0)
> +       if (channel > 4)
>                 return -EINVAL;
>
>         leg_mmio_hole = (u8) (dct_cont_base_reg >> 1 & BIT(0));
>
> --
> Regards/Gruss,
>     Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --

Re: [GIT PULL] A minor amd64_edac fix for 3.13

[Borislav Petkov]

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

Re: [GIT PULL] A minor amd64_edac fix for 3.13

[Borislav Petkov]

On Sat, Nov 16, 2013 at 02:50:49AM -0800, Linus Torvalds wrote:
> As far as I can tell, only that one email had gotten caught by the
> spam filter. So it may be something in the body of the email itself,
> although I don't really see what that could be either..

Right.

> It happens occasionally, although it doors seem to happen much more to
> certain particular people than to others.

AFAIR, it had happened once before with a pull request a couple of
kernel releases back. Oh well, I will start sending the pull requests
from suse.de as their range is statically allocated and this should take
care of the dynamic IP range issues.

> The most common reason seems to be that your email provide is
> associated with spam, sometimes just because of a shared ISP.

Sure, it is one: https://www.hetzner.de/

> It is hard to tell with gmail, since it probably uses heuristics very
> much like spamassassin, but doesn't make the internal scores available
> (to avoid gaming them, I'm sure). So there are likely multiple small
> triggers that combine, rather than one single reason. With "possibly
> bad ISP" probably just being one of them..

Right, I'm adding Frank who takes care of it, just so he's aware.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

Re: [GIT PULL] A minor amd64_edac fix for 3.13

[Linus Torvalds]

On Sat, Nov 16, 2013 at 3:12 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Sat, Nov 16, 2013 at 02:50:49AM -0800, Linus Torvalds wrote:
>
>> The most common reason seems to be that your email provide is
>> associated with spam, sometimes just because of a shared ISP.
>
> Sure, it is one: https://www.hetzner.de/

Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of
complaints. See for example

   http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/

which puts it #2 _worldwide_ in September. I have no idea how accurate
that is, but..

I would suggest everybody who uses hetzner actively drop them, and
talk publicly about *why* they drop them. Your business may not be all
that lucrative to them (compared to the spam), but still..

              Linus

Re: [GIT PULL] A minor amd64_edac fix for 3.13

[Borislav Petkov]

On Sat, Nov 16, 2013 at 10:10:05AM -0800, Linus Torvalds wrote:
> Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of
> complaints. See for example
> 
>    http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/

Yowza, this is just great! :-(

> which puts it #2 _worldwide_ in September. I have no idea how accurate
> that is, but..

And they were #3 in August. So a steady rise ...

> I would suggest everybody who uses hetzner actively drop them, and
> talk publicly about *why* they drop them. Your business may not be all
> that lucrative to them (compared to the spam), but still..

Yeah, I hear they're not that great otherwise either, regardless of how
they handle (or not) spam.

@Frank, we need to have a serious talk, you and I :-)

-- 
Regards/Gruss,
    Boris.

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

Re: [GIT PULL] A minor amd64_edac fix for 3.13

[Frank Becker]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

Borislav Petkov [2013-11-16, 19:23 +0100]:
> On Sat, Nov 16, 2013 at 10:10:05AM -0800, Linus Torvalds wrote:

Hi,

> > Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of
> > complaints. See for example
> > 
> >    http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/
> 
> Yowza, this is just great! :-(
Hetzner provides root servers for money like so many other similar
companies. Some folks use that to run their own mail servers for various
reasons.
Blaming the server provider is nonsense. I've never been in contact with
the Hetzner abuse handling. Maybe that could be improved.

> > I would suggest everybody who uses hetzner actively drop them, and
> > talk publicly about *why* they drop them. Your business may not be all
> > that lucrative to them (compared to the spam), but still..
As far as I can see it is Google who filtered the pull request as SPAM by
mistake.
I'd suggest that everybody who uses Google actively drop them. ;-)

But right, I'll open a ticket with Hetzner to ask what they do to shut down
SPAMers. Let's see what their FAQ link is.


My 2 ct,

    Frank
-- 
Frank Becker <fb@alien8.de> (jabber|mail)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]

Re: [GIT PULL] A minor amd64_edac fix for 3.13

[Frank Becker]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

Linus Torvalds [2013-11-17, 00:52 +0100]:
> On Nov 16, 2013 3:34 PM, "Frank Becker" <fb@alien8.de> wrote:

Hi,

> > Blaming the server provider is nonsense.
> 
> BS.
:-) Looks like an authentic mail. Who needs crypto-signatures?

> If the service provider allows spammers, the service provider is shit. It
> really I'd that simple.
It isn't black/white and you probably know. E-mail is broken by design. Any
attempt to fix it has failed so far. It is abused.

I don't defend Hetzner here. Yes, if they made it to be ranked #2 SPAMer on
some Web page they have a problem especially considering the fact that they
are not #2 in size. I'll tell them that other customers run into a SPAM
problem if they don't mitigate that.

Still, Google made a mistake by tagging Boris mail as SPAM. As you already
wrote it probably was triggered by the content filter. They don't tell. To
get those filters right is probably impossible. BTW, I liked your idea to
tag propaganda you mentioned in some interview.

I'll leave it to this. I've wasted way too much life-time on anti-spam measures
already just because I'd like to run my own mail server and can read e-mail
without other SPAM^h^h ads around it.

The real problem are those fucking parasites aka SPAMers. May they rot in hell.

Bye,

Frank
 
-- 
Frank Becker <fb@alien8.de> (jabber|mail)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]

Re: [GIT PULL] A minor amd64_edac fix for 3.13

[Borislav Petkov]

On Sun, Nov 17, 2013 at 02:22:15AM +0100, Frank Becker wrote:
> Still, Google made a mistake by tagging Boris mail as SPAM. As you
> already wrote it probably was triggered by the content filter. They
> don't tell. To get those filters right is probably impossible. BTW, I
> liked your idea to tag propaganda you mentioned in some interview.

Btw, this reminds me:

I used to have lkml subscribed to gmail and had to go into the spam
folder and regularly fish out legit lkml messages.

The culmination of this activity was me finding a @google.com employee
mail addressed to a discussion on lkml!!! And he was sending from their
own range, of course.

So yes, while hetzner possibly doesn't take care of spammers or doesn't
do so in timely manner (if I'd have to guess, they're on that money
saving trip *every* fucking company is on right now) I can't help but
wonder at the arrogance of gmail's decision to mark certain messages as
spam without saying why so as to senders be able to fix that.

And they even manage to shoot their own foot in the process.

So Linus, get Linux Foundation to write a nice search interface for mail
so that you can move back to community servers. Better yet, write one
yourself - I know you're good at writing your own stuff. We'll gladly
help out if you need people.

:-) :-)

-- 
Regards/Gruss,
    Boris.

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

Re: [GIT PULL] A minor amd64_edac fix for 3.13

[Borislav Petkov]

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