netdev - Re: [RFC] netlink broadcast return value

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]

Date:	Thu, 12 Feb 2009 14:20:15 +0100
From:	Pablo Neira Ayuso <pablo@...filter.org>
To:	Patrick McHardy <kaber@...sh.net>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org
Subject: Re: [RFC] netlink broadcast return value

Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Oh, and also for this:
>>
>>>     if (p->skb2 == NULL) {
>>>         netlink_overrun(sk);
>>>         /* Clone failed. Notify ALL listeners. */
>>>         p->failure = 1;
>>                 ^^^^^^^^^^^^^^^
>>
>> if (nlk->flags & NETLINK_HIGHLY_RELIABLE)
>>     p->failure = 1;
> 
> I always wondered about the intention behind this. It wouldn't
> hurt to just try the other allocation and see if they also fail.

Indeed. I don't see either the point of stopping other sockets from
receiving the message because one clone failed, but that's a different
issue I think.

BTW, the netlink_set_err() function (I found one call in rtnetlink.c)
also attracted my attention since it sets the EAGAIN error to all
listeners when nlmsg_multicast() fails, which happens if the echoing is
set and unicast fails. This made me think, what would it be the action
taken by the multicast userspace listener if it hits EAGAIN? Probably,
let them know that this request may retry? I think there's nothing they
can do anyway.

-- 
"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