netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman-l3A5Bk7waGM@public.gmane.org>
To: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
	neilb-l3A5Bk7waGM@public.gmane.org,
	hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org,
	michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org,
	emunson-CVBTeua0HjReoWH0uzbU5w@public.gmane.org
Subject: Re: [PATCH 01/12] netvm: Prevent a stream-specific deadlock
Date: Tue, 15 May 2012 10:14:02 +0100	[thread overview]
Message-ID: <20120515091402.GG29102@suse.de> (raw)
In-Reply-To: <20120514.162634.1094732813264319951.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

On Mon, May 14, 2012 at 04:26:34PM -0400, David Miller wrote:
> From: Mel Gorman <mgorman-l3A5Bk7waGM@public.gmane.org>
> Date: Mon, 14 May 2012 11:56:04 +0100
> 
> > On Fri, May 11, 2012 at 01:10:34AM -0400, David Miller wrote:
> >> From: Mel Gorman <mgorman-l3A5Bk7waGM@public.gmane.org>
> >> Date: Thu, 10 May 2012 14:54:14 +0100
> >> 
> >> > It could happen that all !SOCK_MEMALLOC sockets have buffered so
> >> > much data that we're over the global rmem limit. This will prevent
> >> > SOCK_MEMALLOC buffers from receiving data, which will prevent userspace
> >> > from running, which is needed to reduce the buffered data.
> >> > 
> >> > Fix this by exempting the SOCK_MEMALLOC sockets from the rmem limit.
> >> > 
> >> > Signed-off-by: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
> >> > Signed-off-by: Mel Gorman <mgorman-l3A5Bk7waGM@public.gmane.org>
> >> 
> >> This introduces an invariant which I am not so sure is enforced.
> >> 
> >> With this change it is absolutely required that once a socket
> >> becomes SOCK_MEMALLOC it must never _ever_ lose that attribute.
> >> 
> > 
> > This is effectively true. In the NFS case, the flag is cleared on
> > swapoff after all the entries have been paged in. In the NBD case,
> > SOCK_MEMALLOC is left set until the socket is destroyed. I'll update the
> > changelog.
> 
> Bugs happen, you need to find a way to assert that nobody every does
> this.  Because if a bug is introduced which makes this happen, it will
> otherwise be very difficult to debug.

Ok, fair point. I looked at how we could ensure it could never happen but
that would require failing sk_clear_memalloc() and it's less clear how
that should be properly recovered from. Instead, it can be detected that
there are rmem tokens allocations, warn about it and fix it up albeit it
in a fairly heavy-handed fashion. How about this on top of the existing
patch?

---8<---
diff --git a/net/core/sock.c b/net/core/sock.c
index 22ff2ea..e3dea27 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -289,6 +289,18 @@ void sk_clear_memalloc(struct sock *sk)
 	sock_reset_flag(sk, SOCK_MEMALLOC);
 	sk->sk_allocation &= ~__GFP_MEMALLOC;
 	static_key_slow_dec(&memalloc_socks);
+
+	/*
+	 * SOCK_MEMALLOC is allowed to ignore rmem limits to ensure forward
+	 * progress of swapping. However, if SOCK_MEMALLOC is cleared while
+	 * it has rmem allocations there is a risk that the user of the
+	 * socket cannot make forward progress due to exceeding the rmem
+	 * limits. By rights, sk_clear_memalloc() should only be called
+	 * on sockets being torn down but warn and reset the accounting if
+	 * that assumption breaks.
+	 */
+	if (WARN_ON(sk->sk_forward_alloc))
+		sk_mem_reclaim(sk);
 }
 EXPORT_SYMBOL_GPL(sk_clear_memalloc);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2012-05-15  9:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-10 13:54 [PATCH 00/12] Swap-over-NFS without deadlocking V4 Mel Gorman
2012-05-10 13:54 ` [PATCH 01/12] netvm: Prevent a stream-specific deadlock Mel Gorman
2012-05-11  5:10   ` David Miller
2012-05-14 10:56     ` Mel Gorman
2012-05-14 20:26       ` David Miller
     [not found]         ` <20120514.162634.1094732813264319951.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2012-05-15  9:14           ` Mel Gorman [this message]
2012-05-15  9:47             ` Peter Zijlstra
2012-05-15 10:08               ` Mel Gorman
2012-05-10 13:54 ` [PATCH 02/12] selinux: tag avc cache alloc as non-critical Mel Gorman
2012-05-10 14:14   ` Casey Schaufler
2012-05-10 14:25   ` Eric Paris
2012-05-10 13:54 ` [PATCH 03/12] mm: Methods for teaching filesystems about PG_swapcache pages Mel Gorman
2012-05-10 13:54 ` [PATCH 04/12] mm: Add support for a filesystem to activate swap files and use direct_IO for writing swap pages Mel Gorman
2012-05-10 13:54 ` [PATCH 05/12] mm: swap: Implement generic handler for swap_activate Mel Gorman
2012-05-10 13:54 ` [PATCH 06/12] mm: Add get_kernel_page[s] for pinning of kernel addresses for I/O Mel Gorman
2012-05-10 13:54 ` [PATCH 07/12] mm: Add support for direct_IO to highmem pages Mel Gorman
2012-05-10 13:54 ` [PATCH 08/12] nfs: teach the NFS client how to treat PG_swapcache pages Mel Gorman
2012-05-10 13:54 ` [PATCH 09/12] nfs: disable data cache revalidation for swapfiles Mel Gorman
2012-05-10 13:54 ` [PATCH 10/12] nfs: enable swap on NFS Mel Gorman
2012-05-10 13:54 ` [PATCH 11/12] nfs: Prevent page allocator recursions with swap over NFS Mel Gorman
2012-05-10 13:54 ` [PATCH 12/12] Avoid dereferencing bd_disk during swap_entry_free for network storage Mel Gorman
  -- strict thread matches above, loose matches on Subject: below --
2012-05-17 14:51 [PATCH 00/12] Swap-over-NFS without deadlocking V5 Mel Gorman
2012-05-17 14:51 ` [PATCH 01/12] netvm: Prevent a stream-specific deadlock Mel Gorman
2012-05-17 20:14   ` David Miller
2012-06-20  9:37 [PATCH 00/12] Swap-over-NFS without deadlocking V6 Mel Gorman
2012-06-20  9:37 ` [PATCH 01/12] netvm: Prevent a stream-specific deadlock Mel Gorman
2012-06-20 14:21   ` Mel Gorman
2012-06-20 15:22   ` Rik van Riel
2012-06-22 14:30 [PATCH 00/12] Swap-over-NFS without deadlocking V7 Mel Gorman
2012-06-22 14:30 ` [PATCH 01/12] netvm: Prevent a stream-specific deadlock Mel Gorman
2012-06-29 13:33 [PATCH 00/12] Swap-over-NFS without deadlocking V8 Mel Gorman
2012-06-29 13:33 ` [PATCH 01/12] netvm: Prevent a stream-specific deadlock Mel Gorman
2012-07-12  6:40 [PATCH 00/12] Swap-over-NFS without deadlocking V9 Mel Gorman
2012-07-12  6:40 ` [PATCH 01/12] netvm: Prevent a stream-specific deadlock Mel Gorman

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=20120515091402.GG29102@suse.de \
    --to=mgorman-l3a5bk7wagm@public.gmane.org \
    --cc=Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org \
    --cc=a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=emunson-CVBTeua0HjReoWH0uzbU5w@public.gmane.org \
    --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org \
    --cc=neilb-l3A5Bk7waGM@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.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;
as well as URLs for NNTP newsgroup(s).