Skip to contentSkip to conversation

2.6.27.52 stable review

PATCH In review Greg KH 7 participants 27 messages Aug 13, 2010 – Aug 23, 2010

Subsystems (5)
Memory management x86 Kbuild MM core +1 more subsystems
lore
Share & tools
lore

Greg KH

author
#0 lore raw

cover 2.6.27.52 stable review

NOTE!

If I could get some people to please test this -rc release? It contains a few core changes that I couldn't validate myself as I don't seem to have a machine that will even boot the .27 kernel anymore after my move.

I didn't want to include them in the last .27-stable release because of this, so any testing is much appreciated. Especially if you happen to run across any signal and/or stack issues that might be floating around in the ether...

----

This is the start of the stable review cycle for the 2.6.27.52 release. There are 3 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Monday, August 16, 2010, 20:00:00 UTC. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.27.52-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

 Makefile            |    2 +-
 arch/x86/mm/fault.c |    9 ++++++++-
 mm/memory.c         |   25 +++++++++++++++++++++++++
 3 files changed, 34 insertions(+), 2 deletions(-)
author
#1 lore raw

PATCH 1/3 mm: keep a guard page below a grow-down stack segment

2.6.27-stable review patch. If anyone has any objections, please let us know.

------------------

From: Linus Torvalds <[email protected]>

commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream.

This is a rather minimally invasive patch to solve the problem of the user stack growing into a memory mapped area below it. Whenever we fill the first page of the stack segment, expand the segment down by one page.

Now, admittedly some odd application might _want_ the stack to grow down into the preceding memory mapping, and so we may at some point need to make this a process tunable (some people might also want to have more than a single page of guarding), but let's try the minimal approach first.

Tested with trivial application that maps a single page just below the stack, and then starts recursing. Without this, we will get a SIGSEGV _after_ the stack has smashed the mapping. With this patch, we'll get a nice SIGBUS just as the stack touches the page just above the mapping.

Requested-by Keith Packard <[email protected]>
Signed-off-by Linus Torvalds <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 mm/memory.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
mm/memory.c +23 -0
@@ -2396,6 +2396,26 @@ out_nomap:
 }
 
 /*
+ * This is like a special single-page "expand_downwards()",
+ * except we must first make sure that 'address-PAGE_SIZE'
+ * doesn't hit another vma.
+ *
+ * The "find_vma()" will do the right thing even if we wrap
+ */
+static inline int check_stack_guard_page(struct vm_area_struct *vma, unsigned long address)
+{
+	address &= PAGE_MASK;
+	if ((vma->vm_flags & VM_GROWSDOWN) && address == vma->vm_start) {
+		address -= PAGE_SIZE;
+		if (find_vma(vma->vm_mm, address) != vma)
+			return -ENOMEM;
+
+		expand_stack(vma, address);
+	}
+	return 0;
+}
+
+/*
  * We enter with non-exclusive mmap_sem (to exclude vma changes,
  * but allow concurrent faults), and pte mapped but not yet locked.
  * We return with mmap_sem still held, but pte unmapped and unlocked.

@@ -2408,6 +2428,9 @@ static int do_anonymous_page(struct mm_s
 	spinlock_t *ptl;
 	pte_t entry;
 
+	if (check_stack_guard_page(vma, address) < 0)
+		return VM_FAULT_SIGBUS;
+
 	/* Allocate our own private page. */
 	pte_unmap(page_table);
author
#2 lore raw

PATCH 2/3 mm: fix missing page table unmap for stack guard page failure case

In reply to Greg KH

2.6.27-stable review patch. If anyone has any objections, please let us know.

------------------

From: Linus Torvalds <[email protected]>

commit 5528f9132cf65d4d892bcbc5684c61e7822b21e9 upstream.

.. which didn't show up in my tests because it's a no-op on x86-64 and most other architectures. But we enter the function with the last-level page table mapped, and should unmap it at exit.

