From: Tejun Heo <tj@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Shakeel Butt <shakeelb@google.com>,
Michal Hocko <mhocko@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, Kernel Team <kernel-team@fb.com>,
LKML <linux-kernel@vger.kernel.org>,
Josef Bacik <josef@toxicpanda.com>,
Eric Dumazet <eric.dumazet@gmail.com>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Linux MM <linux-mm@kvack.org>, Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH v2] net: fix sk_page_frag() recursion from memory reclaim
Date: Fri, 1 Nov 2019 10:12:02 -0700 [thread overview]
Message-ID: <20191101171202.GP3622521@devbig004.ftw2.facebook.com> (raw)
In-Reply-To: <20191031162049.27e54d9412214aea79acd2ea@linux-foundation.org>
Hello,
On Thu, Oct 31, 2019 at 04:20:49PM -0700, Andrew Morton wrote:
> > > In [0], tcp_send_msg_locked() was using current->page_frag when it
>
> "tcp_sendmsg_locked" and "current->task_frag". Stuff like this makes
> review harder :(
lol, sorry about that.
> > > Fix it by adding gfpflags_normal_context() which tests sleepable &&
> > > !reclaim and use it to determine whether to use current->task_frag.
> > >
>
> Dumb-but-obvious question. Rather than putzing with allocation modes,
> is it not feasible to change the net layer to copy the current value of
> current->task_frag into a local then restore its value when it has
> finished being used?
It's being used as an allocation cache, so doing so would lead to the
same area getting allocated for two packets at the same time instead
overrunning the end of the cache.
Thanks.
--
tejun
prev parent reply other threads:[~2019-11-01 17:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-19 17:01 [PATCH] net: fix sk_page_frag() recursion from memory reclaim Tejun Heo
2019-10-19 18:15 ` Eric Dumazet
2019-10-19 21:18 ` Tejun Heo
2019-10-19 21:25 ` Eric Dumazet
2019-10-22 17:19 ` Jakub Kicinski
2019-10-24 20:50 ` [PATCH v2] " Tejun Heo
2019-10-28 23:18 ` David Miller
2019-10-31 17:35 ` Shakeel Butt
2019-10-31 17:47 ` Eric Dumazet
2019-10-31 18:30 ` Shakeel Butt
2019-10-31 18:43 ` Tejun Heo
2019-10-31 18:51 ` Shakeel Butt
2019-10-31 19:00 ` Tejun Heo
2019-10-31 19:14 ` Shakeel Butt
2019-10-31 19:16 ` Tejun Heo
2019-10-31 23:20 ` Andrew Morton
2019-11-01 17:12 ` Tejun Heo [this message]
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=20191101171202.GP3622521@devbig004.ftw2.facebook.com \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=jakub.kicinski@netronome.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shakeelb@google.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).