Re: [34-longterm 000/179] v2.6.34.12 longterm review

Re: [34-longterm 000/179] v2.6.34.12 longterm review

[Paul Gortmaker]

On Mon, May 14, 2012 at 10:11 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> This is the start of the longterm review cycle for the v2.6.34.12 release.
> There are 179 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.
>
> The full queue can be found at:
> �http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
>
> Please try to get reponses made within 72 hours, or it may be too late.\

Doh,  Somehow the old (pre-break-in) address again leaked back into
my stable scripts.  Sorry about that.  This was meant to go to the
stable@vger.kernel.org and not the stale stable@kernel.org address.

Paul.

Re: [34-longterm 167/179] futex: Fix regression with read only mappings

[Paul Gortmaker]

[Re: [34-longterm 167/179] futex: Fix regression with read only mappings] On 15/05/2012 (Tue 12:51) Peter Zijlstra wrote:

> On Mon, 2012-05-14 at 21:38 -0700, Hugh Dickins wrote:
> > I don't know: I'm not NAKking it, I'm just waving a reddish flag,
> > and hoping that Peter will remember more, and have something more
> > constructive to say, than I can think of at this moment. 
> 
> Ha! you're very optimistic :-)
> 
> going by git log kernel/futex.c on a recent kernel the proposed patch
> should indeed be followed by your patch, but I can't seem to find more
> relevant patches.

Thanks a lot guys.  That is a dependency I'd never have come up with.

