Re: [PATCH] net: caif: Don't act on notification for non-caif devices

[Sjur BrÃndeland]

Hi Sasha,

> Since the list of CAIF devices is stored in the net generic struct in each
> net namespace, which is not initialized at that point, we see the following
> BUG():
>
> [ Â200.752016] kernel BUG at include/net/netns/generic.h:40!
...
> [ Â200.752016] Call Trace:
> [ Â200.752016] Â[<ffffffff825c3cea>] ? get_cfcnfg+0x3a/0x180
> [ Â200.752016] Â[<ffffffff821cf0b0>] ? lockdep_rtnl_is_held+0x10/0x20
> [ Â200.752016] Â[<ffffffff825c41be>] caif_device_notify+0x2e/0x530

Argh, my bad. This issue has been identified and fixed by David
Woodhouse earlier,
but was reintroduced again by me when adding support for CAIF over NCM.
The CAIF code is handling if net_generic() returns NULL, but I missed that
net_generic() does BUG_ON().

> Instead, we'll first check if the device in the notification is a CAIF device:
> Â- If it is - the net generic struct in that namespace must have been already
> initialized.
> Â- If not - just ignore it as we don't care about other devices.
>
> Signed-off-by: Sasha Levin <levinsasha928@xxxxxxxxx>

Nack, we have to handle other device types than just ARPHDR_CAIF after
introducing
CAIF over USB/NCM. I'd rather fix this in netns by removing the BUG_ON
and return
NULL. How about this instead:

diff --git a/include/net/netns/generic.h b/include/net/netns/generic.h
index 3419bf5..0fc2eea 100644
--- a/include/net/netns/generic.h
+++ b/include/net/netns/generic.h
@@ -37,8 +37,10 @@ static inline void *net_generic(const struct net *net, int id

        rcu_read_lock();
        ng = rcu_dereference(net->gen);
-       BUG_ON(id == 0 || id > ng->len);
-       ptr = ng->ptr[id - 1];
+       if (id == 0 || id > ng->len)
+               ptr = NULL;
+       else
+               ptr = ng->ptr[id - 1];
        rcu_read_unlock();

        return ptr;

I'll post a patch for this soon.

Regards,
Sjur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/