From: Mel Gorman <mgorman@techsingularity.net>
To: Xie He <xie.he.0141@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>,
jslaby@suse.cz, Neil Brown <neilb@suse.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Mike Christie <michaelc@cs.wisc.edu>,
Eric B Munson <emunson@mgebm.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
Sebastian Andrzej Siewior <sebastian@breakpoint.cc>,
Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Problem in pfmemalloc skb handling in net/core/dev.c
Date: Fri, 9 Apr 2021 10:58:08 +0100 [thread overview]
Message-ID: <20210409095808.GL3697@techsingularity.net> (raw)
In-Reply-To: <CAJht_EPrdujG_0QHM1vc2yrgwwKMQiFzUAK2pgR4dS4z9-Xknw@mail.gmail.com>
On Fri, Apr 09, 2021 at 02:14:12AM -0700, Xie He wrote:
> On Fri, Apr 9, 2021 at 1:44 AM Mel Gorman <mgorman@techsingularity.net> wrote:
> >
> > That would imply that the tap was communicating with a swap device to
> > allocate a pfmemalloc skb which shouldn't happen. Furthermore, it would
> > require the swap device to be deactivated while pfmemalloc skbs still
> > existed. Have you encountered this problem?
>
> I'm not a user of swap devices or pfmemalloc skbs. I just want to make
> sure the protocols that I'm developing (not IP or IPv6) won't get
> pfmemalloc skbs when receiving, because those protocols cannot handle
> them.
>
> According to the code, it seems always possible to get a pfmemalloc
> skb when a network driver calls "__netdev_alloc_skb". The skb will
> then be queued in per-CPU backlog queues when the driver calls
> "netif_rx". There seems to be nothing preventing "sk_memalloc_socks()"
> from becoming "false" after the skb is allocated and before it is
> handled by "__netif_receive_skb".
>
> Do you mean that at the time "sk_memalloc_socks()" changes from "true"
> to "false", there would be no in-flight skbs currently being received,
> and all network communications have been paused?
Not all network communication, but communication with swap devices
should have stopped once sk_memalloc_socks is false.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2021-04-09 9:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 18:52 Problem in pfmemalloc skb handling in net/core/dev.c Xie He
2021-04-09 7:30 ` Mel Gorman
2021-04-09 8:33 ` Xie He
2021-04-09 8:44 ` Mel Gorman
2021-04-09 9:14 ` Xie He
2021-04-09 9:58 ` Mel Gorman [this message]
2021-04-09 10:08 ` Xie He
2021-04-09 10:04 ` Eric Dumazet
2021-04-09 10:14 ` Xie He
2021-04-09 11:50 ` Eric Dumazet
2021-04-09 19:12 ` Xie He
2021-04-12 20:40 ` Xie He
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=20210409095808.GL3697@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=emunson@mgebm.net \
--cc=eric.dumazet@gmail.com \
--cc=jslaby@suse.cz \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=michaelc@cs.wisc.edu \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=sebastian@breakpoint.cc \
--cc=xie.he.0141@gmail.com \
/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).