Please drop this diff.
Within rt_clone() we have the code section protected by kernel lock, and
this code section could be reached with mutex(9) held.
pipex(4) needs to be more refactored before introduce per-session
locking.
> On 28 Jun 2022, at 23:14, Vitaliy Makkoveev wrote:
>
> On Tue, Jun
On Tue, Jun 28, 2022 at 09:05:09PM +0300, Vitaliy Makkoveev wrote:
> The updated diff. It was triggered by Hrvoje Popovski, we could do
> direct (*if_qstart)() call in pipex(4) PPPOE input path, and this
> provides deadlock. The updated diff uses ip{,6}_send() instead of
> ipv{4,6}_input().
>
I th
The updated diff. It was triggered by Hrvoje Popovski, we could do
direct (*if_qstart)() call in pipex(4) PPPOE input path, and this
provides deadlock. The updated diff uses ip{,6}_send() instead of
ipv{4,6}_input().
r420-1# witness: acquiring duplicate lock of same type: "&session->pxs_mtx"
1st
We can't predict netlock state when we executing pipex(4) related
(*if_qstart)() handlers, so we can't use netlock for pipex(4)
protection.
We already use `pipex_list_mtx' for global pipex(4) data, so
Use per-session `pxs_mtx' mutex(9) for pipex session context protection.
We already use `pipex_l
