netdev - Re: [PATCH] udp: Unbreak modules that rely on external __skb_recv

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]

Date:   Mon, 8 Oct 2018 07:15:22 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     David Miller <davem@...emloft.net>
cc:     yoshfuji@...ux-ipv6.org, pabeni@...hat.com, edumazet@...gle.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] udp: Unbreak modules that rely on external __skb_recv_udp()
 availability

On Sun, 7 Oct 2018, David Miller wrote:

> > From: Jiri Kosina <jkosina@...e.cz>
> > 
> > Commit 2276f58ac589 ("udp: use a separate rx queue for packet reception")
> > turned static inline __skb_recv_udp() from being a trivial helper around
> > __skb_recv_datagram() into a UDP specific implementaion, making it
> > EXPORT_SYMBOL_GPL() at the same time.
> > 
> > There are external modules that got broken by __skb_recv_udp() not being
> > visible to them. Let's unbreak them by making __skb_recv_udp EXPORT_SYMBOL().
> > 
> > Rationale (one of those) why this is actually "technically correct" thing 
> > to do: __skb_recv_udp() used to be an inline wrapper around 
> > __skb_recv_datagram(), which itself (still, and correctly so, I believe) 
> > is EXPORT_SYMBOL().
> > 
> > Cc: Paolo Abeni <pabeni@...hat.com>
> > Cc: Eric Dumazet <edumazet@...gle.com>
> > Fixes: 2276f58ac589 ("udp: use a separate rx queue for packet reception")
> > Signed-off-by: Jiri Kosina <jkosina@...e.cz>
> 
> Applied...

Thanks.

> But waiting from 4.13 until now to bring this up is really pushing it...

Well, we been hit by this in distro kernel that got 2276f58ac589 
backported only recently, so that's why.

Thanks again,

-- 
Jiri Kosina
SUSE Labs