Signed-off-by Linus Torvalds <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 mm/memory.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
mm/memory.c +3 -1
@@ -2428,8 +2428,10 @@ static int do_anonymous_page(struct mm_s
 	spinlock_t *ptl;
 	pte_t entry;
 
-	if (check_stack_guard_page(vma, address) < 0)
+	if (check_stack_guard_page(vma, address) < 0) {
+		pte_unmap(page_table);
 		return VM_FAULT_SIGBUS;
+	}
 
 	/* Allocate our own private page. */
 	pte_unmap(page_table);
author
#3 lore raw

PATCH 3/3 x86: dont send SIGBUS for kernel page faults

In reply to Greg KH

2.6.27-stable review patch. If anyone has any objections, please let us know.

------------------

Based on commit 96054569190bdec375fe824e48ca1f4e3b53dd36 upstream, authored by Linus Torvalds.

This is my backport to the .27 kernel tree, hopefully preserving the same functionality.

Original commit message:
It's wrong for several reasons, but the most direct one is that the fault may be for the stack accesses to set up a previous SIGBUS. When we have a kernel exception, the kernel exception handler does all the fixups, not some user-level signal handler.

Even apart from the nested SIGBUS issue, it's also wrong to give out kernel fault addresses in the signal handler info block, or to send a SIGBUS when a system call already returns EFAULT.

Cc Linus Torvalds <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 arch/x86/mm/fault.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
arch/x86/mm/fault.c +8 -1
@@ -589,6 +589,7 @@ void __kprobes do_page_fault(struct pt_r
 	unsigned long address;
 	int write, si_code;
 	int fault;
+	int should_exit_no_context = 0;
 #ifdef CONFIG_X86_64
 	unsigned long flags;
 #endif

@@ -876,6 +877,9 @@ no_context:
 	oops_end(flags, regs, SIGKILL);
 #endif
 
+	if (should_exit_no_context)
+		return;
+
 /*
  * We ran out of memory, or some other thing happened to us that made
  * us unable to handle the page fault gracefully.

@@ -901,8 +905,11 @@ do_sigbus:
 	up_read(&mm->mmap_sem);
 
 	/* Kernel mode? Handle exceptions or die */
-	if (!(error_code & PF_USER))
+	if (!(error_code & PF_USER)) {
+		should_exit_no_context = 1;
 		goto no_context;
+	}
+
 #ifdef CONFIG_X86_32
 	/* User space => ok to do another page fault */
 	if (is_prefetch(regs, address, error_code))
#4 lore raw
In reply to Greg KH
Quoted 5 lines · you

NOTE!

If I could get some people to please test this -rc release? It contains a few core changes that I couldn't validate myself as I don't seem to have a machine that will even boot the .27 kernel anymore after my move.

I surely will, just as soon as the thing appears ;) Ftp and http return nothing just now.

Grant.

Quoted 29 lines

I didn't want to include them in the last .27-stable release because of this, so any testing is much appreciated. Especially if you happen to run across any signal and/or stack issues that might be floating around in the ether...

----

This is the start of the stable review cycle for the 2.6.27.52 release. There are 3 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Monday, August 16, 2010, 20:00:00 UTC. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.27.52-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

Makefile            |    2 +-
arch/x86/mm/fault.c |    9 ++++++++-
mm/memory.c         |   25 +++++++++++++++++++++++++
3 files changed, 34 insertions(+), 2 deletions(-)
author
#5 lore raw
Quoted 10 lines · Grant Coady
Quoted 5 lines · you

NOTE!

If I could get some people to please test this -rc release? It contains a few core changes that I couldn't validate myself as I don't seem to have a machine that will even boot the .27 kernel anymore after my move.

I surely will, just as soon as the thing appears ;) Ftp and http return nothing just now.

Odd, it should be there.

Here it is, attached below. It's small enough to send out this way.

thanks,

greg k-h

Makefile +1 -1
index 5382c55..c7fde5f 100644
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 27
-EXTRAVERSION = .51
+EXTRAVERSION = .52-rc1
 NAME = Trembling Tortoise
 
 # *DOCUMENTATION*
arch/x86/mm/fault.c +8 -1
index 3384255..9d3c576 100644
@@ -589,6 +589,7 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigned long error_code)
 	unsigned long address;
 	int write, si_code;
 	int fault;
+	int should_exit_no_context = 0;
 #ifdef CONFIG_X86_64
 	unsigned long flags;
 #endif

@@ -876,6 +877,9 @@ no_context:
 	oops_end(flags, regs, SIGKILL);
 #endif
 
+	if (should_exit_no_context)
+		return;
+
 /*
  * We ran out of memory, or some other thing happened to us that made
  * us unable to handle the page fault gracefully.

@@ -901,8 +905,11 @@ do_sigbus:
 	up_read(&mm->mmap_sem);
 
 	/* Kernel mode? Handle exceptions or die */
-	if (!(error_code & PF_USER))
+	if (!(error_code & PF_USER)) {
+		should_exit_no_context = 1;
 		goto no_context;
+	}
+
 #ifdef CONFIG_X86_32
 	/* User space => ok to do another page fault */
 	if (is_prefetch(regs, address, error_code))
mm/memory.c +25 -0
index 1300b70..7e308fc 100644
@@ -2396,6 +2396,26 @@ out_nomap:
 }
 
 /*
+ * This is like a special single-page "expand_downwards()",
+ * except we must first make sure that 'address-PAGE_SIZE'
+ * doesn't hit another vma.
+ *
+ * The "find_vma()" will do the right thing even if we wrap
+ */
+static inline int check_stack_guard_page(struct vm_area_struct *vma, unsigned long address)
+{
+	address &= PAGE_MASK;
+	if ((vma->vm_flags & VM_GROWSDOWN) && address == vma->vm_start) {
+		address -= PAGE_SIZE;
+		if (find_vma(vma->vm_mm, address) != vma)
+			return -ENOMEM;
+
+		expand_stack(vma, address);
+	}
+	return 0;
+}
+
+/*
  * We enter with non-exclusive mmap_sem (to exclude vma changes,
  * but allow concurrent faults), and pte mapped but not yet locked.
  * We return with mmap_sem still held, but pte unmapped and unlocked.

@@ -2408,6 +2428,11 @@ static int do_anonymous_page(struct mm_struct *mm, struct vm_area_struct *vma,
 	spinlock_t *ptl;
 	pte_t entry;
 
+	if (check_stack_guard_page(vma, address) < 0) {
+		pte_unmap(page_table);
+		return VM_FAULT_SIGBUS;
+	}
+
 	/* Allocate our own private page. */
 	pte_unmap(page_table);
