linux-kernel - Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

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: <49BA3B05.9020906@snapgear.com>
Date:	Fri, 13 Mar 2009 20:52:53 +1000
From:	Greg Ungerer <gerg@...pgear.com>
To:	Sam Ravnborg <sam@...nborg.org>
CC:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Rob Landley <rob@...dley.net>, linux-kernel@...r.kernel.org,
	dwmw2@...radead.org, linux-next@...r.kernel.org
Subject: Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.

Sam Ravnborg wrote:
> On Fri, Mar 13, 2009 at 09:33:18AM +0100, Geert Uytterhoeven wrote:
>> On Fri, Mar 13, 2009 at 09:25, Sam Ravnborg <sam@...nborg.org> wrote:
>>> On Fri, Mar 13, 2009 at 05:04:57PM +1000, Greg Ungerer wrote:
>>>> I pretty quick time I can fix up the last couple on the above list.
>>>> But do we want to put all that change into 2.6.29-rc at this point?
>>> In general we do not want to have headers_check broken in mainline,
>> headers_check is not broken, headers_install is.
>>
>> Hmm, in some sense headers_check _is_ broken, as it doesn't notice
>> headers_install
>> installs headers that refer to other headers that are not installed...
> This is what scripts/headers_check are supposed to do - strange.
> 
>> Greg, I had a quick look at your signcontext.h and signal.h merge, and the MMU
>> part seems to be OK.
>>
>> However, some of the installed headers still have checks for CONFIG_MMU:
>>
>> param.h:#ifdef CONFIG_MMU
>> sigcontext.h:#ifndef CONFIG_MMU
>> sigcontext.h:#ifdef CONFIG_MMU
>> siginfo.h:#ifdef CONFIG_MMU
>> siginfo.h:#ifdef CONFIG_MMU
>> siginfo.h:#endif /* CONFIG_MMU */
>> swab.h:#elif defined(CONFIG_MMU)
>>
>> so these have to be added to the generic unifdef-y list (is that
>> include/asm-generic/Kbuild.asm?).

Hmmm, yes your right.

> include/asm-generic/Kbuild.asm impacts all architectures so be carefull there.
> It looks like some updates to arch/m68k/include/asm/Kbuild is needed,
> and not the generic list of files to export.
> 
> Also use og CONFIG_MMU suprises me.
> We used #ifdef __uClinux__ in the non-merged headers to avoid use
> of a CONFIG_* symbol that is not valid outside the kernel namespace.
> So if param.h in m68k uses CONFIG_MMU it is broken.

I have been trying to use CONFIG_MMU wherever possible (so for non-
exported headers), since that matches what is actually in the code
proper. I am concerned at the longer term use of __uClinux__ for
distinguishing MMU and non-MMU. I plan on switching to use a normal
m68k toolchain soon. And it won't define __uClinux__ on its own.
(I already do this on ARM for example - same toolchain on both
MMU an non-MMU).

What I have done so far is or the most part a very simple merge
of the files. I know there is room for some improvements in quite a
few of these files.

The use of CONFIG_MMU in swab.h (is this actually exported to user
space?) is not actually for code that is MMU or non-MMU. It is
actually architecture specific. Most ColdFire parts don't have the
"rolw" instruction. The condition test can be better. Geert, any
ideas on what is more appropriate here?

I can switch back to using __uClinux__ on siginfo.h and sigcontext.h.
If I am not mistaken we can't change these structures without breaking
backwards compatibility?  The sigcontext change is particularly ugly :-(

Similarly for param.h, it looks like a switch back to using
__uClinux__ for now is the only option.

Now after these fixups should I create a git branch with these header
merges in for inclusion into 2.6.29-rc?  To fix the regression we
only need to do the handful of files that Rob listed, right?

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@...pgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
--
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/