From: Josef Bacik <jbacik@fb.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: <netdev@vger.kernel.org>, <kernel-team@fb.com>,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next] loopback: clear pfmemalloc on outgoing skb's
Date: Thu, 2 Feb 2017 15:49:11 -0500 [thread overview]
Message-ID: <1486068551.29885.32.camel@fb.com> (raw)
In-Reply-To: <1486055189.13103.53.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, 2017-02-02 at 09:06 -0800, Eric Dumazet wrote:
> On Thu, 2017-02-02 at 10:56 -0500, Josef Bacik wrote:
>
> >
> > The problem is we set skb->pfmemalloc a bunch of different places,
> > such
> > as __skb_fill_page_desc, which appears to be used in both the RX
> > and TX
> > path, so we can't just kill it there. Do we want to go through and
> > audit each one, provide a way for callers to indicate if we care
> > about
> > pfmemalloc and solve this problem that way? I feel like that's
> > more
> > likely to bite us in the ass down the line, and somebody who
> > doesn't
> > know the context is going to come along and change it and regress
> > us to
> > the current situation. The only place this is a problem is with
> > loopback, and my change is contained to this one weird
> > case. Thanks,
> I mentioned this in another mail :
>
> Same issue will happen with veth, or any kind of driver allowing skb
> being given back to the stack in RX.
>
> So your patch on loopback is not the definitive patch.
>
> We probably should clear pf->memalloc directly in TCP write function.
>
> Note that I clear it on the clone, not in original skb.
>
> (It might be very useful to keep skb->pfmemalloc on original skbs in
> write queue, at least for debugging purposes)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index
> 8ce50dc3ab8cac821b8a2c3e0d31f0aa42f5c9d5..010280f1592d3bd195315882c36
> 4bdbbd4a1c2ec 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -944,6 +944,7 @@ static int tcp_transmit_skb(struct sock *sk,
> struct sk_buff *skb, int clone_it,
> skb = skb_clone(skb, gfp_mask);
> if (unlikely(!skb))
> return -ENOBUFS;
> + skb->pfmemalloc = 0;
> }
>
> inet = inet_sk(sk);
>
>
Yup this fixes my problem, you can add
Acked-by: Josef Bacik <jbacik@fb.com>
when you send it. Thanks,
Josef
next prev parent reply other threads:[~2017-02-02 20:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-01 21:04 [PATCH net-next] loopback: clear pfmemalloc on outgoing skb's Josef Bacik
2017-02-01 23:38 ` Eric Dumazet
2017-02-01 23:57 ` Eric Dumazet
2017-02-02 2:13 ` [PATCH net-next] net: remove useless pfmemalloc setting Eric Dumazet
2017-02-03 4:03 ` David Miller
2017-02-02 2:46 ` [PATCH net-next] loopback: clear pfmemalloc on outgoing skb's Eric Dumazet
2017-02-02 15:56 ` Josef Bacik
2017-02-02 17:06 ` Eric Dumazet
2017-02-02 20:49 ` Josef Bacik [this message]
2017-02-03 4:40 ` [PATCH net-next] tcp: clear pfmemalloc on outgoing skb Eric Dumazet
2017-02-03 21:24 ` David Miller
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=1486068551.29885.32.camel@fb.com \
--to=jbacik@fb.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=kernel-team@fb.com \
--cc=netdev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.