From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: David Miller <davem@davemloft.net>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [RFC 0/3] netlink: extended error reporting
Date: Fri, 7 Apr 2017 21:21:34 +0200 [thread overview]
Message-ID: <20170407192134.GA23205@salvia> (raw)
In-Reply-To: <1491592185.5800.7.camel@sipsolutions.net>
On Fri, Apr 07, 2017 at 09:09:45PM +0200, Johannes Berg wrote:
> On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote:
> > On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote:
> > [...]
> > > Heh. I think I really want to solve - at least partially -
> > > nla_parse()
> > > to see that it can be done this way. It'd be nice to even transform
> > > all
> > > the callers (I generated half of these patches with spatch anyway)
> > > to
> > > have at least that.
> >
> > We can just have a modified version of nla_parse that deals with
> > this.
>
> Yes, but we need to figure out a good way to have the offset.
>
> We also need to see if we want to *force* having the offset. In some
> sense that'd be useful, in another it might be very complicated to fill
> it in at all times, if for example errors come from lower layers like
> drivers.
For my usecases in netfilter, the attributes and an specific error
code should be enough to figure out what is wrong. Will not need
strings.
BTW, we may not have an offset, eg. EINVAL because of missing
attribute. Given we have different requirements, I would leave it to
each subsystem to decide what netlink error attributes are specified.
> (It's ultimately always going to be optional since we'll continue
> returning errors without *any* extended error information - likely
> indefinitely - but if we have a wrong attribute, should we always have
> an offset? Would be nice, but could be difficult in practice)
>
> > We can probably use struct nla_policy to place the extended error
> > code or the string (as we discussed I don't need string errors, but
> > I'm fine if other people find it useful).
>
> I don't think for the error strings really would be useful for
> nla_parse() or a policy - we can return something generic like
> "malformed attribute" there as a string, and hopefully point to the
> attribute/offset from there generically. I just really want to see how
> to actually do that.
I think the most flexible way is to pass the container error structure
to nla_parse() so it sets this for you. This would also save tons of
"malformed attribute" strings.
next prev parent reply other threads:[~2017-04-07 19:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 18:26 [RFC 0/3] netlink: extended error reporting Johannes Berg
2017-04-07 18:26 ` [RFC 1/3] " Johannes Berg
2017-04-07 19:41 ` Johannes Berg
2017-04-07 18:26 ` [RFC 2/3] genetlink: pass extended error report down Johannes Berg
2017-04-07 18:37 ` Ben Greear
[not found] ` <25e1fb8c-22e0-d7a2-13a7-d0def5432c9e-my8/4N5VtI7c+919tysfdA@public.gmane.org>
2017-04-07 19:12 ` Johannes Berg
2017-04-07 19:27 ` Ben Greear
[not found] ` <20170407182620.6438-1-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-07 18:26 ` [RFC 3/3] nl80211: add a few extended error strings Johannes Berg
2017-04-07 18:53 ` [RFC 0/3] netlink: extended error reporting David Miller
[not found] ` <20170407.115315.23470877439489670.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-04-07 18:59 ` Johannes Berg
[not found] ` <1491591552.5800.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-07 19:06 ` Pablo Neira Ayuso
2017-04-07 19:09 ` Johannes Berg
2017-04-07 19:21 ` Pablo Neira Ayuso [this message]
2017-04-07 19:29 ` Johannes Berg
[not found] ` <1491593357.5800.13.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-07 19:45 ` Pablo Neira Ayuso
2017-04-07 19:47 ` Johannes Berg
2017-04-07 19:34 ` David Miller
2017-04-07 19:22 ` David Miller
[not found] ` <20170407.122223.385211483743191711.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-04-07 19:27 ` Pablo Neira Ayuso
2017-04-07 19:29 ` Johannes Berg
2017-04-07 19:34 ` David Miller
2017-04-07 19:20 ` David Miller
2017-04-07 19:26 ` Johannes Berg
2017-04-07 19:35 ` Pablo Neira Ayuso
2017-04-07 19:43 ` David Miller
[not found] ` <20170407.124327.626442219286333933.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-04-07 19:46 ` Johannes Berg
[not found] ` <1491594406.5800.18.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-07 19:55 ` David Miller
[not found] ` <20170407.125511.1233528940652477012.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-04-07 20:27 ` Johannes Berg
2017-04-07 19:02 ` Pablo Neira Ayuso
2017-04-07 19:06 ` Johannes Berg
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=20170407192134.GA23205@salvia \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).