On Sun, Jun 26, 2022 at 05:43:55PM +0300, Vitaliy Makkoveev wrote:
> The updated diff below. I'll commit it today later.
> - /* [N] peer's address hash chain */
> - uint16_tstate; /* [N] pipex session state */
> +
On Sun, Jun 26, 2022 at 02:37:41PM +0200, Alexander Bluhm wrote:
> On Wed, Jun 22, 2022 at 02:46:32PM +0300, Vitaliy Makkoveev wrote:
> > @@ -547,9 +547,11 @@ ether_input(struct ifnet *ifp, struct mb
> >
> > if ((session = pipex_pppoe_lookup_session(m)) != NULL) {
> >
On Wed, Jun 22, 2022 at 02:46:32PM +0300, Vitaliy Makkoveev wrote:
> @@ -547,9 +547,11 @@ ether_input(struct ifnet *ifp, struct mb
>
> if ((session = pipex_pppoe_lookup_session(m)) != NULL) {
> pipex_pppoe_input(m, session);
> +
Please drop previous diff. counters_read(9) could sleep, so we can't
call it with mutex(9) held.
The diff below still uses `pipex_list_mtx' mutex(9) for pipex(4) lists
protection, but for safe `session' dereference it user reference
counters.
Index: sys/net/if_ethersubr.c
Hi,
Only pppoe sessions are affected. Unfortunately, netlock is required
for pipex(4) pppoe output processing, and we can’t enforce netlock
state anymore for pppoe related (*if_qstart)(). We use netlock to
protect pipex(4) global list and the dereference of `session’
pointers. Now we can’t rely on
On 20.6.2022. 16:46, Vitaliy Makkoveev wrote:
> And use this mutex(9) to make the `session' dereference safe.
>
> Hrvoje Popovski pointed me, he triggered netlock assertion with pipex(4)
> pppoe sessions:
>
Hi,
I can trigger this splassert with plain snapshot and with only pppoe
clients. npppd
And use this mutex(9) to make the `session' dereference safe.
Hrvoje Popovski pointed me, he triggered netlock assertion with pipex(4)
pppoe sessions:
>
> r420-1# splassert: pipex_ppp_output: want 2 have 0
> Starting stack trace...
> pipex_ppp_output(fd80cb7c9500,800022761200,21) at
> pi
