On (09/19/07 19:36), Sowmini.Varadhan at Sun.COM wrote:
> On (09/19/07 14:01), Artem Kachitchkine wrote:
> > No, this is all supported in this wad. proplists are refcounted, they won't
> > be freed until it reaches 0. Drivers increment/decrement it via
> > mac_prop_init/fini. The framework does this via mac_prop_load/unload -
> > which are called from mac_start/stop. So all cases are covered: when only
> > the framework uses cached properties, when only the driver uses them, and
> > when both.
>
> Ok, I missed this part- I'll look into this carefully tomorrow.
I looked at this again. There's one part that's still not clear to me:
consider the following sequence
# ifconfig <link> plumb
# dladm set-linkprop -p <name>=<value1> <link>
# ifconfig <link> unplumb
# dladm set-linkprop -p <name>=<value2> <link>
we would be trying to update the existing entry for <name> from
value1 to value2 correct? So let's say the driver is doing the
mac_prop_fini() as part of it's detach, what prevents the following
sequence from happening?
thread 1 (mac_prop_update) thread 2 (link_detach)
mp1 = mac_proplist_find
returns existing mac_proplist_t entry
mac_prop_fini
kmem_free the mp1
mac.c line 2623 gets bad pointer
rw_enter(&mpl->mpl_lock, RW_WRITER);
--Sowmini
