All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Aaron Conole <aconole@redhat.com>
Cc: David Miller <davem@davemloft.net>, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] tcp: suppress too verbose messages in tcp_send_ack()
Date: Wed, 25 Nov 2015 14:32:38 -0800	[thread overview]
Message-ID: <1448490758.24696.53.camel@edumazet-glaptop2.roam.corp.google.com> (raw)
In-Reply-To: <f7t7fl5g2ao.fsf@aconole.bos.csb>

On Wed, 2015-11-25 at 17:08 -0500, Aaron Conole wrote:

> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 7f89e4ba18d1..ead514332ae8 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -776,7 +776,7 @@ static inline int sk_memalloc_socks(void)
> >  
> >  static inline gfp_t sk_gfp_atomic(const struct sock *sk, gfp_t gfp_mask)
> >  {
> > -	return GFP_ATOMIC | (sk->sk_allocation & __GFP_MEMALLOC);
> > +	return gfp_mask | (sk->sk_allocation & __GFP_MEMALLOC);
> >  }
> >  
> 
> Sorry if I'm missing something obvious here, but with a name like
> sk_gfp_atomic, would it make sense to keep the GFP_ATOMIC mask as well?
> Otherwise, what is the _atomic is saying?

Not sure what you suggest.

Are you suggesting I remove GFP_ATOMIC from all callers ?

I am fine with this, but looks more invasive, and who knows, maybe one
caller might want to not use GFP_ATOMIC one day (like : do not attempt
to use reserves)

This sk_gfp_atomic() helper has a misleading name, since all it wanted
was to conditionally OR a caller provided flag (mostly GFP_ATOMIC one)
with __GFP_MEMALLOC for some special sockets.

Should have been sk_gfp_or_memalloc() or something...

  reply	other threads:[~2015-11-25 22:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-25 21:50 [PATCH net-next] tcp: suppress too verbose messages in tcp_send_ack() Eric Dumazet
2015-11-25 22:08 ` Aaron Conole
2015-11-25 22:32   ` Eric Dumazet [this message]
2015-11-25 22:35     ` Eric Dumazet
2015-11-26  3:17       ` Aaron Conole
2015-11-26  3:29         ` Eric Dumazet
2015-11-28  2:21           ` Aaron Conole
2015-11-30 16:06 ` David Miller
2015-11-30 16:57   ` [PATCH v2 " Eric Dumazet
2015-12-03  4:44     ` 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=1448490758.24696.53.camel@edumazet-glaptop2.roam.corp.google.com \
    --to=eric.dumazet@gmail.com \
    --cc=aconole@redhat.com \
    --cc=davem@davemloft.net \
    --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.