netdev - Re: [PATCH net-next v4 2/8] netdevice: add IPv4 fib add/del ops

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:	Fri, 6 Mar 2015 11:59:10 -0800
From:	Scott Feldman <sfeldma@...il.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Jiří Pírko <jiri@...nulli.us>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	"alexander.h.duyck@...hat.com" <alexander.h.duyck@...hat.com>
Subject: Re: [PATCH net-next v4 2/8] netdevice: add IPv4 fib add/del ops

On Fri, Mar 6, 2015 at 6:55 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> On 03/06/15 00:21, sfeldma@...il.com wrote:
>>
>> From: Scott Feldman <sfeldma@...il.com>
>>
>> Add two new ndo ops for IPv4 fib offload support, add and del.  Add uses
>> modifiy semantics if fib entry already offloaded.
>
>
>
> The above semantic will not express correctly the intent that the tools
> like iproute2 expose and user space expects.
> I think you need to pass the netlink flags to do it correctly at
> the driver level.
> i.e classical table operations per netlink flags (NLM_F_CREATE,
> NLM_F_REPLACE, NLM_F_EXCL, NLM_F_APPEND)
>
> 1) Create: NLM_F_CREATE
> 2) Create exclusively i.e reject if already created
> (NLM_F_CREATE|NLM_F_EXCL)
> 3) Create or modify (which is the semantic you are refering to)
> NLM_F_CREATE|NLM_F_REPLACE
> 4) Append - which means "I dont care if it exists, just append it"
> NLM_F_CREATE|NLM_F_APPEND

I considered passing netlink flags in to driver, but the kernel logic
in fib_table_insert() already takes care of the checks required by the
flags, and from the driver's perspective, only three ops are needed:
add, del, and mod.  And I've combined add and mod into the same op,
with the assumption the driver can know if an entry exists or not.

Can it work?

Let's try the various user cmds and see what happens:

ip route add ...             CREATE|EXCL

    if kernel FIB entry exists
        return -EEXIST to user
    else
        call driver add op
        add kernel FIB entry

ip route change ...        REPLACE

    if kernel FIB entry exists
        call driver add op             // driver treats this as a mod
        modify kernel FIB entry
    else
        return -ENOENT

ip route replace ...         CREATE|REPLACE

    if kernel FIB entry exists
         call driver add op             // driver treats this as a mod
         modify kernel FIB entry
    else
        call driver add op
        add kernel FIB entry

ip route prepend ...        CREATE

    if kernel FIB entry exists
         call driver add op             // driver treats this as a mod
         prepend kernel FIB entry
    else
        call driver add op
        add kernel FIB entry

ip route append ...          CREATE|APPEND

    if kernel FIB entry exists
         call driver add op             // driver treats this as a mod
         append kernel FIB entry
    else
        call driver add op
        add kernel FIB entry


I'm not 100% on the prepend/append cases.  Maybe don't try to offload
prepend/append cases?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html