tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bridge(4): BRIDGE_MPSAFE by default and applying psref(9)
On Tue, Apr 19, 2016 at 12:27 AM, Taylor R Campbell
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> Date: Mon, 18 Apr 2016 17:06:51 +0900
> From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
>
> On Fri, Apr 15, 2016 at 5:37 AM, Taylor R Campbell
> <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> > You could make (e.g.) bridge_input always satisfy the contract by
> > doing
> >
> > int bound = curlwp->l_pflag & LP_BOUND;
> > curlwp->l_pflag |= LP_BOUND;
> > ...
> > curlwp->l_pflag ^= bound ^ LP_BOUND;
> >
> > if you can't guarantee that every caller will be in a softint.
>
> Good idea. It works for bridge.
>
> Only shmif(4) and virt(4) of the rump kernel are the objectives.
> Considering that introducing psref to other L2 components
> (vlan and bpf) in the future, I think it's better to put
> the LP_BOUND stuffs to shmif and virt.
>
> Sounds good to me.
>
> > And this protocol seems fishy to me -- what stops bridge_clone_destroy
> > from freeing a bridge while another CPU is in the middle of
> > bridge_ioctl_add, after the sc_dying check?
>
> I wrote a patch to solve the issue by putting ifioctl_detach
> before calling destruction routines of an interface:
> http://www.netbsd.org/~ozaki-r/early-ifioctl_detach.diff
>
> The change should prevent *_clone_destroy and *_ioctl from
> running in parallel.
>
> Hmm... I'm rather confused by the ifnet_lock_enter/exit business.
> Why isn't ifnet_lock_enter simply mutex_enter(&il->il_lock) and
> ifnet_lock_exit simply mutex_exit(&il->il_lock)? I think it's trying
> to do something like psref, using per-CPU-per-object counts instead of
> per-CPU lists -- but it doesn't actually avoid the lock.
>
> We should try to get dyoung@ to look at this.
We will apply psref to struct ifnet for safe interface destruction
at some point. Can we use the psref for ioctl instead of il_lock?
>
> > bridge_try_hold_bif should perhaps be renamed now that it never fails,
> > say to bridge_acquire_member -- or maybe we can just remove
> > bridge_try_hold_bif and bridge_release_member altogether, since
> > they're just psref_acquire and psref_release.
>
> I choose bridge_acquire_member for now. I would get rid of
> bridge_*_member in another step later.
>
> So new patches are here:
> http://www.netbsd.org/~ozaki-r/psref-bridge-v2.diff
> http://www.netbsd.org/~ozaki-r/psref-bridge-v2-diff.diff
>
> The changes also reflect christos and mrg suggestions.
>
> Looks good! I don't have time for a thorough review right now, but
> nothing jumped out at me on a quick skim.
Thanks! I committed the patch anyway, although we have to fix the above
issue somehow.
ozaki-r
Home |
Main Index |
Thread Index |
Old Index