netdev - Re: [PATCH net-next v4 07/10] bridge: cfm: Netlink SET configuration Interface.

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]

Message-ID: <20201012130547.7tj3sdkmzcqjcssf@soft-test08>
Date:   Mon, 12 Oct 2020 13:05:47 +0000
From:   Henrik Bjoernlund <henrik.bjoernlund@...rochip.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     <davem@...emloft.net>, <roopa@...dia.com>, <nikolay@...dia.com>,
        <jiri@...lanox.com>, <idosch@...lanox.com>,
        <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
        <bridge@...ts.linux-foundation.org>,
        <UNGLinuxDriver@...rochip.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>
Subject: Re: [PATCH net-next v4 07/10] bridge: cfm: Netlink SET configuration
 Interface.

Thanks for the review. Comments below.

The 10/09/2020 18:45, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, 9 Oct 2020 14:35:27 +0000 Henrik Bjoernlund wrote:
> > +static inline struct mac_addr nla_get_mac(const struct nlattr *nla)
> 
> static inlines are generally not needed in C sources and just hide
> unused code. Please drop the inline annotation.
> 
I removed this function
> > +{
> > +     struct mac_addr mac;
> > +
> > +     nla_memcpy(&mac.addr, nla, sizeof(mac.addr));
> > +
> > +     return mac;
> > +}
> > +
> > +static inline struct br_cfm_maid nla_get_maid(const struct nlattr *nla)
> 
> ditto

I removed this function.

> 
> > +{
> > +     struct br_cfm_maid maid;
> > +
> > +     nla_memcpy(&maid.data, nla, sizeof(maid.data));
> 
> returning a 48B struct from a helper is a little strange, but I guess
> it's not too bad when compiler inlines the thing?
> 
I removed this function. 

> > +     return maid;
> > +}
> > +
> > +static const struct nla_policy
> > +br_cfm_policy[IFLA_BRIDGE_CFM_MAX + 1] = {
> > +     [IFLA_BRIDGE_CFM_UNSPEC]                = { .type = NLA_REJECT },
> 
> Not needed, REJECT is treated the same as 0 / uninit, right?
> 
Did not change anything here. I would like to keep this if it does no harm.

> > +     [IFLA_BRIDGE_CFM_MEP_CREATE]            = { .type = NLA_NESTED },
> 
> Consider using NLA_POLICY_NESTED() to link up the next layers.
> 
I change to use the NLA_POLICY_NESTED macro.

> > +     [IFLA_BRIDGE_CFM_MEP_DELETE]            = { .type = NLA_NESTED },
> > +     [IFLA_BRIDGE_CFM_MEP_CONFIG]            = { .type = NLA_NESTED },
> > +     [IFLA_BRIDGE_CFM_CC_CONFIG]             = { .type = NLA_NESTED },
> > +     [IFLA_BRIDGE_CFM_CC_PEER_MEP_ADD]       = { .type = NLA_NESTED },
> > +     [IFLA_BRIDGE_CFM_CC_PEER_MEP_REMOVE]    = { .type = NLA_NESTED },
> > +     [IFLA_BRIDGE_CFM_CC_RDI]                = { .type = NLA_NESTED },
> > +     [IFLA_BRIDGE_CFM_CC_CCM_TX]             = { .type = NLA_NESTED },
> > +};

-- 
/Henrik