Hello everyone,
I am writing a "network analyser" system in kernel space, which is
designed to work in SMP platforms. The main idea is to capture and
analyse the packets in kernel space without the need to context-switch
to user space. I am using Linux 2.6.13 and network drivers with NAPI
enabled.
To do this, I need to switch on/off promiscuity on a net_device. There
is a function for that: dev_set_promiscuity() but it does no locking.
As I have read in net/core/dev.c there are two "locks" related to
devices: rtnl semaphore and dev_base_lock reader/writer spinlock. The
comments explain that if you are going to write you should take rtnl
semaphore to protect against other writers and take dev_base_lock for
writing whenever you write, to protect against other readers. Thus,
readers can access almost all the time to device information.
This is theory, but as i have seen in real code, they do not use them
like this. Specifically, in dev_ioctl(), where you may get or change
network device flags, they do this:
case SIOCGIFFLAGS: (get flags, so read)
read_lock(&dev_base_lock);
ret = dev_ifsioc(&ifr, cmd); /* here they read the flags */
read_unlock(&dev_base_lock);
...
case SIOCSIFFLAGS:
rtnl_lock();
ret = dev_ifsioc(&ifr, cmd); /* here they write the new flags */
rtnl_unlock();
In dev_ifsioc() there is no new locking. It gets or changes the flags,
depending the case. Now, why there is no call to write_lock()? The
comments in net/core/dev.c suggest that you should take the spinlock
for writing, but they dont do that. As far as I see in the code (may
be I miss something). If one takes the rtnl semaphore for writing and
changes device specific info, and in parallel another thread is
reading that (for which he has got the dev_base_lock for reading) he
would receive incorrect info, because the writer hasn't acquired the
spin_lock.
Anybody can help me? Here is the redirection to the comments in /net/core/dev.c:
http://lxr.linux.no/source/net/core/dev.c#L167
Thank you!
Aritz Bastida
P.S. By the way, this is my first mail in the forum. Make any
suggestion if i didnt
expose the problem properly :)
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
