Hello,
>
> I agree we should protect against that - if I add a sleep there, I can easily
> cause a panic with 'ifconfig vlan10 destroy & ifconfig vlan10 destroy'.
> I think that's a separate issue though, as the same window is present in
> the existing code.
>
that's true. it's refcnt_final
On Mon, Jan 27, 2020 at 12:48:49AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > > I'm not sure about your diff see below.
> >
> > visa@ pointed out that PF_LOCK will introduce a potential sleep inside
> > if_vinput(),
> > making this unsafe, so here's a less optimistic diff where only
Hello,
> > I'm not sure about your diff see below.
>
> visa@ pointed out that PF_LOCK will introduce a potential sleep inside
> if_vinput(),
> making this unsafe, so here's a less optimistic diff where only the vlan list
> traversal is inside the SMR read section, and vlan_softcs are still
On Sun, Jan 26, 2020 at 11:02:29PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Sun, Jan 26, 2020 at 10:06:24AM +1100, Jonathan Matthew wrote:
> > Converting vlan(4) to use SMR instead of SRP to protect the instance lists
> > is pretty simple. vlan_input() doesn't keep a reference to vlan
Hello,
On Sun, Jan 26, 2020 at 10:06:24AM +1100, Jonathan Matthew wrote:
> Converting vlan(4) to use SMR instead of SRP to protect the instance lists
> is pretty simple. vlan_input() doesn't keep a reference to vlan_softcs
> outside
> the read critical section, so we don't need to reference cou
Converting vlan(4) to use SMR instead of SRP to protect the instance lists
is pretty simple. vlan_input() doesn't keep a reference to vlan_softcs outside
the read critical section, so we don't need to reference count them any more.
After the smr_barrier() in vlan_clone_destroy, all pointers to the