Willy -- this is probably of interest to you as well.   Hugh says that
commit e6780f7243 ("futex: Fix uninterruptible loop due to gate_area")
should be used if 9ea71503a8 ("futex: Fix regression with read only
mappings") is used.  The v2.6.32.46 added 9ea71503a8 (as d64ec7bb),
but I don't see a cherry pick of e6780f7243 in any v2.6.32.x yet.

Greg already applied it to 3.0.16 and 3.1.8 and it appeared in v3.2
by default, so no other active stable releases need to worry.

I had to change page_mapping --> page, since the 2.6.34 baseline does
not have a5b338f2b0b1ff73 ("thp: update futex compound knowledge")
[added to v2.6.38] which introduces the shadow variable page_mapping.

Paul.
---

>From f8fe91498b2a35fc6abc02bb213ca297bfcd2b2a Mon Sep 17 00:00:00 2001
From: Hugh Dickins <hughd@google.com>
Date: Sat, 31 Dec 2011 11:44:01 -0800
Subject: [PATCH] futex: Fix uninterruptible loop due to gate_area

commit e6780f7243eddb133cc20ec37fa69317c218b709 upstream.

It was found (by Sasha) that if you use a futex located in the gate
area we get stuck in an uninterruptible infinite loop, much like the
ZERO_PAGE issue.

While looking at this problem, PeterZ realized you'll get into similar
trouble when hitting any install_special_pages() mapping.  And are there
still drivers setting up their own special mmaps without page->mapping,
and without special VM or pte flags to make get_user_pages fail?

In most cases, if page->mapping is NULL, we do not need to retry at all:
Linus points out that even /proc/sys/vm/drop_caches poses no problem,
because it ends up using remove_mapping(), which takes care not to
interfere when the page reference count is raised.

But there is still one case which does need a retry: if memory pressure
called shmem_writepage in between get_user_pages_fast dropping page
table lock and our acquiring page lock, then the page gets switched from
filecache to swapcache (and ->mapping set to NULL) whatever the refcount.
Fault it back in to get the page->mapping needed for key->shared.inode.

Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PG: 2.6.34 variable is page, not page_head, since it doesn't have a5b338f2]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

diff --git a/kernel/futex.c b/kernel/futex.c
index 98a354d..8b467b4 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -264,17 +264,29 @@ again:
 
 	page = compound_head(page);
 	lock_page(page);
+
+	/*
+	 * If page->mapping is NULL, then it cannot be a PageAnon
+	 * page; but it might be the ZERO_PAGE or in the gate area or
+	 * in a special mapping (all cases which we are happy to fail);
+	 * or it may have been a good file page when get_user_pages_fast
+	 * found it, but truncated or holepunched or subjected to
+	 * invalidate_complete_page2 before we got the page lock (also
+	 * cases which we are happy to fail).  And we hold a reference,
+	 * so refcount care in invalidate_complete_page's remove_mapping
+	 * prevents drop_caches from setting mapping to NULL beneath us.
+	 *
+	 * The case we do have to guard against is when memory pressure made
+	 * shmem_writepage move it from filecache to swapcache beneath us:
+	 * an unlikely race, but we do need to retry for page->mapping.
+	 */
 	if (!page->mapping) {
+		int shmem_swizzled = PageSwapCache(page);
 		unlock_page(page);
 		put_page(page);
-		/*
-		* ZERO_PAGE pages don't have a mapping. Avoid a busy loop
-		* trying to find one. RW mapping would have COW'd (and thus
-		* have a mapping) so this page is RO and won't ever change.
-		*/
-		if ((page == ZERO_PAGE(address)))
-			return -EFAULT;
-		goto again;
+		if (shmem_swizzled)
+			goto again;
+		return -EFAULT;
 	}
 
 	/*
-- 
1.7.9.6

Re: [34-longterm 167/179] futex: Fix regression with read only mappings

[Willy Tarreau]

On Tue, May 15, 2012 at 12:02:50PM -0400, Paul Gortmaker wrote:
> [Re: [34-longterm 167/179] futex: Fix regression with read only mappings] On 15/05/2012 (Tue 12:51) Peter Zijlstra wrote:
> 
> > On Mon, 2012-05-14 at 21:38 -0700, Hugh Dickins wrote:
> > > I don't know: I'm not NAKking it, I'm just waving a reddish flag,
> > > and hoping that Peter will remember more, and have something more
> > > constructive to say, than I can think of at this moment. 
> > 
> > Ha! you're very optimistic :-)
> > 
> > going by git log kernel/futex.c on a recent kernel the proposed patch
> > should indeed be followed by your patch, but I can't seem to find more
> > relevant patches.
> 
> Thanks a lot guys.  That is a dependency I'd never have come up with.
> 
> Willy -- this is probably of interest to you as well.   Hugh says that
> commit e6780f7243 ("futex: Fix uninterruptible loop due to gate_area")
> should be used if 9ea71503a8 ("futex: Fix regression with read only
> mappings") is used.  The v2.6.32.46 added 9ea71503a8 (as d64ec7bb),
> but I don't see a cherry pick of e6780f7243 in any v2.6.32.x yet.
> 
> Greg already applied it to 3.0.16 and 3.1.8 and it appeared in v3.2
> by default, so no other active stable releases need to worry.
> 
> I had to change page_mapping --> page, since the 2.6.34 baseline does
> not have a5b338f2b0b1ff73 ("thp: update futex compound knowledge")
> [added to v2.6.38] which introduces the shadow variable page_mapping.

Thank you very much Paul, I'm queuing it then. I hope to have some time for
a new -32 review soon, probably next week-end.

Cheers,
Willy

Re: [34-longterm 179/179] x86/PCI: do not tie MSI MS-7253 use_crs quirk to BIOS version

[Paul Gortmaker]

[Re: [34-longterm 179/179] x86/PCI: do not tie MSI MS-7253 use_crs quirk to BIOS version] On 15/05/2012 (Tue 15:47) Alan Cox wrote:

> On Tue, 15 May 2012 15:44:55 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > O> MS-7253, for which we already have a quirk, but the short-sighted
> > > author tied the quirk to a single BIOS version, making it not kick in
> > 
> > It's our usual policy to tie to particular BIOS versions because these
> > things are often BIOS specific and come and go with updates.
> 
> Doh ignore that, the point is valid but not in a -longterm context

The prefix "34-longterm" isn't as clear as it was before we went to 3.0
so I'll change it to "2.6.34-stable" for next time.  We've stopped
separating longterm from stable on the server anyways.

Thanks,
Paul.

Re: [34-longterm 074/179] xen: Use IRQF_FORCE_RESUME

[Paul Gortmaker]

[Re: [34-longterm 074/179] xen: Use IRQF_FORCE_RESUME] On 15/05/2012 (Tue 00:02) Jonathan Nieder wrote:

> Hi Paul,
> 
> Paul Gortmaker wrote:
> 
> > From: Thomas Gleixner <tglx@linutronix.de>
> [...]
> >     If you see a problem with using this for longterm, please comment.
> [...]
> > commit 676dc3cf5bc36a9e129a3ad8fe3bd7b2ebf20f5d upstream.
> >
> > Mark the IRQF_NO_SUSPEND interrupts IRQF_FORCE_RESUME and remove the extra
> > walk through the interrupt descriptors.
> 
> This produces resume failures and migration failures in Xen guests[1].
> 
> Commit 9bab0b7fbace (genirq: Add IRQF_RESUME_EARLY and resume such
> IRQs earlier, 2011-11-09) is needed on top to avoid regressions.
> 
> Hope that helps,
> Jonathan
> 
> [1] http://thread.gmane.org/gmane.linux.kernel/1198673

Hi Jonathan,

I'd considered this patch, but then saw Greg used it on 2.6.32
and reverted it one release later:

-------------------
commit 758d61b4a76e6ad4224780771edbc6d3a0c29b16
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Tue Nov 8 15:40:42 2011 -0800

    Revert "genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier"
    
    This reverts commit 0f12a6ad9fa3a03f2bcee36c9cb704821e244c40.
    
    It causes too many build errors and needs to be done properly.
    
    Reported-by: Jiri Slaby <jslaby@suse.cz>
    Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
    Cc: Ian Campbell <ian.campbell@citrix.com>
 [...]
-------------

What I didn't realize was that it got re-added as a v2 again in:

-------------
commit 5e87d8ee34e32fda720f3a4e4055f570b09230d6
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Nov 9 08:53:09 2011 +0000

    genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier
    
[...]

    Back ported to 2.6.32 (which lacks syscore support) by calling the relavant
    resume function directly from sysdev_resume).
    
    v2: Fixed non-x86 build errors.
-----------

I'll make sure the v2 ends up in the 34 queue.

Thanks again,
Paul.