m68k libc5 regression

m68k libc5 regression

[Geert Uytterhoeven]

Recently I noticed a regression when running an old libc5 binary
(amiga-lilo) on m68k. It fails with the error message:

    Can't allocate memory

Strace shows that the offending part is:

    brk(0x80008e40)                         = 0x80009000

For older kernels, brk() behaved like:

    brk(0x80008e40)                         = 0x80008e40
    brk(0x80009000)                         = 0x80009000

Also our good old libc5 emergency ramdisk no longer works (init cannot
open /inittab).

At first I suspected CONFIG_COMPAT_BRK, but different values (0, 1, 2) of
/proc/sys/kernel/randomize_va_space don't seem to make any difference.

So I bisected it to:

commit 4cc6028d4040f95cdb590a87db478b42b8be0508
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Wed Feb 6 22:39:44 2008 +0100

    brk: check the lower bound properly
    
    There is a check in sys_brk(), that tries to make sure that we do not
    underflow the area that is dedicated to brk heap.
    
    The check is however wrong, as it assumes that brk area starts immediately
    after the end of the code (+bss), which is wrong for example in
    environments with randomized brk start. The proper way is to check whether
    the address is not below the start_brk address.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/mm/mmap.c b/mm/mmap.c
index bb4c963..ad6e4ea 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -245,7 +245,7 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
 
 	down_write(&mm->mmap_sem);
 
