On 24/05/20(Sun) 22:58, Vitaliy Makkoveev wrote:
> > Please yes, remove the duplication before trying to address concurrency
> > issues. It will make review easier :)
>
> We stopped at `pppx_ifs_lk’ removal, so let’s continue but after [1]
> finished.
>
> 1.
Sorry about delay.
> On 20 May 2020, at 10:54, Martin Pieuchot wrote:
>
> On 14/05/20(Thu) 15:53, Vitaliy Makkoveev wrote:
>> Each `struct pppx_if' holds it's own `pipex_session' and this session is
>> used directly within ifnet's related handlers pppx_if_start() and
>> pppx_if_output().
>
> I
On 14/05/20(Thu) 15:53, Vitaliy Makkoveev wrote:
> Each `struct pppx_if' holds it's own `pipex_session' and this session is
> used directly within ifnet's related handlers pppx_if_start() and
> pppx_if_output().
I don't see a problem with keeping a reference on a pipex_session inside
the softc.
Each `struct pppx_if' holds it's own `pipex_session' and this session is
used directly within ifnet's related handlers pppx_if_start() and
pppx_if_output().
pppx_if_destroy() at first destroys `pipex_session' and calls
if_deatch() which can cause context switch. Hypothetically,
pppx_if_start() or