#6 lore raw

Hi Greg,

I scraped the patches out of the messages and edited Makefile :)

Quoted 8 lines · you
Quoted 7 lines · Grant Coady
Quoted 5 lines · you

NOTE!

If I could get some people to please test this -rc release? It contains a few core changes that I couldn't validate myself as I don't seem to have a machine that will even boot the .27 kernel anymore after my move.

Machine is running, but there's a lot of these in the dmesg:

WARNING: at include/linux/security.h:1826 acct_stack_growth+0xe7/0xf0()
Modules linked in:
Pid: 320, comm: khelper Not tainted 2.6.27.52-rc1a #57
 [<c011b54f>] warn_on_slowpath+0x5f/0x90
 [<c0145a53>] __alloc_pages_internal+0x93/0x420
 [<c01456bd>] buffered_rmqueue+0x11d/0x210
 [<c015e09a>] allocate_slab+0x4a/0xd0
 [<c015e149>] setup_object+0x29/0x30
 [<c015e204>] new_slab+0xb4/0x130
 [<c015e6ec>] __slab_alloc+0xac/0x120
 [<c01529e7>] acct_stack_growth+0xe7/0xf0
 [<c0152afa>] expand_stack+0x7a/0x90
 [<c014fc61>] do_anonymous_page+0x121/0x130
 [<c0150268>] handle_mm_fault+0x1b8/0x1e0
 [<c014e724>] get_user_pages+0xe4/0x270
 [<c0166ac9>] get_arg_page+0x49/0xc0
 [<c0166e5b>] copy_strings+0xdb/0x180
 [<c0166f29>] copy_strings_kernel+0x29/0x40
 [<c0167dae>] do_execve+0xde/0x1d0
 [<c0101f1f>] sys_execve+0x2f/0x60
 [<c0103036>] syscall_call+0x7/0xb
 [<c011007b>] ioapic_register_intr+0x10b/0x110
 [<c0106bfc>] kernel_execve+0x1c/0x30
 [<c0128efc>] ____call_usermodehelper+0x5c/0xc0
 [<c0128ea0>] ____call_usermodehelper+0x0/0xc0
 [<c0103b1b>] kernel_thread_helper+0x7/0x1c
 =======================
---[ end trace 62e879f3daf4be6a ]---

You can view the .config and dmesg at:

http://bugsplatter.id.au/kernel/boxen/deltree/config-2.6.27.52-rc1a.gz
http://bugsplatter.id.au/kernel/boxen/deltree/dmesg-2.6.27.52-rc1a.gz

Top and machine info:

http://bugsplatter.id.au/kernel/boxen/deltree/

Box is Internet facing firewall running Slackware-11.0 and I have my streaming audio ;) Can't be too bad.

Cheers,
Grant.

#7 lore raw
Quoted 4 lines · Grant Coady

Machine is running, but there's a lot of these in the dmesg:

WARNING: at include/linux/security.h:1826 acct_stack_growth+0xe7/0xf0()

That would seem to be because of the lack of commit 05fa199d45c in 2.6.27. It got marked for stable, but probably never went so far back as 2.6.27.

That said, I do wonder if it is worth it maintaining a 2.6.27 that the maintainer can't even boot on his machines any more.

Linus

author
#8 lore raw
Quoted 9 lines · Linus Torvalds
Quoted 4 lines · Grant Coady

Machine is running, but there's a lot of these in the dmesg:

WARNING: at include/linux/security.h:1826 acct_stack_growth+0xe7/0xf0()

That would seem to be because of the lack of commit 05fa199d45c in 2.6.27. It got marked for stable, but probably never went so far back as 2.6.27.

Yup, I didn't include it there. Grant, if you add that, does the warning go away?

Quoted 2 lines

That said, I do wonder if it is worth it maintaining a 2.6.27 that the maintainer can't even boot on his machines any more.

Yeah, I'm beginning to wonder about it as well. I think it's expected lifespan is very near to the end.

thanks,

greg k-h

#9 lore raw
Quoted 5 lines · you
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Grant Coady

Machine is running, but there's a lot of these in the dmesg:

Quoted 8 lines
Quoted 5 lines
Quoted 1 line
WARNING: at include/linux/security.h:1826 acct_stack_growth+0xe7/0xf0()

That would seem to be because of the lack of commit 05fa199d45c in 2.6.27. It got marked for stable, but probably never went so far back as 2.6.27.

Yup, I didn't include it there. Grant, if you add that, does the warning go away?

