From: Patrick McHardy <kaber@trash•net>
To: Urs Thuermann <urs@isnogud•escape.de>
Cc: netdev@vger•kernel.org, David Miller <davem@davemloft•net>,
Thomas Gleixner <tglx@linutronix•de>,
Oliver Hartkopp <oliver@hartkopp•net>,
Oliver Hartkopp <oliver.hartkopp@volkswagen•de>
Subject: Re: [PATCH 2/7] CAN: Add PF_CAN core module
Date: Wed, 19 Sep 2007 10:27:58 +0200 [thread overview]
Message-ID: <46F0DD8E.8070808@trash.net> (raw)
In-Reply-To: <ygffy1bzn4c.fsf@janus.isnogud.escape.de>
Urs Thuermann wrote:
> Patrick McHardy <kaber@trash•net> writes:
>
>>>+HLIST_HEAD(rx_dev_list);
>>
>>
>>Same here (static).
>
>
> Can't be static since it's used in proc.c. But __read_mostly might
> make sense.
>
> What exactly is the effect of __read_mostly? Is that in a separate
> ELF section? Where is that finally located?
Its a seperate section to prevent false sharing.
>
>
>>>+ if (ret == -ENOSYS)
>>>+ printk(KERN_INFO "can: request_module(%s) not"
>>>+ " implemented.\n", module_name);
>>>+ else if (ret)
>>>+ printk(KERN_ERR "can: request_module(%s) failed\n",
>>>+ module_name);
>>
>>
>>Both of these printks seem to be user-triggerable, so they should
>>be rate-limited (or maybe get removed completely/changed to DBG).
>
>
> Hm, I don't think DBG() would be right here, since the messages show
> problems in the installation to the admin. OTOH, I see that a user
> can flood the log by opening sockets with invalid proto numbers. Rate
> limiting might solve this, or we should print the message only once
> per proto number. I will think about this.
IMO this is a perfectly normal condition (not finding a module).
Especially the !KMOD case is hardly an error.
>>>+ /* check for success and correct type */
>>>+ cp = proto_tab[protocol];
>>
>>
>>What prevents the module from getting unloaded again (and using
>>a stale pointer)?
>
>
> When the module is unloaded it calls can_proto_unregister() which
> clears the pointer. Do you see a race condition here?
Yes, you do request_module, load the module, get the cp pointer
from proto_tab, the module is unloaded again. cp points to
stable memory. Using module references would fix this.
>>>+ if (!(skb->dev->flags & IFF_LOOPBACK)) {
>>>+ /*
>>>+ * If the interface is not capable to do loopback
>>>+ * itself, we do it here.
>>>+ */
>>>+ struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
>>>+
>>>+ if (!newskb) {
>>>+ kfree_skb(skb);
>>>+ return -ENOMEM;
>>>+ }
>>>+
>>>+ newskb->sk = skb->sk;
>>>+ newskb->ip_summed = CHECKSUM_UNNECESSARY;
>>>+ newskb->pkt_type = PACKET_BROADCAST;
>>>+ netif_rx(newskb);
>>
>>
>>So the intention here is to send the packet to the non-loopback device
>>and manually loop it, which means sending it twice?
>
>
> CAN is a broadcast message network, so every frame should be (usually)
> sent to all receivers, on remote hosts and to all local sockets. If
> the driver for the interface is not able to loop back the frame for
> local delivery, the can_send() function will do this as a fallback.
> For real CAN devices it is preferred that the driver does loopback.
> For vcan it makes no difference where loopback is done. The module
> paramenter for vcan is therefore only useful to test and debug the CAN
> core module. It is nothing a normal user will ever use.
Thanks for the explanation.
>>>+static struct dev_rcv_lists *find_dev_rcv_lists(struct net_device *dev)
>>>+{
>>>+ struct dev_rcv_lists *d;
>>>+ struct hlist_node *n;
>>>+
>>>+ ....
>>>+
>>>+ hlist_for_each_entry(d, n, &rx_dev_list, list) {
>>
>>
>>On the receive path you use RCU, so this should be
>>hlist_for_each_entry_rcu(), no? The bottem half disabling during
>>addition/removal also seems unnecessary, but I might be missing
>>something.
>
>
> find_dev_rcv_lists() is called in one place from can_rcv() with RCU
> lock held, as you write. The other two calls to find_dev_rcv_lists()
> are from can_rx_register/unregister() functions which change the
> receive lists. Therefore, we can't only use RCU but need protection
> against simultanous writes. We do this with the spin_lock_bh(). The
> _bh variant, because can_rcv() runs in interrupt and we need to block
> that. I thought this is pretty standard.
>
> I'll check this again tomorrow, but I have put much time in these
> locking issues already, changed it quite a few times and hoped to have
> got it right finally.
I'm not saying you should use *only* RCU, you need the lock
for additions/removal of course, but since the receive path
doesn't take that lock and relies on RCU, you need to use
the _rcu list walking variant to avoid races with concurrent
list changes.
>>>+ case NETDEV_REGISTER:
>>>+
>>>+ /*
>>>+ * create new dev_rcv_lists for this device
>>>+ *
>>>+ * N.B. zeroing the struct is the correct initialization
>>>+ * for the embedded hlist_head structs.
>>>+ * Another list type, e.g. list_head, would require
>>>+ * explicit initialization.
>>>+ */
>>>+
>>>+ DBG("creating new dev_rcv_lists for %s\n", dev->name);
>>>+
>>>+ d = kzalloc(sizeof(*d),
>>>+ in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
>>
>>
>>netdevice registration should never happen from interrupt handlers.
>
>
> Hm, I seem to remember we had such an occurance with hot-pluggable
> devices, i.e. USB. But I may be wrong. In what context is
> NETDEV_REGISTER called for e.g. USB devices? Can we safely write
> just GFP_KERNEL here?
Yes. register_netdevice() takes the rtnl mutex, so it can only
be used in process context.
>>>+ stattimer.expires = jiffies + HZ;
>>
>>round_jiffies?
>
>
> Yes. We don't depend on exact times relative to module load time, but
> we would like to have the timer expirations 1 second apart. But we
> would still get this with round_jiffies(), right?
I don't think you will get *exactly* one second, but you also have
no guarantee for that now.
>>>+ * proc read functions
>>>+ *
>>>+ * From known use-cases we expect about 10 entries in a receive list to be
>>>+ * printed in the proc_fs. So PAGE_SIZE is definitely enough space here.
>>
>>
>>Would be nicer to use seq_file (for all the proc stuff).
>
>
> That has already been on my TODO list. There was some problem which I
> don't remember ATM, which is why I dropped it temporarily. Now on my
> TODO list again.
Thanks :)
next prev parent reply other threads:[~2007-09-19 8:34 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 10:03 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #6 Urs Thuermann
2007-09-17 10:03 ` [PATCH 1/7] CAN: Allocate protocol numbers for PF_CAN Urs Thuermann
2007-09-18 13:31 ` Patrick McHardy
2007-09-17 10:03 ` [PATCH 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-09-17 15:50 ` Paul E. McKenney
2007-09-18 13:31 ` Patrick McHardy
2007-09-18 14:54 ` Urs Thuermann
2007-09-18 15:07 ` Patrick McHardy
2007-09-18 21:20 ` Urs Thuermann
2007-09-19 8:27 ` Patrick McHardy [this message]
2007-09-20 8:53 ` Urs Thuermann
2007-09-20 10:33 ` Patrick McHardy
2007-09-20 11:30 ` Urs Thuermann
2007-09-20 11:43 ` Patrick McHardy
2007-09-17 10:03 ` [PATCH 3/7] CAN: Add raw protocol Urs Thuermann
2007-09-18 14:13 ` Patrick McHardy
2007-09-18 21:49 ` Urs Thuermann
2007-09-19 8:34 ` Patrick McHardy
2007-09-17 10:03 ` [PATCH 4/7] CAN: Add broadcast manager (bcm) protocol Urs Thuermann
2007-09-17 10:03 ` [PATCH 5/7] CAN: Add virtual CAN netdevice driver Urs Thuermann
2007-09-18 15:02 ` Patrick McHardy
2007-09-18 22:24 ` Urs Thuermann
2007-09-19 6:26 ` Oliver Hartkopp
2007-09-19 8:41 ` Patrick McHardy
2007-09-17 10:03 ` [PATCH 6/7] CAN: Add maintainer entries Urs Thuermann
2007-09-17 10:03 ` [PATCH 7/7] CAN: Add documentation Urs Thuermann
2007-09-17 17:30 ` Randy Dunlap
2007-09-17 20:22 ` Urs Thuermann
2007-09-17 20:37 ` Thomas Gleixner
2007-09-17 20:49 ` Urs Thuermann
2007-09-17 22:57 ` Randy Dunlap
2007-09-17 23:19 ` Urs Thuermann
2007-09-18 6:51 ` Bill Fink
2007-09-18 7:20 ` Urs Thuermann
-- strict thread matches above, loose matches on Subject: below --
2007-11-16 15:02 [PATCH 0/7] CAN: New PF_CAN protocol family for 2.6.25, update Urs Thuermann
2007-11-16 15:02 ` [PATCH 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-11-14 12:13 [PATCH 0/7] CAN: New PF_CAN protocol family for 2.6.25 Urs Thuermann
2007-11-14 12:13 ` [PATCH 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-11-14 21:38 ` Stephen Hemminger
2007-11-15 7:40 ` Oliver Hartkopp
2007-11-15 8:04 ` Joe Perches
2007-11-15 11:51 ` Urs Thuermann
2007-11-15 12:05 ` David Miller
2007-11-15 15:11 ` Sam Ravnborg
2007-11-16 14:33 ` Urs Thuermann
2007-11-16 23:42 ` David Miller
2007-11-15 11:36 ` Urs Thuermann
2007-11-15 15:09 ` Sam Ravnborg
2007-10-05 10:49 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #10 Urs Thuermann
2007-10-05 10:49 ` [PATCH 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-10-02 13:10 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #9 Urs Thuermann
2007-10-02 13:10 ` [PATCH 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-10-02 14:38 ` Arnaldo Carvalho de Melo
2007-10-02 16:09 ` Oliver Hartkopp
2007-10-04 11:51 ` Urs Thuermann
2007-10-04 13:40 ` Arnaldo Carvalho de Melo
2007-09-25 12:20 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #8 Urs Thuermann
2007-09-25 12:20 ` [PATCH 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-09-25 12:41 ` Arnaldo Carvalho de Melo
2007-09-25 13:24 ` Urs Thuermann
2007-09-25 15:33 ` Stephen Hemminger
2007-09-25 21:00 ` Urs Thuermann
2007-09-25 21:07 ` Stephen Hemminger
2007-09-25 21:09 ` David Miller
2007-09-28 16:27 ` Thomas Gleixner
2007-09-28 20:20 ` David Miller
2007-09-28 20:28 ` Thomas Gleixner
2007-09-20 18:43 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #7 Urs Thuermann
2007-09-20 18:43 ` [PATCH 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-09-20 20:06 ` Joe Perches
2007-09-20 20:27 ` Thomas Gleixner
2007-09-21 10:35 ` Urs Thuermann
2007-09-21 16:58 ` Joe Perches
2007-09-24 19:23 ` Urs Thuermann
2007-09-21 12:47 ` Patrick McHardy
2007-09-21 18:01 ` Urs Thuermann
2007-09-22 10:53 ` Patrick McHardy
2007-08-04 2:06 [patch 0/7] CAN: Add new PF_CAN protocol family, try #5 Urs Thuermann
2007-08-04 2:06 ` [patch 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-06-22 3:44 [patch 0/7] CAN: Add new PF_CAN protocol family, try #3 Urs Thuermann
2007-06-22 3:44 ` [patch 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-05-30 13:11 [patch 0/7] CAN: Add new PF_CAN protocol family, update Urs Thuermann
2007-05-30 13:11 ` [patch 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-05-16 14:51 [patch 0/7] CAN: Add new PF_CAN protocol family Urs Thuermann
2007-05-16 14:51 ` [patch 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-05-16 16:35 ` Arnaldo Carvalho de Melo
2007-05-16 19:14 ` Urs Thuermann
2007-05-16 20:51 ` Arnaldo Carvalho de Melo
2007-05-18 0:59 ` Paul E. McKenney
2007-05-18 9:19 ` Oliver Hartkopp
2007-05-18 14:33 ` Paul E. McKenney
2007-05-18 15:03 ` Oliver Hartkopp
2007-05-18 21:06 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46F0DD8E.8070808@trash.net \
--to=kaber@trash$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=oliver.hartkopp@volkswagen$(echo .)de \
--cc=oliver@hartkopp$(echo .)net \
--cc=tglx@linutronix$(echo .)de \
--cc=urs@isnogud$(echo .)escape.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox