From: Greg KH <gregkh@suse.de>
To: Grant Coady <gcoady.lk@gmail.com>
Cc: linux-kernel@vger.kernel.org, stable@kernel.org,
stable-review@kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk
Subject: Re: [0/3] 2.6.27.52 stable review
Date: Fri, 13 Aug 2010 16:07:12 -0700 [thread overview]
Message-ID: <20100813230712.GA1703@suse.de> (raw)
In-Reply-To: <p5ib66db7ilijjesu4dd3b351dtmsk175f@4ax.com>
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
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
[-- Attachment #2: patch-2.6.27.52-rc1 --]
[-- Type: text/plain, Size: 2439 bytes --]
diff --git a/Makefile b/Makefile
index 5382c55..c7fde5f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 27
-EXTRAVERSION = .51
+EXTRAVERSION = .52-rc1
NAME = Trembling Tortoise
# *DOCUMENTATION*
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 3384255..9d3c576 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -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))
diff --git a/mm/memory.c b/mm/memory.c
index 1300b70..7e308fc 100644
--- 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,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);
next prev parent reply other threads:[~2010-08-13 23:13 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-13 21:47 [0/3] 2.6.27.52 stable review Greg KH
2010-08-13 21:42 ` [1/3] mm: keep a guard page below a grow-down stack segment Greg KH
2010-08-13 21:42 ` [2/3] mm: fix missing page table unmap for stack guard page failure case Greg KH
2010-08-13 21:42 ` [3/3] x86: dont send SIGBUS for kernel page faults Greg KH
2010-08-13 22:36 ` [0/3] 2.6.27.52 stable review Grant Coady
2010-08-13 23:07 ` Greg KH [this message]
2010-08-13 23:47 ` Grant Coady
2010-08-14 0:11 ` Greg KH
2010-08-14 0:51 ` Linus Torvalds
2010-08-14 2:53 ` Greg KH
2010-08-14 5:43 ` [Stable-review] " Willy Tarreau
2010-08-14 18:47 ` [stable] " Greg KH
2010-08-14 21:46 ` Greg KH
2010-08-14 7:24 ` Grant Coady
2010-08-14 19:12 ` [stable] " Greg KH
2010-08-15 1:28 ` Grant Coady
2010-08-14 0:12 ` Linus Torvalds
2010-08-14 0:47 ` Greg KH
2010-08-14 7:34 ` Grant Coady
2010-08-14 7:43 ` [Stable-review] " Willy Tarreau
2010-08-14 8:52 ` Grant Coady
2010-08-13 22:45 ` Willy Tarreau
2010-08-14 11:11 ` Gabor Z. Papp
2010-08-14 15:00 ` 2.6.27.52 " Grant Coady
2010-08-14 21:01 ` Greg KH
2010-08-14 22:11 ` Thomas Backlund
2010-08-23 22:27 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100813230712.GA1703@suse.de \
--to=gregkh@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=gcoady.lk@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable-review@kernel.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.