I'm sorry, no idea at all how to cherry pick that, I don't know git :(

Google brings up this thread but not that commit, point me at it and I'll try it.

Grant.

Quoted 10 lines
Quoted 3 lines

That said, I do wonder if it is worth it maintaining a 2.6.27 that the maintainer can't even boot on his machines any more.

Yeah, I'm beginning to wonder about it as well. I think it's expected lifespan is very near to the end.

thanks,

greg k-h

#10 lore raw
Quoted 13 lines · Grant Coady
Quoted 11 lines · you
Quoted 9 lines · Linus Torvalds
Quoted 4 lines · Grant Coady

Machine is running, but there's a lot of these in the dmesg:

WARNING: at include/linux/security.h:1826 acct_stack_growth+0xe7/0xf0()

That would seem to be because of the lack of commit 05fa199d45c in 2.6.27. It got marked for stable, but probably never went so far back as 2.6.27.

Quoted 7 lines
Quoted 2 lines

Yup, I didn't include it there. Grant, if you add that, does the warning go away?

I'm sorry, no idea at all how to cherry pick that, I don't know git :(

Google brings up this thread but not that commit, point me at it and I'll try it.

Simply apply this patch (even by hand) :

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=05fa199d45c

It solved the warnings for me.

Cheers,
Willy

#11 lore raw
Quoted 19 lines · you
Quoted 18 lines · Grant Coady
Quoted 5 lines · you
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Grant Coady

Machine is running, but there's a lot of these in the dmesg:

Quoted 8 lines
Quoted 5 lines
Quoted 1 line
WARNING: at include/linux/security.h:1826 acct_stack_growth+0xe7/0xf0()

That would seem to be because of the lack of commit 05fa199d45c in 2.6.27. It got marked for stable, but probably never went so far back as 2.6.27.

Yup, I didn't include it there. Grant, if you add that, does the warning go away?

I'm sorry, no idea at all how to cherry pick that, I don't know git :(

Quoted 8 lines
Quoted 2 lines

Google brings up this thread but not that commit, point me at it and I'll try it.

Simply apply this patch (even by hand) :

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=05fa199d45c

It solved the warnings for me.

Thanks Willy, got:

grant@deltree:~/linux/linux-2.6.27.52-rc1b$ patch -p1 < ../patch-05fa199d45c
patching file mm/mmap.c
Hunk #1 succeeded at 1573 (offset -2 lines).

Compiling. . .

Yup, works for me :)

http://bugsplatter.id.au/kernel/boxen/deltree/dmesg-2.6.27.52-rc1b.gz

Cheers,
Grant.

author
#12 lore raw
In reply to Grant Coady
Quoted 37 lines · Grant Coady

Hi Greg,

I scraped the patches out of the messages and edited Makefile :)

Quoted 8 lines · you
Quoted 7 lines · Grant Coady
Quoted 5 lines · you

NOTE!

If I could get some people to please test this -rc release? It contains a few core changes that I couldn't validate myself as I don't seem to have a machine that will even boot the .27 kernel anymore after my move.

Machine is running, but there's a lot of these in the dmesg:

WARNING: at include/linux/security.h:1826 acct_stack_growth+0xe7/0xf0()
Modules linked in:
Pid: 320, comm: khelper Not tainted 2.6.27.52-rc1a #57
 [<c011b54f>] warn_on_slowpath+0x5f/0x90
 [<c0145a53>] __alloc_pages_internal+0x93/0x420
 [<c01456bd>] buffered_rmqueue+0x11d/0x210
 [<c015e09a>] allocate_slab+0x4a/0xd0
 [<c015e149>] setup_object+0x29/0x30
 [<c015e204>] new_slab+0xb4/0x130
 [<c015e6ec>] __slab_alloc+0xac/0x120
 [<c01529e7>] acct_stack_growth+0xe7/0xf0
 [<c0152afa>] expand_stack+0x7a/0x90
 [<c014fc61>] do_anonymous_page+0x121/0x130
 [<c0150268>] handle_mm_fault+0x1b8/0x1e0
 [<c014e724>] get_user_pages+0xe4/0x270
 [<c0166ac9>] get_arg_page+0x49/0xc0
 [<c0166e5b>] copy_strings+0xdb/0x180
 [<c0166f29>] copy_strings_kernel+0x29/0x40
 [<c0167dae>] do_execve+0xde/0x1d0
 [<c0101f1f>] sys_execve+0x2f/0x60
Quoted 8 lines
 [<c0103036>] syscall_call+0x7/0xb
 [<c011007b>] ioapic_register_intr+0x10b/0x110
 [<c0106bfc>] kernel_execve+0x1c/0x30
 [<c0128efc>] ____call_usermodehelper+0x5c/0xc0
 [<c0128ea0>] ____call_usermodehelper+0x0/0xc0
 [<c0103b1b>] kernel_thread_helper+0x7/0x1c
 =======================
---[ end trace 62e879f3daf4be6a ]---

I'm guessing that 2.6.27.51 didn't cause those warnings as well?

That's a warning that current->mm is null. I don't know enough about the mm subsystem to say if this is normal or not, and I don't at first glance, see how this patch could have caused this to happen.

Anyone else have an idea?

thanks,

greg k-h

#13 lore raw
Quoted 4 lines · Greg KH

That's a warning that current->mm is null.  I don't know enough about the mm subsystem to say if this is normal or not, and I don't at first glance, see how this patch could have caused this to happen.

We call that whole "expand_stack()" through handle_mm_fault(), and that's _not_ called just for the process itself. So "current->mm" is sometimes simply the wrong thing to use - like when you access the VM of another process (during fork for the argument setup of the new VM, or during ptrace etc).

Which is why I think commit 05fa199d45c should fix it. It makes the stack expansion thing use the right mm. Which it just _happened_ to do before, because it was always called just from the faulting code where current->mm happened to be the right mm.

But I really don't know if there might be other issues lurking too.

Linus

author
#14 lore raw
Quoted 12 lines · Linus Torvalds
Quoted 4 lines · Greg KH

That's a warning that current->mm is null.  I don't know enough about the mm subsystem to say if this is normal or not, and I don't at first glance, see how this patch could have caused this to happen.

We call that whole "expand_stack()" through handle_mm_fault(), and that's _not_ called just for the process itself. So "current->mm" is sometimes simply the wrong thing to use - like when you access the VM of another process (during fork for the argument setup of the new VM, or during ptrace etc).

Quoted 6 lines

Which is why I think commit 05fa199d45c should fix it. It makes the stack expansion thing use the right mm. Which it just _happened_ to do before, because it was always called just from the faulting code where current->mm happened to be the right mm.

But I really don't know if there might be other issues lurking too.

Ok, I'll go add that commit, and I unpacked my older machine that runs the .27 kernel and will beat on it with that box tomorrow to see if anything else pops up.

thanks,

greg k-h

#15 lore raw
Quoted 18 lines · Greg KH
Quoted 17 lines · Linus Torvalds
Quoted 4 lines · Greg KH

That's a warning that current->mm is null.  I don't know enough about the mm subsystem to say if this is normal or not, and I don't at first glance, see how this patch could have caused this to happen.

We call that whole "expand_stack()" through handle_mm_fault(), and that's _not_ called just for the process itself. So "current->mm" is sometimes simply the wrong thing to use - like when you access the VM of another process (during fork for the argument setup of the new VM, or during ptrace etc).

Which is why I think commit 05fa199d45c should fix it. It makes the stack expansion thing use the right mm. Which it just _happened_ to do before, because it was always called just from the faulting code where current->mm happened to be the right mm.

Quoted 5 lines
Quoted 1 line

But I really don't know if there might be other issues lurking too.

Ok, I'll go add that commit, and I unpacked my older machine that runs the .27 kernel and will beat on it with that box tomorrow to see if anything else pops up.

Greg, I confirm that 05fa199d45c fixes the warnings. I did not have them in .51, got them with .52-rc1 and got rid of it with the patch above.

Regards,
Willy

#16 lore raw
Quoted 19 lines · Willy Tarreau
Quoted 18 lines · Greg KH
Quoted 17 lines · Linus Torvalds
Quoted 4 lines · Greg KH

That's a warning that current->mm is null.  I don't know enough about the mm subsystem to say if this is normal or not, and I don't at first glance, see how this patch could have caused this to happen.

We call that whole "expand_stack()" through handle_mm_fault(), and that's _not_ called just for the process itself. So "current->mm" is sometimes simply the wrong thing to use - like when you access the VM of another process (during fork for the argument setup of the new VM, or during ptrace etc).

Which is why I think commit 05fa199d45c should fix it. It makes the stack expansion thing use the right mm. Which it just _happened_ to do before, because it was always called just from the faulting code where current->mm happened to be the right mm.

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

But I really don't know if there might be other issues lurking too.

Ok, I'll go add that commit, and I unpacked my older machine that runs the .27 kernel and will beat on it with that box tomorrow to see if anything else pops up.

Greg, I confirm that 05fa199d45c fixes the warnings. I did not have them in .51, got them with .52-rc1 and got rid of it with the patch above.

Wonderful. I've released a 2.6.27.52-rc2 with this fix in it. I'm building it and will test it on my box now. The full patch is below if anyone wants to try it out.

Odds are it will need whatever patch Linus is currently working on for mainline, so I'll hold off on releasing a real release until that is all worked out.

thanks,

greg k-h

Makefile +1 -1
index 5382c55..096cde6 100644
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 27
-EXTRAVERSION = .51
+EXTRAVERSION = .52-rc2
 NAME = Trembling Tortoise
 
 # *DOCUMENTATION*
arch/x86/mm/fault.c +8 -1
index 3384255..9d3c576 100644
@@ -589,6 +589,7 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigned long error_code)
 	unsigned long address;
 	int write, si_code;
 	int fault;
