public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: linux-kernel@vger.kernel.org
Subject: 2.6.5-aa1
Date: Sun, 4 Apr 2004 07:22:56 +0200	[thread overview]
Message-ID: <20040404052256.GA2164@dualathlon.random> (raw)

This fixes a tiny race in the recent mprotect merging code, here's the
intradiff for review, plus it merges some nice lowlatency improvement
from Takashi.

--- x/mm/mprotect.c.~1~	2004-04-04 06:26:09.226033712 +0200
+++ x/mm/mprotect.c	2004-04-04 06:29:37.165422120 +0200
@@ -196,12 +196,18 @@ mprotect_attempt_merge(struct vm_area_st
 
 	/*
 	 * Otherwise extend it.
+	 * We need the anon_vma_lock only for "vma" since it's changing
+	 * vma->vm_start and vma->vm_pgoff. prev->vm_start and
+	 * prev->vm_pgoff are unchanged so the race on prev->vm_end
+	 * is controlled w/o explicit anon-vma locking.
 	 */
 	if (file)
 		down(i_shared_sem);
+	anon_vma_lock(vma);
 	__vma_modify(root, prev, prev->vm_start, end, prev->vm_pgoff);
 	__vma_modify(root, vma, end, vma->vm_end,
 		     vma->vm_pgoff + ((end - vma->vm_start) >> PAGE_SHIFT));
+	anon_vma_unlock(vma);
 	if (file)
 		up(i_shared_sem);
 	return 1;
@@ -264,6 +270,7 @@ mprotect_attempt_merge_final(struct vm_a
 
 	if (file)
 		down(i_shared_sem);
+	/* no need of anon_vma_lock for any "vm_end" extension */
 	__vma_modify(root, prev, prev->vm_start,
 		     next->vm_end, prev->vm_pgoff);
 

I didn't yet merge the ppc patch because I'm not really sure it's
necessary (how can it not oops in the first place, if that patch was
needed? OTOH certainly that patch cannot hurt either but I'll wait
feedback from the testing first).  The only pending bug at the moment is
the gfp-no-compound related crash from Christoph on ppc showing
page->private corrupted. I currently doubt it's a bug in my changes,
though I cannot exclude it either. As soon as I get the results from the
three debugging patches I will know more about it. I definitely cannot
reproduce anything wrong here, and the gfp-no-compound fixed the last
swap-suspend related glitch plus it makes the interface with the drivers
more robust.

URL:

	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.6/2.6.5-aa1.gz
	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.6/2.6.5-aa1/

Changelog diff between 2.6.5-rc3-aa3 and 2.6.5-aa1:

Files 2.6.5-rc3-aa3/disable-cap-mlock and 2.6.5-aa1/disable-cap-mlock differ
Files 2.6.5-rc3-aa3/extraversion and 2.6.5-aa1/extraversion differ
Files 2.6.5-rc3-aa3/prio-tree.gz and 2.6.5-aa1/prio-tree.gz differ

	Rediffed due rejects.

Files 2.6.5-rc3-aa3/mprotect-vma-merging and 2.6.5-aa1/mprotect-vma-merging differ

	Fixed race condition in mprotect, must hold the anon_vma_lock()
	while moving either ->vm_start or ->vm_pgoff (extending the vm_end
	doesn't need it instead since the race is controlled w/o explicit
	locking).

Only in 2.6.5-aa1: unmap_vmas-lat

	Don't threat no-preempt differently from -preempt w.r.t. worst case
	latencies.

Only in 2.6.5-aa1: writeback-lat

	Merged Takashi Iwai's lowlatency fixes adding missing schedule points,
	reducing greatly the worst case latency with preempt disabled.

             reply	other threads:[~2004-04-04  5:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-04  5:22 Andrea Arcangeli [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-04-04 21:05 2.6.5-aa1 Marcus Hartig
2004-04-04 22:59 ` 2.6.5-aa1 Jeff Sipek
2004-04-05  0:20   ` 2.6.5-aa1 Andrea Arcangeli
2004-04-05  2:18     ` 2.6.5-aa1 Jeff Sipek
2004-04-05  5:39     ` 2.6.5-aa1 Marcus Hartig
2004-04-05  7:03       ` 2.6.5-aa1 Jeff Sipek
     [not found]       ` <1081185096.8036.3.camel@nosferatu.lan>
2004-04-05 17:28         ` 2.6.5-aa1 Marcus Hartig
2004-04-05 18:31     ` 2.6.5-aa1 Marcus Hartig
2004-04-05 19:02       ` 2.6.5-aa1 Andrea Arcangeli

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=20040404052256.GA2164@dualathlon.random \
    --to=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox