netdev - Re: [PATCHv2 net-next] sched: multicast sched extack messages

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:   Mon, 26 Dec 2022 11:31:24 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Hangbin Liu <liuhangbin@...il.com>
Cc:     David Ahern <dsahern@...nel.org>, Jakub Kicinski <kuba@...nel.org>,
        netdev@...r.kernel.org, Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Vlad Buslov <vladbu@...dia.com>
Subject: Re: [PATCHv2 net-next] sched: multicast sched extack messages

My only concern is this is not generic enough i.e can other objects
outside of filters do this?
You are still doing it only for the filter (in tfilter_set_nl_ext() -
sitting in cls_api)
As i mentioned earlier, actions can also be offloaded independently;
would this work with actions extack?
If it wont work then perhaps we should go the avenue of using
per-object(in this case filter) specific attributes
to carry the extack as suggested by Jakub earlier.

David, extacks are passed to user space today via NLMSG_ERROR  and in
this case the error is being returned by
the driver - so it makes sense to stick to that attribute so user
space can interpret it as such.

Jakub, I would argue this is an event given the original intent: Some
human (or daemon) tried to add an entry to
hardware and s/w (neither skip_sw nor skip_hw set in user space
request) and it failed because the hardware does
not support the request, and therefore the entry got added as to the
kernel only.
The event in this case is to tell whoever is listening that this
happened i.e half the request worked.

The secondary argument from Marcelo and Hangbin is: there is a
practical use for this, you reducing the amount
of operational tooling needed. Alternative is to get the extack
equivalent in syslog and the other from from events and
then do the heuristics.

cheers,
jamal

On Thu, Dec 22, 2022 at 9:35 PM Hangbin Liu <liuhangbin@...il.com> wrote:
>
> On Thu, Dec 22, 2022 at 09:26:14AM -0700, David Ahern wrote:
> > On 12/22/22 12:48 AM, Hangbin Liu wrote:
> > > On Wed, Dec 21, 2022 at 05:28:17PM -0800, Jakub Kicinski wrote:
> > >> On Wed, 21 Dec 2022 17:39:40 +0800 Hangbin Liu wrote:
> > >>> + nlh = nlmsg_put(skb, portid, n->nlmsg_seq, NLMSG_ERROR, sizeof(*errmsg),
> > >>> +                 NLM_F_ACK_TLVS | NLM_F_CAPPED);
> > >>> + if (!nlh)
> > >>> +         return -1;
> > >>> +
> > >>> + errmsg = (struct nlmsgerr *)nlmsg_data(nlh);
> > >>> + errmsg->error = 0;
> > >>> + errmsg->msg = *n;
> > >>> +
> > >>> + if (nla_put_string(skb, NLMSGERR_ATTR_MSG, extack->_msg))
> > >>> +         return -1;
> > >>> +
> > >>> + nlmsg_end(skb, nlh);
> > >>
> > >> I vote "no", notifications should not generate NLMSG_ERRORs.
> > >> (BTW setting pid and seq on notifications is odd, no?)
> > >
> > > I'm not sure if this error message should be counted to notifications generation.
> > > The error message is generated as there is extack message, which is from
> > > qdisc/filter adding/deleting.
> > >
> > > Can't we multicast error message?
> > >
> > > If we can't multicast the extack message via NLMSG_ERROR or NLMSG_DONE. I
> > > think there is no other way to do it via netlink.
> > >
> >
> > it is confusing as an API to send back information or debugging strings
> > marked as an "error message."
> >
>
> I think it's OK to send back information with error message. Based on rfc3549,
>
>    An error code of zero indicates that the message is an ACK response.
>    An ACK response message contains the original Netlink message header,
>    which can be used to compare against (sent sequence numbers, etc).
>
> I tried to do it on netlink_ack[1]. But Jakub pointed that the message ids
> are not same families. So I moved it to net/sched.
>
> I think the argue point is, can we multicast the error message?
>
> [1] https://lore.kernel.org/all/Y4W9qEHzg5h9n%2Fod@Laptop-X1/
>
> Thanks
> Hangbin