[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150512.184532.1368324454021599990.davem@davemloft.net>
Date: Tue, 12 May 2015 18:45:32 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: sfeldma@...il.com
Cc: netdev@...r.kernel.org, jiri@...nulli.us,
roopa@...ulusnetworks.com, linux@...ck-us.net,
f.fainelli@...il.com, andrew@...n.ch, simon.horman@...ronome.com,
joe@...ches.com, sridhar.samudrala@...el.com, ronen.arad@...el.com
Subject: Re: [PATCH net-next v7 00/24] switchdev: spring cleanup
From: sfeldma@...il.com
Date: Sun, 10 May 2015 09:47:45 -0700
> The main theme of this patch set is to cleanup swdev in preparation for
> new features or fixes to be added soon. We have a pretty good idea now how
> to handle stacked drivers in swdev, but there where some loose ends. For
> example, if a set failed in the middle of walking the lower devs, we would
> leave the system in an undefined state...there was no way to recover back to
> the previous state. Speaking of sets, also recognize a pattern that most
> swdev API accesses are gets or sets of port attributes, so go ahead and make
> port attr get/set the central swdev API, and convert everything that is
> set-ish/get-ish to this new API.
>
> Features/fixes that should follow from this cleanup:
>
> - solve the duplicate pkt forwarding issue
> - get/set bridge attrs, like ageing_time, from/to device
> - get/set more bridge port attrs from/to device
>
> There are some rename cleanups tagging along at the end, to give swdev
> consistent naming.
>
> And finally, some much needed updates to the switchdev.txt documentation to
> hopefully capture the state-of-the-art of swdev. Hopefully, we can do a better
> job keeping this document up-to-date.
>
> Tested with rocker, of course, to make sure nothing functional broke. There
> are a couple minor tweaks to DSA code for getting switch ID and setting STP
> updates to use new API, but not expecting amy breakage there.
Ok, this series looks good for the most part so I'll apply it, thanks
Scott.
One thing that worries me is that deferral of operations when rtnl
isn't held. You've lost the ability there to signal an error back
to the user, so you just return zero and BUG() if it does actually
error.
You'll need to do something better in that situation in my opinion.
My preference would be to require that RTNL is held on any traversal
into those code paths.
--
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