On Tue, 23 Jun 2020 11:12:24 +0200 Bartosz Golaszewski wrote:

wt., 23 cze 2020 o 00:49 Jakub Kicinski [off-list ref] napisał(a):

quoted

On Mon, 22 Jun 2020 12:00:48 +0200 Bartosz Golaszewski wrote:  

quoted

From: Bartosz Golaszewski <redacted>

This devres helper registers a release callback that only unregisters
the net_device. It works perfectly fine with netdev structs that are
not managed on their own. There's no reason to check this - drop the
warning.

Signed-off-by: Bartosz Golaszewski <redacted>  

I think the reasoning for this suggestion was to catch possible UAF
errors. The netdev doesn't necessarily has to be from devm_alloc_*
but it has to be part of devm-ed memory or memory which is freed
after driver's remove callback.
 

Yes I understand that UAF was the concern here, but this limitation is
unnecessary. In its current form devm_register_netdev() only works for
struct net_device allocated with devm_alloc_etherdev(). Meanwhile
calling alloc_netdev() (which doesn't have its devm counterpart yet -
I may look into it shortly),

If resource managed alloc_netdev() is needed devm_alloc_netdev() can
be created, and even reuse devm_free_netdev() so no changes to the
warning are even necessary for such extension.

then registering a devm action with devm_add_action_or_reset() which
would free this memory is a perfectly fine use case. This patch would
make it possible.

alloc_netdev() + devm_add_action makes no sense in the upstream kernel,
just add the appropriate helper, we care little about out of tree code.

quoted

Are there cases in practice where you've seen the netdev not being
devm allocated?  

As I said above - alloc_netdev() used by wireless, can, usb etc.
drivers doesn't have a devres variant.