Re: [PATCH net-next] rtnetlink: delay RTM_DELLINK notification until after ndo_uninit()

[Roopa Prabhu <roopa@cumulusnetworks.com>]

On 12/2/14, 8:19 AM, Eric Dumazet wrote:
> On Tue, 2014-12-02 at 08:08 -0800, Roopa Prabhu wrote:
>
>> interestingly I have never seen this. We use this heavily with most
>> other logical devices.
>> Which tells me most logical devices do have checks in their fill_info.
>> The patch idea is good. My only concern is stale information
>> in the DELLINK notification. Because,  ndo_uninit() does do a lot of
>> cleanup, sending
>> newlink's for some of these cleanup changes. And now with your patch the
>> dellink notification
>> skb probably  contains information that has been already deleted by
>> ndo_uninit ?
> What do you mean ? We send a message and device is deleted.
>
> Its an asynchronous message.
>
> At the time you read it, lot of things might already have changed, no
> matter how careful you are.
>
> This patch permits to get a precise snapshot of device info right before
> dismantle (like stats counters for accounting purpose)

fair point. But the commit that moved things around was done to handle 
cases where,
the ndo_uninit() already sends some notifications to userspace for the 
changes
during uninit (example bond driver).

The only point i was making was that the dellink after the ndo_uninit in 
your
case now contains state that was prior to uninit for these drivers.

For the bug being discussed, i was thinking fill_info in ipvlan should 
be fixed to handle this correctly.
  ie fill_info could be fixed to not barf if the private information is 
not present and just return nothing.
But understand that this will not give you the state prior to uninit for 
some drivers.