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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZC1LYEp8anZWkRFq@corigine.com>
Date:   Wed, 5 Apr 2023 12:20:16 +0200
From:   Simon Horman <simon.horman@...igine.com>
To:     Vladimir Nikishkin <vladimir@...ishkin.pw>
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

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.

...