netdev - Re: [PATCH net-next] tcp: suppress too verbose messages in tcp_send

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f7tegfadft3.fsf@aconole.bos.csb>
Date:	Fri, 27 Nov 2015 21:21:44 -0500
From:	Aaron Conole <aconole@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.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()

Eric Dumazet <eric.dumazet@...il.com> writes:
> On Wed, 2015-11-25 at 22:17 -0500, Aaron Conole wrote:
>
>> Probably that would call for a different more primitive version of this
>> API (sk_gfp_or_memalloc() as you suggest below). Then this could be
>> written in terms of that
>> 
>> static inline sk_gfp_or_memalloc(const struct sock *sk, gfp_t gfp_mask)
>> {
>> 	return gfp_mask | (sk->sk_allocation & __GFP_MEMALLOC);
>> }
>> 
>> static inline sk_gfp_atomic(const struct sock *sk, gfp_t gfp_mask)
>> {
>> 	return sk_gfp_or_memalloc(sk, gfp_mask | GFP_ATOMIC);
>> }
>> 
>> Not sure if it's "too much API".
>
> Well, this looks like it, not sure how this is going to make code
> clearer.
>
> The only thing we bring from sk is the __GFP_MEMALLOC thing, so a single
> function seems enough ?

Okay. Just thought that a 'gfp' function ending in _atomic that doesn't
actually set GFP_ATOMIC might now confuse, but if you think it's no big
deal, hey no skin off my back :)

> I honestly do not care that much about function names, I mostly look at
> actual implementation. And current implementation ignores the gfp_t
> gfp_mask argument, for no real good reason.

I agree with this.
--
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