+	int should_exit_no_context = 0;
 #ifdef CONFIG_X86_64
 	unsigned long flags;
 #endif

@@ -876,6 +877,9 @@ no_context:
 	oops_end(flags, regs, SIGKILL);
 #endif
 
+	if (should_exit_no_context)
+		return;
+
 /*
  * We ran out of memory, or some other thing happened to us that made
  * us unable to handle the page fault gracefully.

@@ -901,8 +905,11 @@ do_sigbus:
 	up_read(&mm->mmap_sem);
 
 	/* Kernel mode? Handle exceptions or die */
-	if (!(error_code & PF_USER))
+	if (!(error_code & PF_USER)) {
+		should_exit_no_context = 1;
 		goto no_context;
+	}
+
 #ifdef CONFIG_X86_32
 	/* User space => ok to do another page fault */
 	if (is_prefetch(regs, address, error_code))
mm/memory.c +25 -0
index 1300b70..7e308fc 100644
@@ -2396,6 +2396,26 @@ out_nomap:
 }
 
 /*
+ * This is like a special single-page "expand_downwards()",
+ * except we must first make sure that 'address-PAGE_SIZE'
+ * doesn't hit another vma.
+ *
+ * The "find_vma()" will do the right thing even if we wrap
+ */
+static inline int check_stack_guard_page(struct vm_area_struct *vma, unsigned long address)
+{
+	address &= PAGE_MASK;
+	if ((vma->vm_flags & VM_GROWSDOWN) && address == vma->vm_start) {
+		address -= PAGE_SIZE;
+		if (find_vma(vma->vm_mm, address) != vma)
+			return -ENOMEM;
+
+		expand_stack(vma, address);
+	}
+	return 0;
+}
+
+/*
  * We enter with non-exclusive mmap_sem (to exclude vma changes,
  * but allow concurrent faults), and pte mapped but not yet locked.
  * We return with mmap_sem still held, but pte unmapped and unlocked.

@@ -2408,6 +2428,11 @@ static int do_anonymous_page(struct mm_struct *mm, struct vm_area_struct *vma,
 	spinlock_t *ptl;
 	pte_t entry;
 
+	if (check_stack_guard_page(vma, address) < 0) {
+		pte_unmap(page_table);
+		return VM_FAULT_SIGBUS;
+	}
+
 	/* Allocate our own private page. */
 	pte_unmap(page_table);
