netdev - Re: [PATCH] netlink: add NETLINK_NO

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 23 Mar 2009 13:11:53 +0100
From:	Pablo Neira Ayuso <pablo@...filter.org>
To:	Patrick McHardy <kaber@...sh.net>
CC:	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH] netlink: add NETLINK_NO_ENOBUFS socket flag

Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> This patch adds the NETLINK_NO_ENOBUFS socket flag. This flag can
>> be used by unicast and broadcast listeners to avoid receiving
>> ENOBUFS errors.
>>
>> Generally speaking, ENOBUFS errors are useful to notify two things
>> to the listener:
>>
>> a) You may increase the receiver buffer size via setsockopt().
>> b) You have lost messages, you may be out of sync.
>>
>> In some cases, ignoring ENOBUFS errors can be useful. For example:
>>
>> a) nfnetlink_queue: this subsystem does not have any sort of resync
>> method and you can decide to ignore ENOBUFS once you have set a
>> given buffer size.
>>
>> b) ctnetlink: you can use this together with the socket flag
>> NETLINK_BROADCAST_SEND_ERROR to stop getting ENOBUFS errors as
>> you do not need to resync (packets whose event are not delivered
>> are drop to provide reliable logging and state-synchronization).
>>
>> Moreover, the use of NETLINK_NO_ENOBUFS also reduces a "go up, go down"
>> effect in terms of performance which is due to the netlink congestion
>> control when the listener cannot back off. The effect is the following:
>>
>> 1) throughput rate goes up and netlink messages are inserted in the
>> receiver buffer.
>> 2) Then, netlink buffer fills and overruns (set on nlk->state bit 0).
>> 3) While the listener empties the receiver buffer, netlink keeps
>> dropping messages. Thus, throughput goes dramatically down.
>> 4) Then, once the listener has emptied the buffer (nlk->state
>> bit 0 is set off), goto step 1.
> 
> I agree that not having netlink drop new messages after congestion
> might be useful. Two suggestions though:
> 
> - NETLINK_NO_CONGESTION_CONTROL seems a bit more descriptive than
>   "NO_ENOBUFS"
> 
> - The ENOBUFS error itself is actually not the problem, but the
>   congestion handling. It still makes sense to notify userspace
>   of congestion. I'd suggest to deliver the error, but avoid setting
>   the congestion bit.

I thought about this choice but I see one problem with this. The ENOBUFS
error is attached to the congestion control. If we keep reporting
ENOBUFS errors to userspace with no congestion control, the listener may
keep receiving ENOBUFS indefinitely. In other words, the congestion
control seems to me like a way to avoid spamming ENOBUFS errors to
userspace.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers
--
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