netdev - Re: [PATCH] ip: Support filter links/neighs with no master

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] [day] [month] [year] [list]

Message-ID: <11a0051c-2d14-a479-c657-d49a2fce9a9d@gmail.com>
Date:   Tue, 24 Aug 2021 09:16:35 -0700
From:   David Ahern <dsahern@...il.com>
To:     Lahav Schlesinger <lschlesinger@...venets.com>
Cc:     netdev@...r.kernel.org, dsahern@...nel.org
Subject: Re: [PATCH] ip: Support filter links/neighs with no master

On 8/24/21 8:16 AM, Lahav Schlesinger wrote:
>>> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
>>> index 85534aaf..a5b683f5 100644
>>> --- a/ip/ipaddress.c
>>> +++ b/ip/ipaddress.c
>>> @@ -61,7 +61,7 @@ static void usage(void)
>>>               "                            [ to PREFIX ] [ FLAG-LIST ] [ label LABEL ] [up]\n"
>>>               "       ip address [ show [ dev IFNAME ] [ scope SCOPE-ID ] [ master DEVICE ]\n"
>>
>> move [ nomaster ] to here on a new line to keep the existing line
>> length, and
>>
>>>               "                         [ type TYPE ] [ to PREFIX ] [ FLAG-LIST ]\n"
>>> -             "                         [ label LABEL ] [up] [ vrf NAME ] ]\n"
>>> +             "                         [ label LABEL ] [up] [ vrf NAME ] [ nomaster ] ]\n"
>>
>> make this 'novrf' for consistency with existing syntax.
>>
>> Similarly for the other 2 commands.
> 
> I think "nomaster" is more fitting here, because this option only affects
> interfaces that have no master at all, so e.g. slaves of a bundle will
> not be returned by the "nomaster" option, even if they are in the default VRF.

I was thinking both - 'nomaster' for bridges and 'novrf' for VRFs. Just
friendlier syntax for the latter.

> 
> I'm planning next to add support for the "novrf" option which will indeed
> only affect interfaces which are in the default VRF, even if they have a
> master.

ok,