netdev - Re: [PATCH net-next] net: Remove VRF change to udp

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: <55E4918E.7030104@cumulusnetworks.com>
Date:	Mon, 31 Aug 2015 11:40:30 -0600
From:	David Ahern <dsa@...ulusnetworks.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>
Subject: Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg

Hi Tom:

On 8/31/15 11:22 AM, Tom Herbert wrote:
> It's a major departure from current convention. The source address of
> the packet should be set before doing ip_send_skb. In UDP unconnected
> case ip_route_output_flow calls inet_select_addr. AKAIK there is no
> provision for not setting the source address and relying on the output
> device to do this in its transmit routine. I still think it would be
> better to call into the VRF device from inet_select_addr using an ndo
> function.

I was not disregarding your suggestion and definitely appreciate the 
advice. I will look into it in time. In fact I was looking at how to 
better encapsulate FIB oif changes (e.g., with ndo) on the plane home 
yesterday, but those take time and seem more appropriate for 4.4.

My intention with this patch is to reign in the VRF footprint and by 
extension impact for 4.3 without losing functionality. During the merge 
window for 4.3 net-next will be closed and it provides a good time to 
investigate abstractions like ndo handlers.

David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html