netdev - Re: [PATCH net-next v5] vxlan: try to send a packet normally if local bypass fails

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <878rf6va81.fsf@laptop.lockywolf.net>
Date:   Wed, 05 Apr 2023 19:24:56 +0800
From:   Vladimir Nikishkin <vladimir@...ishkin.pw>
To:     Simon Horman <simon.horman@...igine.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
        kuba@...nel.org, pabeni@...hat.com,
        eng.alaamohamedsoliman.am@...il.com, gnault@...hat.com,
        razor@...ckwall.org
Subject: Re: [PATCH net-next v5] vxlan: try to send a packet normally if
 local bypass fails


Simon Horman <simon.horman@...igine.com> writes:

> On Wed, Apr 05, 2023 at 01:05:02PM +0800, Vladimir Nikishkin wrote:
>> 
>> Simon Horman <simon.horman@...igine.com> writes:
>> 
>> > I'm a bit unsure about the logic around dst_release().
>> > But assuming it is correct, perhaps this is a slightly
>> 
>> Let me try to defend this logic.
>> 
>> In the previous version, if the destination is local (the first "if"),
>> then there is no need to keep the address in memory any more, hence the
>> address was free()'d at the beginning of the "if" (and was not freed
>> after the "if", because the address was still needed at the userspace
>> part.)
>> 
>> With this patch, the "localbypass" creates one more branch inside that
>> "if", which is handing over the processing logic to the userspace (which
>> has no free()). The older two branches _inside_ the "if" (vxlan
>> found/vxlan not found) are still terminating, and therefore have one
>> call to free() each.
>
> Hi Vladimir,
>
> thanks for your response.
>
> I do still feel that the code I proposed is slightly nicer
> and in keeping with general kernel coding practices.
> But I do also concede that is a highly subjective position.
>
> I do agree that your code is correct, within the scope of what the patch
> seeks to achieve.  And I do not object to you keeping it as is if that is
> your preference.
>
> ...

Hello, Simon

I have integrated all of your suggestions in v6. This response was only
to justify the correctness of the dst_release() call, which is not a
self-evident thing.

-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)
--
Fastmail.