netdev - Re: locking in net_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20120321233720.GA14134@electric-eye.fr.zoreil.com>
Date:	Thu, 22 Mar 2012 00:37:20 +0100
From:	Francois Romieu <romieu@...zoreil.com>
To:	Jeff Haran <jharan@...emobile.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: locking in net_device_ops callbacks

Jeff Haran <jharan@...emobile.com> :
[...]
> It seems to me that some other serialization mechanism should be in place
> to serialize soft IRQ context access to instances of struct net_device.

The driver must implement adequate locking -mostly bh or irq spinlock- if
you want to change the MTU at any time. It is possible to temporarily stop
some bh as well too, see napi_disable for instance.

net_device stats locking is a different beast.

Other than that, some serializing is already done with rules such as
"xmit happens in locally bh disabled context" or through special purpose
lock (think Tx locking).

So, yes, there are some mechanisms. However most drivers only care about
the net_device itself when it goes up or down. As soon as the net_device
is up, it won't change much behind the driver's back (nor should the driver
try to modify it much btw).

-- 
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html