netdev - Re: [PATCH net-next V3 2/4] net/dst: Utility functions to build dst

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: <CAJ3xEMhF=xskN6bpfP2=euKiCUz=vGF_JvMsY78=kXvhQ7HY-g@mail.gmail.com>
Date:   Fri, 26 Aug 2016 09:14:40 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Shmulik Ladkani <shmulik.ladkani@...il.com>
Cc:     Hadar Hen Zion <hadarh@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>, Jiri Benc <jbenc@...hat.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Tom Herbert <tom@...bertland.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Amir Vadai <amirva@...lanox.com>, Amir Vadai <amir@...ai.me>
Subject: Re: [PATCH net-next V3 2/4] net/dst: Utility functions to build
 dst_metadata without supplying an skb

On Thu, Aug 25, 2016 at 7:40 PM, Shmulik Ladkani
<shmulik.ladkani@...il.com> wrote:
> Hi,
>
> On Thu, 25 Aug 2016 19:13:45 +0300 Hadar Hen Zion <hadarh@...lanox.com> wrote:
>> From: Amir Vadai <amir@...ai.me>
>>
>> Extract _ip_tun_rx_dst() and _ipv6_tun_rx_dst() out of ip_tun_rx_dst()
>> and ipv6_tun_rx_dst(), to be used without supplying an skb.
>
> Per this v3, the newly introduced helpers ate named _ip_tun_set_dst and
> _ipv6_tun_set_dst - better alter the log message to reflect that.

sure, will fix that

>> +static inline struct metadata_dst *
>> +_ipv6_tun_set_dst(const struct in6_addr saddr, const struct in6_addr daddr,
>> +               __u8 tos, __u8 ttl, __be32 label, __be16 flags,
>> +               __be64 tunnel_id, int md_size)
>> +{
>
> Any reason not passing in6_addr pointers, as suggested?

guess not

> This is the common practice for ipv6 address parameters.

will do