mm/mmap.c +1 -1
index f3e5bfe..08a32cf 100644
@@ -1573,7 +1573,7 @@ static int acct_stack_growth(struct vm_area_struct * vma, unsigned long size, un
 	 * Overcommit..  This must be the final test, as it will
 	 * update security statistics.
 	 */
-	if (security_vm_enough_memory(grow))
+	if (security_vm_enough_memory_mm(mm, grow))
 		return -ENOMEM;
 
 	/* Ok, everything looks good - let it rip */
author
#17 lore raw
In reply to Greg KH
Quoted 18 lines · Greg KH
Quoted 17 lines · Linus Torvalds
Quoted 4 lines · Greg KH

That's a warning that current->mm is null.  I don't know enough about the mm subsystem to say if this is normal or not, and I don't at first glance, see how this patch could have caused this to happen.

We call that whole "expand_stack()" through handle_mm_fault(), and that's _not_ called just for the process itself. So "current->mm" is sometimes simply the wrong thing to use - like when you access the VM of another process (during fork for the argument setup of the new VM, or during ptrace etc).

Which is why I think commit 05fa199d45c should fix it. It makes the stack expansion thing use the right mm. Which it just _happened_ to do before, because it was always called just from the faulting code where current->mm happened to be the right mm.

Quoted 5 lines
Quoted 1 line

But I really don't know if there might be other issues lurking too.

Ok, I'll go add that commit, and I unpacked my older machine that runs the .27 kernel and will beat on it with that box tomorrow to see if anything else pops up.

It's booting here, but I'm out of time and have to go on vacation until Monday night and I'll pick this up on Tuesday again when I get back.

thanks,

greg k-h

#18 lore raw
In reply to Greg KH
Quoted 47 lines · you
Quoted 37 lines · Grant Coady

Hi Greg,

I scraped the patches out of the messages and edited Makefile :)

Quoted 8 lines · you
Quoted 7 lines · Grant Coady
Quoted 5 lines · you

NOTE!

If I could get some people to please test this -rc release? It contains a few core changes that I couldn't validate myself as I don't seem to have a machine that will even boot the .27 kernel anymore after my move.

Machine is running, but there's a lot of these in the dmesg:

