[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1448490937.24696.55.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Wed, 25 Nov 2015 14:35:37 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Aaron Conole <aconole@...hat.com>
Cc: David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] tcp: suppress too verbose messages in
tcp_send_ack()
On Wed, 2015-11-25 at 14:32 -0800, Eric Dumazet wrote:
> 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...
>
BTW original commit changelog was clear and matches my expectations :
commit 99a1dec70d5acbd8c6b3928cdebb4a2d1da676c8
Author: Mel Gorman <mgorman@...e.de>
Date: Tue Jul 31 16:44:14 2012 -0700
net: introduce sk_gfp_atomic() to allow addition of GFP flags depending on the individual socket
Introduce sk_gfp_atomic(), this function allows to inject sock specific
flags to each sock related allocation. It is only used on allocation
paths that may be required for writing pages back to network storage.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists