Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 2 Aug 2021 15:43:20 +0200
From:   Guillaume Nault <gnault@redhat.com>
To:     Pali =?iso-8859-1?Q?Roh=E1r?= <pali@kernel.org>
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: How to find out name or id of newly created interface
Message-ID: <20210802134320.GB3756@pc-32.home>
References: <20210731203054.72mw3rbgcjuqbf4j@pali>
 <20210802100238.GA3756@pc-32.home>
 <20210802105825.td57b5rd3d6xfxfo@pali>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210802105825.td57b5rd3d6xfxfo@pali>
Precedence: bulk

On Mon, Aug 02, 2021 at 12:58:25PM +0200, Pali Roh?r wrote:
> On Monday 02 August 2021 12:02:38 Guillaume Nault wrote:
> > 
> > So the proper solution is to implement NLM_F_ECHO support for
> > RTM_NEWLINK messages (RTM_NEWROUTE is an example of netlink handler
> > that supports NLM_F_ECHO, see rtmsg_fib()).
> 
> Do you know if there is some workaround / other solution which can be
> used by userspace applications now? And also with stable kernels (which
> obviously do not receive this new NLM_F_ECHO support for RTM_NEWLINK)?

I unfortunately can't think of any clean solution. It might be possible
to create the new interface with attributes very unlikely to be used by
external programs and retrieve the interface name and id by monitoring
link creation messages (like 'ip monitor' does). But at this point it's
probably easier to just set the interface name and retry with a
different name every time it conflicted with an existing device.

Maybe someone else could propose less hacky solutions, but I really
can't think of anything else apart from implementing NLM_F_ECHO.