WARNING: at include/linux/security.h:1826 acct_stack_growth+0xe7/0xf0()
Modules linked in:
Pid: 320, comm: khelper Not tainted 2.6.27.52-rc1a #57
 [<c011b54f>] warn_on_slowpath+0x5f/0x90
 [<c0145a53>] __alloc_pages_internal+0x93/0x420
 [<c01456bd>] buffered_rmqueue+0x11d/0x210
 [<c015e09a>] allocate_slab+0x4a/0xd0
 [<c015e149>] setup_object+0x29/0x30
 [<c015e204>] new_slab+0xb4/0x130
 [<c015e6ec>] __slab_alloc+0xac/0x120
 [<c01529e7>] acct_stack_growth+0xe7/0xf0
 [<c0152afa>] expand_stack+0x7a/0x90
 [<c014fc61>] do_anonymous_page+0x121/0x130
 [<c0150268>] handle_mm_fault+0x1b8/0x1e0
 [<c014e724>] get_user_pages+0xe4/0x270
 [<c0166ac9>] get_arg_page+0x49/0xc0
 [<c0166e5b>] copy_strings+0xdb/0x180
 [<c0166f29>] copy_strings_kernel+0x29/0x40
 [<c0167dae>] do_execve+0xde/0x1d0
 [<c0101f1f>] sys_execve+0x2f/0x60
Quoted 8 lines
 [<c0103036>] syscall_call+0x7/0xb
 [<c011007b>] ioapic_register_intr+0x10b/0x110
 [<c0106bfc>] kernel_execve+0x1c/0x30
 [<c0128efc>] ____call_usermodehelper+0x5c/0xc0
 [<c0128ea0>] ____call_usermodehelper+0x0/0xc0
 [<c0103b1b>] kernel_thread_helper+0x7/0x1c
 =======================
---[ end trace 62e879f3daf4be6a ]---
Quoted 1 line

I'm guessing that 2.6.27.51 didn't cause those warnings as well?

Not in .51, the .51 dmesg is up now too:

http://bugsplatter.id.au/kernel/boxen/deltree/dmesg-2.6.27.51a.gz

Quoted 10 lines

That's a warning that current->mm is null. I don't know enough about the mm subsystem to say if this is normal or not, and I don't at first glance, see how this patch could have caused this to happen.

Anyone else have an idea?

thanks,

greg k-h

#19 lore raw
Quoted 49 lines · Grant Coady
Quoted 47 lines · you
Quoted 45 lines · Grant Coady

Hi Greg,

I scraped the patches out of the messages and edited Makefile :)

Quoted 8 lines · you
Quoted 7 lines · Grant Coady
Quoted 5 lines · you

NOTE!

If I could get some people to please test this -rc release? It contains a few core changes that I couldn't validate myself as I don't seem to have a machine that will even boot the .27 kernel anymore after my move.

Machine is running, but there's a lot of these in the dmesg:

WARNING: at include/linux/security.h:1826 acct_stack_growth+0xe7/0xf0()
Modules linked in:
Pid: 320, comm: khelper Not tainted 2.6.27.52-rc1a #57
 [<c011b54f>] warn_on_slowpath+0x5f/0x90
 [<c0145a53>] __alloc_pages_internal+0x93/0x420
 [<c01456bd>] buffered_rmqueue+0x11d/0x210
 [<c015e09a>] allocate_slab+0x4a/0xd0
 [<c015e149>] setup_object+0x29/0x30
 [<c015e204>] new_slab+0xb4/0x130
 [<c015e6ec>] __slab_alloc+0xac/0x120
 [<c01529e7>] acct_stack_growth+0xe7/0xf0
 [<c0152afa>] expand_stack+0x7a/0x90
 [<c014fc61>] do_anonymous_page+0x121/0x130
 [<c0150268>] handle_mm_fault+0x1b8/0x1e0
 [<c014e724>] get_user_pages+0xe4/0x270
 [<c0166ac9>] get_arg_page+0x49/0xc0
 [<c0166e5b>] copy_strings+0xdb/0x180
 [<c0166f29>] copy_strings_kernel+0x29/0x40
 [<c0167dae>] do_execve+0xde/0x1d0
 [<c0101f1f>] sys_execve+0x2f/0x60
 [<c0103036>] syscall_call+0x7/0xb
 [<c011007b>] ioapic_register_intr+0x10b/0x110
 [<c0106bfc>] kernel_execve+0x1c/0x30
 [<c0128efc>] ____call_usermodehelper+0x5c/0xc0
 [<c0128ea0>] ____call_usermodehelper+0x0/0xc0
 [<c0103b1b>] kernel_thread_helper+0x7/0x1c
 =======================
---[ end trace 62e879f3daf4be6a ]---
Quoted 5 lines
Quoted 1 line

I'm guessing that 2.6.27.51 didn't cause those warnings as well?

Not in .51, the .51 dmesg is up now too:

http://bugsplatter.id.au/kernel/boxen/deltree/dmesg-2.6.27.51a.gz

Thanks, can you try 2.6.52-rc2 now? It should have the fix for this in it.

greg k-h

#21 lore raw
In reply to Greg KH
Quoted 10 lines · Greg KH

NOTE!

If I could get some people to please test this -rc release? It contains a few core changes that I couldn't validate myself as I don't seem to have a machine that will even boot the .27 kernel anymore after my move.

I didn't want to include them in the last .27-stable release because of this, so any testing is much appreciated. Especially if you happen to run across any signal and/or stack issues that might be floating around in the ether...

I will try it, Greg. If you want specific tests, do not hesitate to tell me which ones.

Willy

