> On 29 Jul 2020, at 00:09, sven falempin <sven.falem...@gmail.com> wrote:
>
> On Tue, Jul 28, 2020 at 4:42 PM Vitaliy Makkoveev <m...@openbsd.org> wrote:
>>
>> On Tue, Jul 28, 2020 at 04:10:01PM -0400, sven falempin wrote:
>>> Hello,
>>>
>>> I am running some trunk interfaces in a multi core environment,
>>> it's a slightly modified version, i have a few NET_ASSERT_LOCKED();
>>> suspecting some multi core shenanigans, which i guess was confirmed:
>>> (unsure the have X meaning, but i ' m pretty sure 256 is very wrong)
>>> the if_trunk.c locking is completely unmodified
>>> The code is 6.7-stable
>>>
>>> splassert: lacp_detach: want 2 have 0
>>> splassert: lacp_detach: want 2 have 0
>>> splassert: lacp_detach: want 2 have 256
>>>
>>> I noticed : trunk_clone_destroy ,call
>>>
>>> if (tr->tr_proto != TRUNK_PROTO_NONE)
>>> tr->tr_detach(tr);
>>>
>>> outside the lock, and that trunk_ioctl call it
>>>
>>> if (tr->tr_proto != TRUNK_PROTO_NONE)
>>> error = tr->tr_detach(tr);
>>>
>>> but ioctl is as far as i understand locked.
>>> I'm unsure if the difficult and amazing unlocking work
>>> did an oopsies or if ioctl is already assumed unlocked.
>>>
>>> Kindly inform me.
>>> Best regards, thank you for reading.
>>>
>>
>> lacp_detach() touches nothing which requires NET_LOCK(). What is the
>> reason you placed assertion to lacp_detach()?
>
> <<it's a slightly modified version, i have a few NET_ASSERT_LOCKED()>>
>
> the lacp_detach is not yours, i put them here because i have a NULL pointer
> popping in other 'driver' callback.
>
> I'm tracking this and trying to understand how this memory is 'nullified'
> mid function.
I have no telepathy skills. Sorry. If you have panics send please dmesg(8)
output and instruction for reproduce.
>
> I do not think putting NET_ASSERT_LOCKED can be harmful in any way.
> If so please tell me.
>
What is the data you think needs be protected by netlock?
> I am just tracking a bug and noticed these detach locking strangeness.
>