-	if (brk < mm->end_code)
+	if (brk < mm->start_brk)
 		goto out;
 
 	/*

Reverting this change on current mainline fixes both libc5 amiga-lilo and the
libc5 emergency ramdisk. The value of /proc/sys/kernel/randomize_va_space still
doesn't matter.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: m68k libc5 regression

[Jiri Kosina]

On Mon, 26 May 2008, Geert Uytterhoeven wrote:

> Recently I noticed a regression when running an old libc5 binary
> (amiga-lilo) on m68k. It fails with the error message:

Hmm, libc5 is known to make broken assumptions about brk location, that's 
why we introduced CONFIG_COMPAT_BRK, do you have that option turned on?

> So I bisected it to:
> commit 4cc6028d4040f95cdb590a87db478b42b8be0508
> Author: Jiri Kosina <jkosina@suse.cz>
> Date:   Wed Feb 6 22:39:44 2008 +0100
>     brk: check the lower bound properly

Indeed, this should take CONFIG_COMPAT_BRK into account. Does the patch 
below fix it? (assuming that you have CONFIG_COMPAT_BRK=y):



From: Jiri Kosina <jkosina@suse.cz>

brk: check lower bound properly

The check in sys_brk() on minimum value the brk might have must take 
CONFIG_COMPAT_BRK setting into account. When this option is turned on 
(i.e. we support ancient legacy binaries, e.g. libc5-linked stuff), the 
lower bound on brk value is mm->end_code, otherwise the brk start is 
allowed to be arbitrarily shifted.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/mm/mmap.c b/mm/mmap.c
index fac6633..834118b 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -245,10 +245,16 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
 	unsigned long rlim, retval;
 	unsigned long newbrk, oldbrk;
 	struct mm_struct *mm = current->mm;
+	unsigned long min_brk;
 
 	down_write(&mm->mmap_sem);
 
-	if (brk < mm->start_brk)
+#ifdef CONFIG_COMPAT_BRK
+	min_brk = mm->end_code;
+#else
+	min_brk = mm->start_brk;
+#endif
+	if (brk < min_brk)
 		goto out;
 
 	/*

Re: m68k libc5 regression

[Jiri Kosina]

On Tue, 27 May 2008, Jiri Kosina wrote:

> > So I bisected it to:
> > commit 4cc6028d4040f95cdb590a87db478b42b8be0508
> > Author: Jiri Kosina <jkosina@suse.cz>
> > Date:   Wed Feb 6 22:39:44 2008 +0100
> >     brk: check the lower bound properly
> Indeed, this should take CONFIG_COMPAT_BRK into account. Does the patch 
> below fix it? (assuming that you have CONFIG_COMPAT_BRK=y):
> From: Jiri Kosina <jkosina@suse.cz>
> brk: check lower bound properly
[ ... ]

Geert, did you have time to verify that the patch fixes the problem for 
you please?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: m68k libc5 regression

[Geert Uytterhoeven]

On Thu, 29 May 2008, Jiri Kosina wrote:
> On Tue, 27 May 2008, Jiri Kosina wrote:
> > > So I bisected it to:
> > > commit 4cc6028d4040f95cdb590a87db478b42b8be0508
> > > Author: Jiri Kosina <jkosina@suse.cz>
> > > Date:   Wed Feb 6 22:39:44 2008 +0100
> > >     brk: check the lower bound properly
> > Indeed, this should take CONFIG_COMPAT_BRK into account. Does the patch 
> > below fix it? (assuming that you have CONFIG_COMPAT_BRK=y):
> > From: Jiri Kosina <jkosina@suse.cz>
> > brk: check lower bound properly
> [ ... ]
> 
> Geert, did you have time to verify that the patch fixes the problem for 
> you please?

Not yet. I will definitely let you know.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: m68k libc5 regression

[Geert Uytterhoeven]

On Tue, 27 May 2008, Jiri Kosina wrote:
> On Mon, 26 May 2008, Geert Uytterhoeven wrote:
> 
> > Recently I noticed a regression when running an old libc5 binary
> > (amiga-lilo) on m68k. It fails with the error message:
> 
> Hmm, libc5 is known to make broken assumptions about brk location, that's 
> why we introduced CONFIG_COMPAT_BRK, do you have that option turned on?
> 
> > So I bisected it to:
> > commit 4cc6028d4040f95cdb590a87db478b42b8be0508
> > Author: Jiri Kosina <jkosina@suse.cz>
> > Date:   Wed Feb 6 22:39:44 2008 +0100
> >     brk: check the lower bound properly
> 
> Indeed, this should take CONFIG_COMPAT_BRK into account. Does the patch 
> below fix it? (assuming that you have CONFIG_COMPAT_BRK=y):

Yes, both libc5 amiga-lilo and the libc5 emergency ramdisk work again
after applying this patch.

> From: Jiri Kosina <jkosina@suse.cz>
> 
> brk: check lower bound properly
> 
> The check in sys_brk() on minimum value the brk might have must take 
> CONFIG_COMPAT_BRK setting into account. When this option is turned on 
> (i.e. we support ancient legacy binaries, e.g. libc5-linked stuff), the 
> lower bound on brk value is mm->end_code, otherwise the brk start is 
> allowed to be arbitrarily shifted.
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: m68k libc5 regression

[Andrew Morton]

On Tue, 27 May 2008 00:19:32 +0200 (CEST) Jiri Kosina <jkosina@suse.cz> wrote:

> On Mon, 26 May 2008, Geert Uytterhoeven wrote:
> 
> > Recently I noticed a regression when running an old libc5 binary
> > (amiga-lilo) on m68k. It fails with the error message:
> 
> Hmm, libc5 is known to make broken assumptions about brk location, that's 
> why we introduced CONFIG_COMPAT_BRK, do you have that option turned on?
> 
> > So I bisected it to:
> > commit 4cc6028d4040f95cdb590a87db478b42b8be0508
> > Author: Jiri Kosina <jkosina@suse.cz>
> > Date:   Wed Feb 6 22:39:44 2008 +0100
> >     brk: check the lower bound properly
> 
> Indeed, this should take CONFIG_COMPAT_BRK into account. Does the patch 
> below fix it? (assuming that you have CONFIG_COMPAT_BRK=y):
> 
> 
> 
> From: Jiri Kosina <jkosina@suse.cz>
> 
> brk: check lower bound properly
> 
> The check in sys_brk() on minimum value the brk might have must take 
> CONFIG_COMPAT_BRK setting into account. When this option is turned on 
> (i.e. we support ancient legacy binaries, e.g. libc5-linked stuff), the 
> lower bound on brk value is mm->end_code, otherwise the brk start is 
> allowed to be arbitrarily shifted.
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index fac6633..834118b 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -245,10 +245,16 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
>  	unsigned long rlim, retval;
>  	unsigned long newbrk, oldbrk;
>  	struct mm_struct *mm = current->mm;
> +	unsigned long min_brk;
>  
>  	down_write(&mm->mmap_sem);
>  
> -	if (brk < mm->start_brk)
> +#ifdef CONFIG_COMPAT_BRK
> +	min_brk = mm->end_code;
> +#else
> +	min_brk = mm->start_brk;
> +#endif
> +	if (brk < min_brk)
>  		goto out;
>  

OK, we have a problem here.

Somebody has gone and checked this patch into their tree and it now
appears in linux-next.

I do not know how to work out how this patch got into linux-next.

It's not in any of the trees which I pull so I guess that person has
been shuffling URLs without telling me.

One of the reasons this is bad is that, frankly, I trust almost nobody
to remember to backport fixes into 2.6.25.x.  I'm not even at all
confident that our mystery new part-time memory management maintainer
will remember to merge this into 2.6.26.  The fact that this person
failed to add a Cc:stable@kernel.org to the changelog doesn't inspire
confidence.

I shall merge this fix into my tree (y'know - the one where memory
management patches are hosted) and I'll get it into 2.6.26 and shall
offer it to the -stable team.  This will cause me to get collisions
with the duplicated patch in linux-next but fortunately it is small. 
This time.

And to whoever did this: please don't.

Re: m68k libc5 regression

[Geert Uytterhoeven]

On Sun, 1 Jun 2008, Andrew Morton wrote:
> On Tue, 27 May 2008 00:19:32 +0200 (CEST) Jiri Kosina <jkosina@suse.cz> wrote:
> > From: Jiri Kosina <jkosina@suse.cz>
> > 
> > brk: check lower bound properly
> > 
> > The check in sys_brk() on minimum value the brk might have must take 
> > CONFIG_COMPAT_BRK setting into account. When this option is turned on 
> > (i.e. we support ancient legacy binaries, e.g. libc5-linked stuff), the 
> > lower bound on brk value is mm->end_code, otherwise the brk start is 
> > allowed to be arbitrarily shifted.
> > 
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> 
> OK, we have a problem here.
> 
> Somebody has gone and checked this patch into their tree and it now
> appears in linux-next.
> 
> I do not know how to work out how this patch got into linux-next.

Through quilt/m68k

> It's not in any of the trees which I pull so I guess that person has
> been shuffling URLs without telling me.

... which is not in your tree, AFAIK.

> One of the reasons this is bad is that, frankly, I trust almost nobody
> to remember to backport fixes into 2.6.25.x.  I'm not even at all
> confident that our mystery new part-time memory management maintainer
> will remember to merge this into 2.6.26.  The fact that this person
> failed to add a Cc:stable@kernel.org to the changelog doesn't inspire
> confidence.

It's on my (m68k) list for 2.6.26...
And as soon as it's in, I was going to tell stable...

> I shall merge this fix into my tree (y'know - the one where memory
> management patches are hosted) and I'll get it into 2.6.26 and shall
> offer it to the -stable team.  This will cause me to get collisions
> with the duplicated patch in linux-next but fortunately it is small. 
> This time.

So what's the appropriate way to handle this?
I should have kept it in the m68k series after NEXT_PATCHES_END, so
nobody sees it exists?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: m68k libc5 regression

[Andrew Morton]

On Sun, 1 Jun 2008 10:37:59 +0200 (CEST) Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> > I shall merge this fix into my tree (y'know - the one where memory
> > management patches are hosted) and I'll get it into 2.6.26 and shall
> > offer it to the -stable team.  This will cause me to get collisions
> > with the duplicated patch in linux-next but fortunately it is small. 
> > This time.
> 
> So what's the appropriate way to handle this?

Well at least please reply letting people know what's happening with it.

Ask me to merge it and remind me that it's needed in -stable.  Or just
send the thing to Linus and -stable immediately.  Copy me and I'll do
the usual merge-it-in-case-linus-misses-it trick.

> I should have kept it in the m68k series after NEXT_PATCHES_END, so
> nobody sees it exists?

That would work, as long as we know that the patch is firmly on the
mainline and -stable paths.

Re: m68k libc5 regression

[Sam Ravnborg]

On Sun, Jun 01, 2008 at 01:48:24AM -0700, Andrew Morton wrote:
> On Sun, 1 Jun 2008 10:37:59 +0200 (CEST) Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> > > I shall merge this fix into my tree (y'know - the one where memory
> > > management patches are hosted) and I'll get it into 2.6.26 and shall
> > > offer it to the -stable team.  This will cause me to get collisions
> > > with the duplicated patch in linux-next but fortunately it is small. 
> > > This time.
> > 
> > So what's the appropriate way to handle this?
> 
> Well at least please reply letting people know what's happening with it.
> 
> Ask me to merge it and remind me that it's needed in -stable.  Or just
> send the thing to Linus and -stable immediately.

I recall adding:
Cc: stable@kernel.org

will automagically tell the stable team when this is
merged and that it is a -stable candidate.

	Sam

Re: m68k libc5 regression

[Andrew Morton]

On Sun, 1 Jun 2008 11:22:05 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:

> On Sun, Jun 01, 2008 at 01:48:24AM -0700, Andrew Morton wrote:
> > On Sun, 1 Jun 2008 10:37:59 +0200 (CEST) Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > 
> > > > I shall merge this fix into my tree (y'know - the one where memory
> > > > management patches are hosted) and I'll get it into 2.6.26 and shall
> > > > offer it to the -stable team.  This will cause me to get collisions
> > > > with the duplicated patch in linux-next but fortunately it is small. 
> > > > This time.
> > > 
> > > So what's the appropriate way to handle this?
> > 
> > Well at least please reply letting people know what's happening with it.
> > 
> > Ask me to merge it and remind me that it's needed in -stable.  Or just
> > send the thing to Linus and -stable immediately.
> 
> I recall adding:
> Cc: stable@kernel.org
> 
> will automagically tell the stable team when this is
> merged and that it is a -stable candidate.
> 

Yup.  Except I always use the <> wrappers around the email address.  In
fact my scripts require that (and probably shouldn't).  We don't seem
very consistent with that.

Re: m68k libc5 regression

[Geert Uytterhoeven]

On Sun, 1 Jun 2008, Andrew Morton wrote:
> On Sun, 1 Jun 2008 10:37:59 +0200 (CEST) Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > I shall merge this fix into my tree (y'know - the one where memory
> > > management patches are hosted) and I'll get it into 2.6.26 and shall
> > > offer it to the -stable team.  This will cause me to get collisions
> > > with the duplicated patch in linux-next but fortunately it is small. 
> > > This time.
> > 
> > So what's the appropriate way to handle this?
> 
> Well at least please reply letting people know what's happening with it.
> 
> Ask me to merge it and remind me that it's needed in -stable.  Or just
> send the thing to Linus and -stable immediately.  Copy me and I'll do
> the usual merge-it-in-case-linus-misses-it trick.
> 
> > I should have kept it in the m68k series after NEXT_PATCHES_END, so
> > nobody sees it exists?
> 
> That would work, as long as we know that the patch is firmly on the
> mainline and -stable paths.

OK.

As you've been faster than me, I assume you will take care of it now anyway?

Here's an additional one... Can you add this one too?

Thx!

Subject: [PATCH] m68k: enable CONFIG_COMPAT_BRK by default

As some m68k machines have plenty of libc5 binaries in active use, enable
CONFIG_COMPAT_BRK by default.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 arch/m68k/configs/amiga_defconfig    |    6 +++---
 arch/m68k/configs/apollo_defconfig   |    6 +++---
 arch/m68k/configs/atari_defconfig    |    6 +++---
 arch/m68k/configs/bvme6000_defconfig |    6 +++---
 arch/m68k/configs/hp300_defconfig    |    6 +++---
 arch/m68k/configs/mac_defconfig      |    6 +++---
 arch/m68k/configs/multi_defconfig    |    6 +++---
 arch/m68k/configs/mvme147_defconfig  |    6 +++---
 arch/m68k/configs/mvme16x_defconfig  |    6 +++---
 arch/m68k/configs/q40_defconfig      |    6 +++---
 arch/m68k/configs/sun3_defconfig     |    6 +++---
 arch/m68k/configs/sun3x_defconfig    |    6 +++---
 12 files changed, 36 insertions(+), 36 deletions(-)

--- a/arch/m68k/configs/amiga_defconfig
+++ b/arch/m68k/configs/amiga_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:41 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/apollo_defconfig
+++ b/arch/m68k/configs/apollo_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:42 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/atari_defconfig
+++ b/arch/m68k/configs/atari_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:43 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/bvme6000_defconfig
+++ b/arch/m68k/configs/bvme6000_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:45 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/hp300_defconfig
+++ b/arch/m68k/configs/hp300_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:46 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:47 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:42:31 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/mvme147_defconfig
+++ b/arch/m68k/configs/mvme147_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:49 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/mvme16x_defconfig
+++ b/arch/m68k/configs/mvme16x_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:50 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/q40_defconfig
+++ b/arch/m68k/configs/q40_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:51 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/sun3_defconfig
+++ b/arch/m68k/configs/sun3_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:53 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y
--- a/arch/m68k/configs/sun3x_defconfig
+++ b/arch/m68k/configs/sun3x_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26-rc2
-# Sun May 18 14:44:54 2008
+# Linux kernel version: 2.6.26-rc4
+# Wed May 28 22:47:35 2008
 #
 CONFIG_M68K=y
 CONFIG_MMU=y
@@ -59,7 +59,7 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
+CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_ANON_INODES=y

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: m68k libc5 regression

[Sam Ravnborg]

On Sun, Jun 01, 2008 at 02:41:05AM -0700, Andrew Morton wrote:
> On Sun, 1 Jun 2008 11:22:05 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > On Sun, Jun 01, 2008 at 01:48:24AM -0700, Andrew Morton wrote:
> > > On Sun, 1 Jun 2008 10:37:59 +0200 (CEST) Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > 
> > > > > I shall merge this fix into my tree (y'know - the one where memory
> > > > > management patches are hosted) and I'll get it into 2.6.26 and shall
> > > > > offer it to the -stable team.  This will cause me to get collisions
> > > > > with the duplicated patch in linux-next but fortunately it is small. 
> > > > > This time.
> > > > 
> > > > So what's the appropriate way to handle this?
> > > 
> > > Well at least please reply letting people know what's happening with it.
> > > 
> > > Ask me to merge it and remind me that it's needed in -stable.  Or just
> > > send the thing to Linus and -stable immediately.
> > 
> > I recall adding:
> > Cc: stable@kernel.org
> > 
> > will automagically tell the stable team when this is
> > merged and that it is a -stable candidate.
> > 
> 
> Yup.  Except I always use the <> wrappers around the email address.  In
> fact my scripts require that (and probably shouldn't).  We don't seem
> very consistent with that.

Email addresses are often verbatim copied from MAINTAINERS
where we not yet have proper format (no <>).
So relying on <> in Cc: is not good.

For stable on 20 where without <> since 2.6.20 compered to
291 with <>.

	Sam

Diagnosing linux-next (Was: Re: m68k libc5 regression)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

Hi Andrew,

On Sun, 1 Jun 2008 00:53:38 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I do not know how to work out how this patch got into linux-next.

I have been wondering for a while what I can do to make figuring this out
(in general) easier.  Would adding the SHA1 of the head of each tree to
the Trees file help?  I could publish all the branches in my linux-next
repo - but they change daily.  I guess only the git users benefit from
those suggestions.

gitk can tell you pretty easily (just find the offending commit and work
your way upward until you find a merge by me).

Other suggestions?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Diagnosing linux-next (Was: Re: m68k libc5 regression)

[Andrew Morton]

On Sun, 1 Jun 2008 23:26:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> On Sun, 1 Jun 2008 00:53:38 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > I do not know how to work out how this patch got into linux-next.
> 
> I have been wondering for a while what I can do to make figuring this out
> (in general) easier.  Would adding the SHA1 of the head of each tree to
> the Trees file help?  I could publish all the branches in my linux-next
> repo - but they change daily.  I guess only the git users benefit from
> those suggestions.
> 
> gitk can tell you pretty easily (just find the offending commit and work
> your way upward until you find a merge by me).
> 

hm, I just found the `committer' line in gitk.  Coulda sworn that
wasn't there yesterday.

Re: Diagnosing linux-next (Was: Re: m68k libc5 regression)

[Paul Mackerras]

Andrew Morton writes:

> hm, I just found the `committer' line in gitk.  Coulda sworn that
> wasn't there yesterday.

It was, actually. :)

Seriously, if you have any suggestions about things that would make
gitk more useful for you, let me know.

Paul.

Re: Diagnosing linux-next (Was: Re: m68k libc5 regression)

[Andrew Morton]

On Mon, 2 Jun 2008 10:39:17 +1000 Paul Mackerras <paulus@samba.org> wrote:

> Andrew Morton writes:
> 
> > hm, I just found the `committer' line in gitk.  Coulda sworn that
> > wasn't there yesterday.
> 
> It was, actually. :)
> 
> Seriously, if you have any suggestions about things that would make
> gitk more useful for you, let me know.
> 

tkdiff-style diff viewer!

I mentioned that to you a year or two back, and you've probabably
already done it but nobody told me about it :)

Re: Diagnosing linux-next (Was: Re: m68k libc5 regression)

[Paul Mackerras]

Andrew Morton writes:

> tkdiff-style diff viewer!
> 
> I mentioned that to you a year or two back, and you've probabably
> already done it but nobody told me about it :)

There's now a facility for viewing diffs in an external viewer.  If
you do Edit->Preferences and set the "External diff tool" thing to
tkdiff, then you can right-click on a file name in the file list
(bottom right-hand pane) and select "External diff" and it will launch
tkdiff to show you the diffs for that file.

What is it you like about tkdiff?  Is it the side-by-side display, or
the highlighting of differences within a line, or the merge facility?

Paul.

Re: Diagnosing linux-next (Was: Re: m68k libc5 regression)

[Andrew Morton]

On Mon, 2 Jun 2008 12:12:29 +1000 Paul Mackerras <paulus@samba.org> wrote:

> Andrew Morton writes:
> 
> > tkdiff-style diff viewer!
> > 
> > I mentioned that to you a year or two back, and you've probabably
> > already done it but nobody told me about it :)
> 
> There's now a facility for viewing diffs in an external viewer.  If
> you do Edit->Preferences and set the "External diff tool" thing to
> tkdiff, then you can right-click on a file name in the file list
> (bottom right-hand pane) and select "External diff" and it will launch
> tkdiff to show you the diffs for that file.

<upgrades>

OK, that works, thanks.  Right-clicking on each file is the sole way to
bring it up?

> What is it you like about tkdiff?  Is it the side-by-side display, or
> the highlighting of differences within a line, or the merge facility?

I like the side-by-side display.  I hardly look at the left (previous) side
at all - it's a good way of seeing the change in a larger context.

Re: Diagnosing linux-next (Was: Re: m68k libc5 regression)

[Paul Mackerras]

Andrew Morton writes:

> On Mon, 2 Jun 2008 12:12:29 +1000 Paul Mackerras <paulus@samba.org> wrote:
> > There's now a facility for viewing diffs in an external viewer.  If
> > you do Edit->Preferences and set the "External diff tool" thing to
> > tkdiff, then you can right-click on a file name in the file list
> > (bottom right-hand pane) and select "External diff" and it will launch
> > tkdiff to show you the diffs for that file.
> 
> <upgrades>
> 
> OK, that works, thanks.  Right-clicking on each file is the sole way to
> bring it up?

At the moment, yes.  Do you want something different?

> > What is it you like about tkdiff?  Is it the side-by-side display, or
> > the highlighting of differences within a line, or the merge facility?
> 
> I like the side-by-side display.  I hardly look at the left (previous) side
> at all - it's a good way of seeing the change in a larger context.

I see.  There are a couple of features in gitk you might find useful,
then: you can get the gitk diff window to display just the new
version (or just the old version) using the radio buttons just above
the diff pane.  You can also get it to show more context with the
spinbox to the right of the radio buttons.

Something that dirdiff can do is to let you pick up the separator line
and drag it upwards or downwards to see more context.  Maybe I should
add that to gitk too.

Paul.

Re: Diagnosing linux-next (Was: Re: m68k libc5 regression)

[Andrew Morton]

On Mon, 2 Jun 2008 15:49:59 +1000 Paul Mackerras <paulus@samba.org> wrote:

> Andrew Morton writes:
> 
> > On Mon, 2 Jun 2008 12:12:29 +1000 Paul Mackerras <paulus@samba.org> wrote:
> > > There's now a facility for viewing diffs in an external viewer.  If
> > > you do Edit->Preferences and set the "External diff tool" thing to
> > > tkdiff, then you can right-click on a file name in the file list
> > > (bottom right-hand pane) and select "External diff" and it will launch
> > > tkdiff to show you the diffs for that file.
> > 
> > <upgrades>
> > 
> > OK, that works, thanks.  Right-clicking on each file is the sole way to
> > bring it up?
> 
> At the moment, yes.  Do you want something different?

No, that's OK.

> > > What is it you like about tkdiff?  Is it the side-by-side display, or
> > > the highlighting of differences within a line, or the merge facility?
> > 
> > I like the side-by-side display.  I hardly look at the left (previous) side
> > at all - it's a good way of seeing the change in a larger context.
> 
> I see.  There are a couple of features in gitk you might find useful,
> then: you can get the gitk diff window to display just the new
> version (or just the old version) using the radio buttons just above
> the diff pane.  You can also get it to show more context with the
> spinbox to the right of the radio buttons.
> 
> Something that dirdiff can do is to let you pick up the separator line
> and drag it upwards or downwards to see more context.  Maybe I should
> add that to gitk too.

I like to see the new code with lines-which-changed highlighted (the
tkdiff RHS).  But the LHS is useful sometimes too.

tkdiff works fine for me - I guess it's what you're used to.

eg: when I apply a patch with -F1 and it fails, then I apply it without
-F1 and it applies, I have to go in and check that the hunks which
didn't apply with -F1 actually landed in the right place.  So to find
hunk 14 of 24 I click tkdiff's 'Next' button 13 times.

Re: m68k libc5 regression

[Jiri Kosina]

On Sun, 1 Jun 2008, Andrew Morton wrote:

> > -	if (brk < mm->start_brk)
> > +#ifdef CONFIG_COMPAT_BRK
> > +	min_brk = mm->end_code;
> > +#else
> > +	min_brk = mm->start_brk;
> > +#endif
> > +	if (brk < min_brk)
> >  		goto out;
> >  
> OK, we have a problem here.
> Somebody has gone and checked this patch into their tree and it now
> appears in linux-next.

Ah, I have expected either you or Ingo (as my patch that introduced the 
bug went through his tree too) to pick that up.

> I do not know how to work out how this patch got into linux-next.

Well, git-blame on mm/mmap.c in linux-next tree shows the commit id, and 
then git-show --pretty=full tells you the comitter name.

-- 
Jiri Kosina
SUSE Labs

Re: m68k libc5 regression

[Jiri Kosina]

On Thu, 29 May 2008, Geert Uytterhoeven wrote:

> > From: Jiri Kosina <jkosina@suse.cz>
> > 
> > brk: check lower bound properly
> > 
> > The check in sys_brk() on minimum value the brk might have must take 
> > CONFIG_COMPAT_BRK setting into account. When this option is turned on 
> > (i.e. we support ancient legacy binaries, e.g. libc5-linked stuff), the 
> > lower bound on brk value is mm->end_code, otherwise the brk start is 
> > allowed to be arbitrarily shifted.
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Thanks a lot for verifying, Geert.

So, I assume the proper way to handle this now is you dropping it from 
your m68k tree, and Andrew taking it through -mm.

Thanks,

-- 
Jiri Kosina
SUSE Labs