| 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
| ||
|
Date: Sun, 8 Mar 2015 15:16:50 -0700 From: Scott Feldman <sfeldma@...il.com> To: roopa <roopa@...ulusnetworks.com> Cc: Jamal Hadi Salim <jhs@...atatu.com>, Netdev <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Jiří Pírko <jiri@...nulli.us>, "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 Sun, Mar 8, 2015 at 7:31 AM, roopa <roopa@...ulusnetworks.com> wrote: > On 3/6/15, 11:59 AM, Scott Feldman wrote: >> >> >> 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? > > We will have to offload prepend/append cases as well (I had also raised this > earlier in v2). Can you show an working example of prepend/append case where programming hardware would be different than the replace case? -scott -- 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
Powered by blists - more mailing lists