linux-kernel - Re: Linux 2.6.32.55

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]

Date:	Sat, 23 Jun 2012 22:57:34 +0200
From:	Willy Tarreau <w@....eu>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, lwn@....net,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: Linux 2.6.32.55

Hi Jiri,

On Fri, Jun 22, 2012 at 11:33:28PM +0200, Jiri Slaby wrote:
> On 06/22/2012 11:18 PM, Willy Tarreau wrote:
> >> Given nobody noticed till now, I would incline to drop that patch from
> >> 2.6.32 series. Opinions?
> > 
> > Which one would you drop then ? You got me lost now. I mean, since you've
> > been the only one to notice an issue, I have no problem with following you
> > on the best way to fix it but I need to understand what you want then :-)
> 
> Ok, now I spent some time to look into that.

thank you.

> I thought suse does not need the original patch (PNP: work around Dell
> 1536/1546 BIOS MMCONFIG bug that breaks USB) as we do not support
> CONFIG_AMD_NB. But in 2.6.32.55, it is named CONFIG_K8_NB. So actually
> we need it.
> 
> There are two problems with the backport:
> * missing amd_get_mmconfig_range (added by 24d25dbfa6)

Indeed I can see it now. Thanks for the pointer to the patch.

> * used wrong names: CONFIG_AMD_NB and asm/amd_nb.h
>
> The latter can be fixed in two ways:
> * easier: change CONFIG_AMD_NB to CONFIG_K8_NB and asm/amd_nb.h to
> asm/k8.h (obviously, there will be no "upstream commit" for that)

OK I can see it in quirks.c. Indeed, it looks like this is the way to
go. I'm not opposed to merging it even without upstream commit since
it's a fix for a regression we introduced during a backport. So that's
fine.

> * maybe harder: backport 23ac4ae827 including dependencies (I haven't
> looked if there are any)

I'd rather avoid backporting such changes into stable when the fix is
obvious.

Thanks for these precisions, it's clear to me now. I'm queuing it.

Cheers,
Willy

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