#22 lore raw
In reply to Greg KH

* Greg KH <[email protected]>:

| If I could get some people to please test this -rc release?

BTW seems like 2.6.27 no more combatible with GNU Make 3.82:

$ make oldconfig
Makefile:443: *** mixed implicit and normal rules.  Stop.

Same with line 1609.

Makefile renamed from Makefile.orig +10 -2
@@ -440,7 +440,11 @@
 include $(srctree)/arch/$(SRCARCH)/Makefile
 export KBUILD_DEFCONFIG
 
-config %config: scripts_basic outputmakefile FORCE
+config: scripts_basic outputmakefile FORCE
+	$(Q)mkdir -p include/linux include/config
+	$(Q)$(MAKE) $(build)=scripts/kconfig $@
+
+%config: scripts_basic outputmakefile FORCE
 	$(Q)mkdir -p include/linux include/config
 	$(Q)$(MAKE) $(build)=scripts/kconfig $@
 

@@ -1602,7 +1606,11 @@
 	$(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
 
 # Modules
-/ %/: prepare scripts FORCE
+/: prepare scripts FORCE
+	$(cmd_crmodverdir)
+	$(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
+	$(build)=$(build-dir)
+%/: prepare scripts FORCE
 	$(cmd_crmodverdir)
 	$(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
 	$(build)=$(build-dir)
#23 lore raw
Quoted 10 lines · you

* Greg KH <[email protected]>:

| If I could get some people to please test this -rc release?

BTW seems like 2.6.27 no more combatible with GNU Make 3.82:

$ make oldconfig
Makefile:443: *** mixed implicit and normal rules.  Stop.

Same with line 1609.

I have:

grant@deltree:~$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i486-slackware-linux-gnu

and 2.6.27 builds here just fine.

Grant.

author
#24 lore raw
In reply to Gabor Z. Papp
Quoted 10 lines · Gabor Z. Papp

* Greg KH <[email protected]>:

| If I could get some people to please test this -rc release?

BTW seems like 2.6.27 no more combatible with GNU Make 3.82:

$ make oldconfig
Makefile:443: *** mixed implicit and normal rules.  Stop.

Same with line 1609.

Nothing has changed with the main Makefile with the exception of changing the version number for a very long time.

Did something else change on your system?

odd,

greg k-h

#25 lore raw

Greg KH skrev 15.8.2010 00:01:

Quoted 10 lines · Gabor Z. Papp
Quoted 9 lines

* Greg KH<[email protected]>:

| If I could get some people to please test this -rc release?

BTW seems like 2.6.27 no more combatible with GNU Make 3.82:

$ make oldconfig
Makefile:443: *** mixed implicit and normal rules.  Stop.
Quoted 9 lines
Quoted 1 line

Same with line 1609.

Nothing has changed with the main Makefile with the exception of changing the version number for a very long time.

Did something else change on your system?

odd,

2.6.27 needs this wich went in after 2.6.28-rc8:

kbuild: fix make incompatibility
author Sam Ravnborg <[email protected]>

	Sat, 13 Dec 2008 22:00:45 +0000 (23:00 +0100)
committer	Sam Ravnborg <[email protected]>	
	Sat, 13 Dec 2008 22:00:45 +0000 (23:00 +0100)

commit 31110ebbec8688c6e9597b641101afc94e1c762a
tree 208aaad7e40cbb86bc125760664911da8cd4eebb tree | snapshot
parent abf681ce5b6f83f0b8883e0f2c12d197a38543dd commit | diff
kbuild: fix make incompatibility

"Paul Smith" <[email protected]> reported that we would fail to build with a new check that may be enabled in an upcoming version of make.

The error was:

Makefile:442: *** mixed implicit and normal rules. Stop.

And I assume the powerpc make-3.82 fix (e32e78c5ee8aadef020fbaecbe6fb741ed9029fd) needs to be added to 2.6.27 too...

--
Thomas

#26 lore raw
Quoted 21 lines · Thomas Backlund

Greg KH skrev 15.8.2010 00:01:

Quoted 10 lines · Gabor Z. Papp
Quoted 9 lines

* Greg KH<[email protected]>:

| If I could get some people to please test this -rc release?

BTW seems like 2.6.27 no more combatible with GNU Make 3.82:

$ make oldconfig
Makefile:443: *** mixed implicit and normal rules.  Stop.
Quoted 9 lines
Quoted 1 line

Same with line 1609.

Nothing has changed with the main Makefile with the exception of changing the version number for a very long time.

Did something else change on your system?

odd,

Quoted 8 lines

2.6.27 needs this wich went in after 2.6.28-rc8:

kbuild: fix make incompatibility
author Sam Ravnborg <[email protected]>

	Sat, 13 Dec 2008 22:00:45 +0000 (23:00 +0100)
committer	Sam Ravnborg <[email protected]>	
	Sat, 13 Dec 2008 22:00:45 +0000 (23:00 +0100)

commit 31110ebbec8688c6e9597b641101afc94e1c762a

Now applied.

thanks,

greg k-h