linux-kernel - Re: 2.6.21-rc7-mm2 -- PPC link failure

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]

Date:	Thu, 26 Apr 2007 11:27:30 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Andy Whitcroft <apw@...dowen.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.21-rc7-mm2 -- PPC link failure

On Thu, 26 Apr 2007, Andy Whitcroft wrote:

> > Ok, this is a SLUB related link failure.  Am investigating if PPC simply
> > needs larger allocs and needs CONFIG_LARGE_ALLOCS, of if this is an
> > inlining issue.
> 
> Ok this is confirmed as an inlining issue.  With the compiler below on
> ppc64 we get the above link failure:
> 
>   gcc version 3.3.3 (SuSE Linux)
> 
> What seems to happen is that although the optimiser is capable of
> collapsing the kmalloc_index() call it then fails to collapse
> kmalloc_slab().  This leads to the never used reference to
> __kmalloc_size_too_large() and the link failure.  From my testing this
> seems to occur at sizes >= 32k.  At 16k all of the code collapses

Interesting. Why would that boundary be of relevance to the compiler? Some 
offset heuristics?

> correctly, at 32k it does not.  I am not entirely sure what to think at
> this point, it is cirtainly not at all clear why the 32k version fails
> and the 16k succeeds they are almost identical.

Likely a backend optimization issue.

> Either way it seems to me that assuming the optimiser will remove the
> code is perhaps over optimistic.  Perhaps it would make more sense to
> put a BUG() in here.  Though that points out the anomaly that the
> kmalloc() for constants has different semantics to that for variable values?

Yes but that has always been the case. We want to reduce kmalloc for 
constants at compile time to use the appropriate kmalloc cache. If kmalloc 
does not use a constant then we will do run time determination of the 
kmalloc cache.

The code in SLAB is easier to fold since it does not use a subroutine call.

We could simply #ifdef out the __kmalloc_sizes_too_large for ppc and let 
it fall back to __kmalloc? That would mean only that kmallocs >32k 
would require an additional determination of the kmalloc cache at run 
time.

But then how important is gcc 3.3 support?

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