On 27/06/20(Sat) 17:58, Vitaliy Makkoveev wrote:
> > [...]
> > Look at r1.329 of net/if.c. Prior to this change if_detach_queues() was
> > used to free all mbufs when an interface was removed. Now lazy freeing
> > is used everytime if_get(9) rerturns NULL.
> >
> > This is possible because we st
On Sat, Jun 27, 2020 at 12:41:29PM +0200, Martin Pieuchot wrote:
> On 27/06/20(Sat) 01:02, Vitaliy Makkoveev wrote:
> > On Fri, Jun 26, 2020 at 09:15:38PM +0200, Martin Pieuchot wrote:
> > > On 26/06/20(Fri) 17:53, Vitaliy Makkoveev wrote:
> > > > On Fri, Jun 26, 2020 at 02:29:03PM +0200, Martin Pi
On 27/06/20(Sat) 01:02, Vitaliy Makkoveev wrote:
> On Fri, Jun 26, 2020 at 09:15:38PM +0200, Martin Pieuchot wrote:
> > On 26/06/20(Fri) 17:53, Vitaliy Makkoveev wrote:
> > > On Fri, Jun 26, 2020 at 02:29:03PM +0200, Martin Pieuchot wrote:
> > > > On 26/06/20(Fri) 12:35, Vitaliy Makkoveev wrote:
>
On Fri, Jun 26, 2020 at 09:15:38PM +0200, Martin Pieuchot wrote:
> On 26/06/20(Fri) 17:53, Vitaliy Makkoveev wrote:
> > On Fri, Jun 26, 2020 at 02:29:03PM +0200, Martin Pieuchot wrote:
> > > On 26/06/20(Fri) 12:35, Vitaliy Makkoveev wrote:
> > > > On Fri, Jun 26, 2020 at 10:23:42AM +0200, Martin Pi
On 26/06/20(Fri) 17:53, Vitaliy Makkoveev wrote:
> On Fri, Jun 26, 2020 at 02:29:03PM +0200, Martin Pieuchot wrote:
> > On 26/06/20(Fri) 12:35, Vitaliy Makkoveev wrote:
> > > On Fri, Jun 26, 2020 at 10:23:42AM +0200, Martin Pieuchot wrote:
> > > > On 25/06/20(Thu) 19:56, Vitaliy Makkoveev wrote:
>
On Fri, Jun 26, 2020 at 02:29:03PM +0200, Martin Pieuchot wrote:
> On 26/06/20(Fri) 12:35, Vitaliy Makkoveev wrote:
> > On Fri, Jun 26, 2020 at 10:23:42AM +0200, Martin Pieuchot wrote:
> > > On 25/06/20(Thu) 19:56, Vitaliy Makkoveev wrote:
> > > > Updated diff.
> > > >
> > > > OpenBSD uses 16 bit
On Fri, Jun 26, 2020 at 10:23:42AM +0200, Martin Pieuchot wrote:
> On 25/06/20(Thu) 19:56, Vitaliy Makkoveev wrote:
> > Updated diff.
> >
> > OpenBSD uses 16 bit counter for allocate interface indexes. So we can't
> > store index in session and be sure if_get(9) returned `ifnet' is our
> > origin
On 26/06/20(Fri) 12:35, Vitaliy Makkoveev wrote:
> On Fri, Jun 26, 2020 at 10:23:42AM +0200, Martin Pieuchot wrote:
> > On 25/06/20(Thu) 19:56, Vitaliy Makkoveev wrote:
> > > Updated diff.
> > >
> > > OpenBSD uses 16 bit counter for allocate interface indexes. So we can't
> > > store index in ses
On 25/06/20(Thu) 19:56, Vitaliy Makkoveev wrote:
> Updated diff.
>
> OpenBSD uses 16 bit counter for allocate interface indexes. So we can't
> store index in session and be sure if_get(9) returned `ifnet' is our
> original `ifnet'.
Why not? The point of if_get(9) is to be sure. If that doesn't
> On 25 Jun 2020, at 20:13, Christiano F. Haesbaert
> wrote:
>
> You can.
>
> The idea is that ifindex is always monotonically increased, so to actually
> get a new interface you would have to have "overflowed" 65k interfaces,
> which is unreal.
>
> So if your interface is gone, you can be
Updated diff.
OpenBSD uses 16 bit counter for allocate interface indexes. So we can't
store index in session and be sure if_get(9) returned `ifnet' is our
original `ifnet'.
Now each pipex(4) session has it's own reference to `ifnet'. Also pppoe
related sessions has the reference to it's ethernet
> On 25 Jun 2020, at 16:35, Christiano F. Haesbaert
> wrote:
>
> On Thu, 25 Jun 2020 at 14:06, Vitaliy Makkoveev
> wrote:
>>
>>
>>
>>> On 25 Jun 2020, at 11:55, Martin Pieuchot wrote:
>>>
>>> On 24/06/20(Wed) 17:10, Vitaliy Makkoveev wrote:
While `mbuf' enqueued to `pipexinq' or `pipe
You can.
The idea is that ifindex is always monotonically increased, so to actually
get a new interface you would have to have "overflowed" 65k interfaces,
which is unreal.
So if your interface is gone, you can be sure if_get will give you NULL.
On Thu, Jun 25, 2020, 18:55 Vitaliy Makkoveev
wro
> On 25 Jun 2020, at 11:55, Martin Pieuchot wrote:
>
> On 24/06/20(Wed) 17:10, Vitaliy Makkoveev wrote:
>> While `mbuf' enqueued to `pipexinq' or `pipexoutq' it has the reference
>> to corresponding pipex(4) session as `ph_cookie'. `ph_cookie' is
>> accessed by pipexintr() and it's always deff
On Thu, 25 Jun 2020 at 14:06, Vitaliy Makkoveev
wrote:
>
>
>
> > On 25 Jun 2020, at 11:55, Martin Pieuchot wrote:
> >
> > On 24/06/20(Wed) 17:10, Vitaliy Makkoveev wrote:
> >> While `mbuf' enqueued to `pipexinq' or `pipexoutq' it has the reference
> >> to corresponding pipex(4) session as `ph_coo
On 24/06/20(Wed) 17:10, Vitaliy Makkoveev wrote:
> While `mbuf' enqueued to `pipexinq' or `pipexoutq' it has the reference
> to corresponding pipex(4) session as `ph_cookie'. `ph_cookie' is
> accessed by pipexintr() and it's always defferent context from context
> where we destroy session. `ph_cook
While `mbuf' enqueued to `pipexinq' or `pipexoutq' it has the reference
to corresponding pipex(4) session as `ph_cookie'. `ph_cookie' is
accessed by pipexintr() and it's always defferent context from context
where we destroy session. `ph_cookie' is protected only while we destroy
session by pipex_t
17 matches
Mail list logo
