netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next-2.6] can: deny filterlist access on non-CAN interfaces
@ 2010-01-26 13:51 Oliver Hartkopp
  2010-02-02 15:21 ` David Miller
  0 siblings, 1 reply; 4+ messages in thread
From: Oliver Hartkopp @ 2010-01-26 13:51 UTC (permalink / raw)
  To: David Miller; +Cc: Linux Netdev List

In commit 20dd3850bcf860561496827b711fa10fecf6e787 "can: Speed up CAN frame
receiption by using ml_priv" the formerly used hlist of receiver lists for
each CAN netdevice has been replaced. 

The hlist content ensured only CAN netdevices to be accessed by the
can_rx_(un)register() functions which accidently dropped away together with
the hlist receiver implementation.

This patch re-introduces the check for CAN netdevices in can_rx_(un)register().

Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>

---

diff --git a/net/can/af_can.c b/net/can/af_can.c
index bc18b08..702be5a 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -415,6 +415,9 @@ int can_rx_register(struct net_device *dev, canid_t can_id, canid_t mask,
 
 	/* insert new receiver  (dev,canid,mask) -> (func,data) */
 
+	if (dev && dev->type != ARPHRD_CAN)
+		return -ENODEV;
+
 	r = kmem_cache_alloc(rcv_cache, GFP_KERNEL);
 	if (!r)
 		return -ENOMEM;
@@ -478,6 +481,9 @@ void can_rx_unregister(struct net_device *dev, canid_t can_id, canid_t mask,
 	struct hlist_node *next;
 	struct dev_rcv_lists *d;
 
+	if (dev && dev->type != ARPHRD_CAN)
+		return;
+
 	spin_lock(&can_rcvlists_lock);
 
 	d = find_dev_rcv_lists(dev);


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH net-next-2.6] can: deny filterlist access on non-CAN interfaces
@ 2010-01-29  7:41 Oliver Hartkopp
  2010-01-29  8:09 ` David Miller
  0 siblings, 1 reply; 4+ messages in thread
From: Oliver Hartkopp @ 2010-01-29  7:41 UTC (permalink / raw)
  To: David Miller; +Cc: Linux Netdev List

Hello Dave,

are you fine with this fix or are you just waiting for Wolfgangs ACK?

As this is networklayer stuff in net/can and not in drivers/net/can you won't
get any ACK from Wolfgang, as i'm the maintainer for that ;-)

If it makes is more clearly i would suggest to name my networklayer patches with

[PATCH net-next-2.6] net/can: ...

instead of

[PATCH net-next-2.6] can: ...

in the future. Would this be ok for you?

Thanks & best regards,
Oliver


-------- Original Message --------
Subject: [PATCH net-next-2.6] can: deny filterlist access on non-CAN interfaces
Date: Tue, 26 Jan 2010 14:51:59 +0100
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: David Miller <davem@davemloft.net>
CC: Linux Netdev List <netdev@vger.kernel.org>

In commit 20dd3850bcf860561496827b711fa10fecf6e787 "can: Speed up CAN frame
receiption by using ml_priv" the formerly used hlist of receiver lists for
each CAN netdevice has been replaced.

The hlist content ensured only CAN netdevices to be accessed by the
can_rx_(un)register() functions which accidently dropped away together with
the hlist receiver implementation.

This patch re-introduces the check for CAN netdevices in can_rx_(un)register().

Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>

---

diff --git a/net/can/af_can.c b/net/can/af_can.c
index bc18b08..702be5a 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -415,6 +415,9 @@ int can_rx_register(struct net_device *dev, canid_t
can_id, canid_t mask,

 	/* insert new receiver  (dev,canid,mask) -> (func,data) */

+	if (dev && dev->type != ARPHRD_CAN)
+		return -ENODEV;
+
 	r = kmem_cache_alloc(rcv_cache, GFP_KERNEL);
 	if (!r)
 		return -ENOMEM;
@@ -478,6 +481,9 @@ void can_rx_unregister(struct net_device *dev, canid_t
can_id, canid_t mask,
 	struct hlist_node *next;
 	struct dev_rcv_lists *d;

+	if (dev && dev->type != ARPHRD_CAN)
+		return;
+
 	spin_lock(&can_rcvlists_lock);

 	d = find_dev_rcv_lists(dev);




^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH net-next-2.6] can: deny filterlist access on non-CAN interfaces
  2010-01-29  7:41 Oliver Hartkopp
@ 2010-01-29  8:09 ` David Miller
  0 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2010-01-29  8:09 UTC (permalink / raw)
  To: socketcan; +Cc: netdev

From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Fri, 29 Jan 2010 08:41:55 +0100

> are you fine with this fix or are you just waiting for Wolfgangs ACK?

It's simply in my backlog, I'll get to it soon.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net-next-2.6] can: deny filterlist access on non-CAN interfaces
  2010-01-26 13:51 [PATCH net-next-2.6] can: deny filterlist access on non-CAN interfaces Oliver Hartkopp
@ 2010-02-02 15:21 ` David Miller
  0 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2010-02-02 15:21 UTC (permalink / raw)
  To: socketcan; +Cc: netdev

From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Tue, 26 Jan 2010 14:51:59 +0100

> In commit 20dd3850bcf860561496827b711fa10fecf6e787 "can: Speed up CAN frame
> receiption by using ml_priv" the formerly used hlist of receiver lists for
> each CAN netdevice has been replaced. 
> 
> The hlist content ensured only CAN netdevices to be accessed by the
> can_rx_(un)register() functions which accidently dropped away together with
> the hlist receiver implementation.
> 
> This patch re-introduces the check for CAN netdevices in can_rx_(un)register().
> 
> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>

Applied, thanks Oliver.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-02-02 15:21 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-26 13:51 [PATCH net-next-2.6] can: deny filterlist access on non-CAN interfaces Oliver Hartkopp
2010-02-02 15:21 ` David Miller
  -- strict thread matches above, loose matches on Subject: below --
2010-01-29  7:41 Oliver Hartkopp
2010-01-29  8:09 ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).