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(-)
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(-)
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -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);
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(+)
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -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);
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(-)
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -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))
On Fri, 13 Aug 2010 14:47:04 -0700, you wrote:
>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.
>
>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(-)
On Fri, Aug 13, 2010 at 02:47:04PM -0700, Greg KH wrote:
> 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
On Sat, Aug 14, 2010 at 08:36:34AM +1000, Grant Coady wrote:
> On Fri, 13 Aug 2010 14:47:04 -0700, you wrote:
>
> >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
Hi Greg,
I scraped the patches out of the messages and edited Makefile :)
On Fri, 13 Aug 2010 16:07:12 -0700, you wrote:
>On Sat, Aug 14, 2010 at 08:36:34AM +1000, Grant Coady wrote:
>> On Fri, 13 Aug 2010 14:47:04 -0700, you wrote:
>>
>> >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.
On Fri, Aug 13, 2010 at 4:47 PM, Grant Coady <[email protected]> wrote:
>
> 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
On Sat, Aug 14, 2010 at 09:47:08AM +1000, Grant Coady wrote:
> Hi Greg,
>
> I scraped the patches out of the messages and edited Makefile :)
>
> On Fri, 13 Aug 2010 16:07:12 -0700, you wrote:
>
> >On Sat, Aug 14, 2010 at 08:36:34AM +1000, Grant Coady wrote:
> >> On Fri, 13 Aug 2010 14:47:04 -0700, you wrote:
> >>
> >> >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 ]---
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
On Fri, Aug 13, 2010 at 05:12:57PM -0700, Linus Torvalds wrote:
> On Fri, Aug 13, 2010 at 4:47 PM, Grant Coady <[email protected]> wrote:
> >
> > 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?
> 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
On Fri, Aug 13, 2010 at 5:11 PM, Greg KH <[email protected]> wrote:
>
> 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
On Fri, Aug 13, 2010 at 05:51:56PM -0700, Linus Torvalds wrote:
> On Fri, Aug 13, 2010 at 5:11 PM, Greg KH <[email protected]> wrote:
> >
> > 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.
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
On Fri, Aug 13, 2010 at 07:53:23PM -0700, Greg KH wrote:
> On Fri, Aug 13, 2010 at 05:51:56PM -0700, Linus Torvalds wrote:
> > On Fri, Aug 13, 2010 at 5:11 PM, Greg KH <[email protected]> wrote:
> > >
> > > 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.
>
> 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
On Fri, 13 Aug 2010 17:11:58 -0700, you wrote:
>On Sat, Aug 14, 2010 at 09:47:08AM +1000, Grant Coady wrote:
>> Hi Greg,
>>
>> I scraped the patches out of the messages and edited Makefile :)
>>
>> On Fri, 13 Aug 2010 16:07:12 -0700, you wrote:
>>
>> >On Sat, Aug 14, 2010 at 08:36:34AM +1000, Grant Coady wrote:
>> >> On Fri, 13 Aug 2010 14:47:04 -0700, you wrote:
>> >>
>> >> >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 ]---
>
>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
>
>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
On Sat, Aug 14, 2010 at 05:34:55PM +1000, Grant Coady wrote:
> On Fri, 13 Aug 2010 17:47:29 -0700, you wrote:
>
> >On Fri, Aug 13, 2010 at 05:12:57PM -0700, Linus Torvalds wrote:
> >> On Fri, Aug 13, 2010 at 4:47 PM, Grant Coady <[email protected]> wrote:
> >> >
> >> > 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?
>
> 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
On Fri, 13 Aug 2010 17:47:29 -0700, you wrote:
>On Fri, Aug 13, 2010 at 05:12:57PM -0700, Linus Torvalds wrote:
>> On Fri, Aug 13, 2010 at 4:47 PM, Grant Coady <[email protected]> wrote:
>> >
>> > 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?
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.
>
>> 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
On Sat, 14 Aug 2010 09:43:33 +0200, you wrote:
>On Sat, Aug 14, 2010 at 05:34:55PM +1000, Grant Coady wrote:
>> On Fri, 13 Aug 2010 17:47:29 -0700, you wrote:
>>
>> >On Fri, Aug 13, 2010 at 05:12:57PM -0700, Linus Torvalds wrote:
>> >> On Fri, Aug 13, 2010 at 4:47 PM, Grant Coady <[email protected]> wrote:
>> >> >
>> >> > 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?
>>
>> 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.
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.
On Sat, Aug 14, 2010 at 07:43:35AM +0200, Willy Tarreau wrote:
> On Fri, Aug 13, 2010 at 07:53:23PM -0700, Greg KH wrote:
> > On Fri, Aug 13, 2010 at 05:51:56PM -0700, Linus Torvalds wrote:
> > > On Fri, Aug 13, 2010 at 5:11 PM, Greg KH <[email protected]> wrote:
> > > >
> > > > 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.
> >
> > 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
On Sat, Aug 14, 2010 at 05:24:36PM +1000, Grant Coady wrote:
> On Fri, 13 Aug 2010 17:11:58 -0700, you wrote:
>
> >On Sat, Aug 14, 2010 at 09:47:08AM +1000, Grant Coady wrote:
> >> Hi Greg,
> >>
> >> I scraped the patches out of the messages and edited Makefile :)
> >>
> >> On Fri, 13 Aug 2010 16:07:12 -0700, you wrote:
> >>
> >> >On Sat, Aug 14, 2010 at 08:36:34AM +1000, Grant Coady wrote:
> >> >> On Fri, 13 Aug 2010 14:47:04 -0700, you wrote:
> >> >>
> >> >> >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 ]---
> >
> >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
On Fri, Aug 13, 2010 at 07:53:23PM -0700, Greg KH wrote:
> On Fri, Aug 13, 2010 at 05:51:56PM -0700, Linus Torvalds wrote:
> > On Fri, Aug 13, 2010 at 5:11 PM, Greg KH <[email protected]> wrote:
> > >
> > > 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.
>
> 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
On Sat, 14 Aug 2010 12:12:24 -0700, you wrote:
>Thanks, can you try 2.6.52-rc2 now? It should have the fix for this in
>it.
Yup, looks good here :)
http://bugsplatter.id.au/kernel/boxen/deltree/dmesg-2.6.27.52-rc2a.gz
Grant.