Resending without Japanese characters in the mail header to avoid spam filters.
Sorry for the noise.
---
The commit 8833ebaa3f4325820fe3338ccf6fae04f6669254 introduced a change that broke
IA64 compilation as shown below:
gcc -Wp,-MD,arch/ia64/kernel/.entry.o.d -nostdinc -isystem /usr/lib/gcc/ia64-linux-gnu/4.1.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -DHAVE_WORKING_TEXT_ALIGN -DHAVE_MODEL_SMALL_ATTRIBUTE -DHAVE_SERIALIZE_DIRECTIVE -D__ASSEMBLY__ -mconstant-gp -c -o arch/ia64/kernel/entry.o arch/ia64/kernel/entry.S
include/asm/mman.h: Assembler messages:
include/asm/mman.h:13: Error: Unknown opcode `int ia64_map_check_rgn(unsigned long addr,unsigned long len,'
include/asm/mman.h:14: Error: Unknown opcode `unsigned long flags)'
make[1]: *** [arch/ia64/kernel/entry.o] Error 1
make: *** [arch/ia64/kernel] Error 2
The reason is that "asm/mman.h" is being included from entry.S indirectly through
"asm/pgtable.h" (see code snips below).
* arch/ia64/kernel/entry.S:
...
#include <asm/pgtable.h>
...
* include/asm-ia64/pgtable.h:
...
#include <asm/mman.h>
...
* include/asm-ia64/mman.h
...
#ifdef __KERNEL__
#define arch_mmap_check ia64_map_check_rgn
int ia64_map_check_rgn(unsigned long addr, unsigned long len,
unsigned long flags);
#endif
...
Signed-off-by: Fernando Vazquez <[email protected]>
---
diff -urNp linux-2.6.17.11/include/asm-ia64/mman.h linux-2.6.17.11-fix/include/asm-ia64/mman.h
--- linux-2.6.17.11/include/asm-ia64/mman.h 2006-08-25 11:36:09.000000000 +0900
+++ linux-2.6.17.11-fix/include/asm-ia64/mman.h 2006-08-25 11:39:16.000000000 +0900
@@ -9,10 +9,12 @@
*/
#ifdef __KERNEL__
+#ifndef __ASSEMBLY__
#define arch_mmap_check ia64_map_check_rgn
int ia64_map_check_rgn(unsigned long addr, unsigned long len,
unsigned long flags);
#endif
+#endif
#include <asm-generic/mman.h>
On Fri, Aug 25, 2006 at 05:13:07PM +0900, Fernando Vazquez wrote:
> Resending without Japanese characters in the mail header to avoid spam filters.
> Sorry for the noise.
Queued to -stable, thanks.
greg k-h
> The commit 8833ebaa3f4325820fe3338ccf6fae04f6669254 introduced a change that broke
> IA64 compilation as shown below:
What happened to the mainline version of the patch to which this
is a fix (local DoS with corrupted ELFs)? I don't see it in 2.6.18-rc5.
Did it get fixed some other way, or is it just queued somewhere? Or do
we have a fix in -stable that isn't in mainline?
-Tony
On Mon, Aug 28, 2006 at 03:11:31PM -0700, Luck, Tony wrote:
> > The commit 8833ebaa3f4325820fe3338ccf6fae04f6669254 introduced a change that broke
> > IA64 compilation as shown below:
>
> What happened to the mainline version of the patch to which this
> is a fix (local DoS with corrupted ELFs)? I don't see it in 2.6.18-rc5.
> Did it get fixed some other way, or is it just queued somewhere? Or do
> we have a fix in -stable that isn't in mainline?
I thought this was a fix for a prior -stable patch that did not affect
mainline. Or was this thought wrong?
thanks,
greg k-h
Greg KH wrote:
> On Mon, Aug 28, 2006 at 03:11:31PM -0700, Luck, Tony wrote:
>
>>>The commit 8833ebaa3f4325820fe3338ccf6fae04f6669254 introduced a change that broke
>>>IA64 compilation as shown below:
>>
>>What happened to the mainline version of the patch to which this
>>is a fix (local DoS with corrupted ELFs)? I don't see it in 2.6.18-rc5.
>>Did it get fixed some other way, or is it just queued somewhere? Or do
>>we have a fix in -stable that isn't in mainline?
>
>
> I thought this was a fix for a prior -stable patch that did not affect
> mainline. Or was this thought wrong?
both patches should be passed to Linus.
Probably it is my fault, since I thought that patches which got into -stable
automatically go into Linus tree.
Thanks,
Kirill
Greg KH wrote:
> On Mon, Aug 28, 2006 at 03:11:31PM -0700, Luck, Tony wrote:
>
>>>The commit 8833ebaa3f4325820fe3338ccf6fae04f6669254 introduced a change that broke
>>>IA64 compilation as shown below:
>>
>>What happened to the mainline version of the patch to which this
>>is a fix (local DoS with corrupted ELFs)? I don't see it in 2.6.18-rc5.
>>Did it get fixed some other way, or is it just queued somewhere? Or do
>>we have a fix in -stable that isn't in mainline?
>
>
> I thought this was a fix for a prior -stable patch that did not affect
> mainline. Or was this thought wrong?
it should be passed to Linus.
Probably it is my fault, since I thought that patches which got into -stable
automatically go into Linus tree.
Thanks,
Kirill
On Tue, Aug 29, 2006 at 04:24:21PM +0400, Kirill Korotaev wrote:
> Probably it is my fault, since I thought that patches which got into -stable
> automatically go into Linus tree.
No they do not. Usually it's the requirement that they be in his tree
first, but I didn't think it was necessary this time due to my
misunderstanding about the fix.
thanks,
greg k-h
On Tue, 2006-08-29 at 09:08 -0700, Greg KH wrote:
> On Tue, Aug 29, 2006 at 04:24:21PM +0400, Kirill Korotaev wrote:
> > Probably it is my fault, since I thought that patches which got into -stable
> > automatically go into Linus tree.
>
> No they do not. Usually it's the requirement that they be in his tree
> first, but I didn't think it was necessary this time due to my
> misunderstanding about the fix.
2.6.18-rc6 has just been released and neither my patch nor the original
patch to which it is a fix seem to have been included. Does this mean
they will not be sent to Linux before the final release of 2.6.18?
Regards,
Fernando
--
VGER BF report: H 0.358263
Fernando,
I planned to send it today. You will be on CC
Thanks,
Kirill
> On Tue, 2006-08-29 at 09:08 -0700, Greg KH wrote:
>
>>On Tue, Aug 29, 2006 at 04:24:21PM +0400, Kirill Korotaev wrote:
>>
>>>Probably it is my fault, since I thought that patches which got into -stable
>>>automatically go into Linus tree.
>>
>>No they do not. Usually it's the requirement that they be in his tree
>>first, but I didn't think it was necessary this time due to my
>>misunderstanding about the fix.
>
> 2.6.18-rc6 has just been released and neither my patch nor the original
> patch to which it is a fix seem to have been included. Does this mean
> they will not be sent to Linux before the final release of 2.6.18?
>
> Regards,
>
> Fernando
>
>
--
VGER BF report: H 0