From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: [RFC] netlink broadcast return value
Date: Mon, 09 Feb 2009 23:51:54 +0100 [thread overview]
Message-ID: <4990B38A.3020207@netfilter.org> (raw)
In-Reply-To: <49903B03.2040302@trash.net>
Patrick McHardy wrote:
> David Miller wrote:
>> From: Pablo Neira Ayuso <pablo@netfilter.org>
>> Date: Sun, 01 Feb 2009 14:33:57 +0100
>>
>>> In short, I think that the change that I'm proposing would also require
>>> to fix some netlink_broadcast() clients to skip ENOBUFS errors: they are
>>> not meaningful for them since they assume that Netlink is unreliable and
>>> so the return value does not provide any useful information.
>>
>> I think this analysis is accurate.
>
> We have at least one case where the caller wants to know of
> any successful delivery. Keymanager queries done by xfrm_state
> want to know whether an acquire was delivered to any keymanager.
> So we need to continue to indicate this, maybe using a different
> errno code than -ENOBUFS. I don't have a suggestion which one to
> use though.
Indeed, I have missed that spot. I'm not very familiar with that code,
however, I see that the creation of a state depends on the netlink
broadcast return value, but how useful is that? I think that the state
should be created even if the broadcast fails, the userspace daemon
should request a resync to the kernel as soon as it hits ENOBUFS, then
it would be in sync again with that state.
--
"Los honestos son inadaptados sociales" -- Les Luthiers
next prev parent reply other threads:[~2009-02-09 22:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-01 13:33 [RFC] netlink broadcast return value Pablo Neira Ayuso
2009-02-02 22:05 ` David Miller
2009-02-09 14:17 ` Patrick McHardy
2009-02-09 22:51 ` Pablo Neira Ayuso [this message]
2009-02-09 23:23 ` Patrick McHardy
2009-02-09 23:58 ` Pablo Neira Ayuso
2009-02-10 13:50 ` Patrick McHardy
2009-02-10 18:51 ` Pablo Neira Ayuso
2009-02-11 12:44 ` Patrick McHardy
2009-02-11 16:39 ` Pablo Neira Ayuso
2009-02-11 16:54 ` Patrick McHardy
2009-02-11 21:01 ` Pablo Neira Ayuso
2009-02-12 5:07 ` Patrick McHardy
2009-02-12 12:36 ` Pablo Neira Ayuso
2009-02-12 12:41 ` Pablo Neira Ayuso
2009-02-12 12:48 ` Patrick McHardy
2009-02-12 13:20 ` Pablo Neira Ayuso
2009-02-12 13:25 ` Patrick McHardy
2009-02-12 12:45 ` Patrick McHardy
2009-02-02 22:35 ` Inaky Perez-Gonzalez
2009-02-03 10:07 ` Pablo Neira Ayuso
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=4990B38A.3020207@netfilter.org \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@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.