| 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
| ||
|
Message-ID: <49BEDC24.6000607@snapgear.com>
Date: Tue, 17 Mar 2009 09:09:24 +1000
From: Greg Ungerer <gerg@...pgear.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
CC: Rob Landley <rob@...dley.net>, Sam Ravnborg <sam@...nborg.org>,
linux-kernel@...r.kernel.org, dwmw2@...radead.org,
linux-next@...r.kernel.org, linux-m68k@...r.kernel.org
Subject: Re: make headers_install broken for ARCH=m68k in 2.6.29-rc7.
Hi Geert,
Geert Uytterhoeven wrote:
> On Mon, Mar 16, 2009 at 21:20, Rob Landley <rob@...dley.net> wrote:
>> On Monday 16 March 2009 07:40:19 Greg Ungerer wrote:
>>> Geert Uytterhoeven wrote:
>>>> On Fri, Mar 13, 2009 at 11:52, Greg Ungerer <gerg@...pgear.com> wrote:
>>>>> 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?
>>>> The `rolw' variant is already protected by `#if defined
>>>> (__mcfisaaplus__) || defined (__mcfisac__)',
>>>> so I think you can replace the `#elif defined(CONFIG_MMU)' by a plain
>>>> `#else'. Or are there cases where you don't want to have __arch_swab32 at
>>>> all?
>>> Not all ColdFire fit into '(__mcfisaaplus__) || defined (__mcfisac__)'
>>> so #else won't be good enough. Though I suspect it is true that the
>>> older m68k varients (68328, etc) can do "rolw" - or I am I mistaken on
>>> that?
>>>
>>>>> 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 :-(
>>>> Copying the signal experts on linux-m68k...
>>>>
>>>>> 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?
>>>> Yes.
>>> Ok, I have created a git branch for this as:
>>>
>>> The following changes since commit
>>> 5bee17f18b595937e6beafeee5197868a3f74a06: Kyle McMartin (1):
>>> parisc: sba_iommu: fix build bug when CONFIG_PARISC_AGP=y
>>>
>>> are available in the git repository at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
>>> fix-includes
>>>
>>> Greg Ungerer (8):
>>> m68k: merge the non-MMU and MMU versions of param.h
>>> m68k: merge the non-MMU and MMU versions of swab.h
>>> m68k: merge the non-MMU and MMU versions of sigcontext.h
>>> m68k: merge the non-MMU and MMU versions of siginfo.h
>>> m68k: use MMU version of setup.h for both MMU and non-MMU
>>> m68k: merge the non-MMU and MMU versions of ptrace.h
>>> m68k: merge the non-MMU and MMU versions of signal.h
>>> m68k: use the MMU version of unistd.h for all m68k platforms
>>>
>>> arch/m68k/include/asm/param.h | 25 ++-
>>> arch/m68k/include/asm/param_mm.h | 22 --
>>> arch/m68k/include/asm/param_no.h | 22 --
>>> arch/m68k/include/asm/ptrace.h | 88 ++++++++-
>>> arch/m68k/include/asm/ptrace_mm.h | 80 -------
>>> arch/m68k/include/asm/ptrace_no.h | 87 --------
>>> arch/m68k/include/asm/setup.h | 377
>>> ++++++++++++++++++++++++++++++++-
>>> arch/m68k/include/asm/setup_mm.h | 376
>>> --------------------------------
>>> arch/m68k/include/asm/setup_no.h | 10 -
>>> arch/m68k/include/asm/sigcontext.h | 25 ++-
>>> arch/m68k/include/asm/sigcontext_mm.h | 19 --
>>> arch/m68k/include/asm/sigcontext_no.h | 17 --
>>> arch/m68k/include/asm/siginfo.h | 95 ++++++++-
>>> arch/m68k/include/asm/siginfo_mm.h | 92 --------
>>> arch/m68k/include/asm/siginfo_no.h | 6 -
>>> arch/m68k/include/asm/signal.h | 216 ++++++++++++++++++-
>>> arch/m68k/include/asm/signal_mm.h | 206 ------------------
>>> arch/m68k/include/asm/signal_no.h | 159 --------------
>>> arch/m68k/include/asm/swab.h | 30 +++-
>>> arch/m68k/include/asm/swab_mm.h | 16 --
>>> arch/m68k/include/asm/swab_no.h | 24 --
>>> arch/m68k/include/asm/unistd.h | 377
>>> ++++++++++++++++++++++++++++++++-
>>> arch/m68k/include/asm/unistd_mm.h | 372
>>> --------------------------------
>>> arch/m68k/include/asm/unistd_no.h | 372
>>> --------------------------------
>>> 24 files changed, 1206 insertions(+), 1907 deletions(-)
>>> delete mode 100644 arch/m68k/include/asm/param_mm.h
>>> delete mode 100644 arch/m68k/include/asm/param_no.h
>>> delete mode 100644 arch/m68k/include/asm/ptrace_mm.h
>>> delete mode 100644 arch/m68k/include/asm/ptrace_no.h
>>> delete mode 100644 arch/m68k/include/asm/setup_mm.h
>>> delete mode 100644 arch/m68k/include/asm/setup_no.h
>>> delete mode 100644 arch/m68k/include/asm/sigcontext_mm.h
>>> delete mode 100644 arch/m68k/include/asm/sigcontext_no.h
>>> delete mode 100644 arch/m68k/include/asm/siginfo_mm.h
>>> delete mode 100644 arch/m68k/include/asm/siginfo_no.h
>>> delete mode 100644 arch/m68k/include/asm/signal_mm.h
>>> delete mode 100644 arch/m68k/include/asm/signal_no.h
>>> delete mode 100644 arch/m68k/include/asm/swab_mm.h
>>> delete mode 100644 arch/m68k/include/asm/swab_no.h
>>> delete mode 100644 arch/m68k/include/asm/unistd_mm.h
>>> delete mode 100644 arch/m68k/include/asm/unistd_no.h
>>>
>>>
>>> I have only patched those files that I saw mentioned in the previous
>>> emails in this thread.
>>>
>>> Geert, can you check an m68k build?
>
> You introduced a build regression by moving the #include <asm-generic/siginfo.h>
> to the bottom of arch/m68k/include/asm/siginfo.h.
Ah, yes, I was worried that might be the case with that change.
I refactored it back to the way it was originally (like your patch).
Updated the git tree with that.
Thanks
Greg
> After fixing that (patch below, did gmail webmail preserve the tabs?),
> atari_defconfig builds
> and runs on ARAnyM. I'm now building a sun3_defconfig...
>
> diff --git a/arch/m68k/include/asm/siginfo.h b/arch/m68k/include/asm/siginfo.h
> index 9999e7d..f88b4a7 100644
> --- a/arch/m68k/include/asm/siginfo.h
> +++ b/arch/m68k/include/asm/siginfo.h
> @@ -4,7 +4,11 @@
> #ifndef __uClinux__
> #define HAVE_ARCH_SIGINFO_T
> #define HAVE_ARCH_COPY_SIGINFO
> +#endif
> +
> +#include <asm-generic/siginfo.h>
>
> +#ifndef __uClinux__
> typedef struct siginfo {
> int si_signo;
> int si_errno;
> @@ -89,6 +93,4 @@ static inline void copy_siginfo(struct siginfo *to,
> struct siginfo *from)
> #endif /* __KERNEL__ */
> #endif /* __uClinux__ */
>
> -#include <asm-generic/siginfo.h>
> -
> #endif
>
>>> Rob, can you check that you can build what you used to be able to?
>> Nope. Pulled the repository, tarred it up, stuck it in my build system, and
>> the uClibc build still dies attempting to generate syscalls:
>>
>> GEN include/bits/sysnum.h
>> In file included from <stdin>:1:
>> /home/landley/firmware/firmware/build/cross-compiler-
>> m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory
>> In file included from <stdin>:1:
>> /home/landley/firmware/firmware/build/cross-compiler-
>> m68k/include/asm/unistd.h:4:23: error: unistd_mm.h: No such file or directory
>> ERROR: Could not generate syscalls.
>
> I guess you forgot to check out branch fix-includes? There's no unistd_mm.h in
> that branch.
>
--
------------------------------------------------------------------------
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/
Powered by blists - more mailing lists