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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <471DE477E2B1F549A58F3A14A27180BE0147A6@HQ-EX01.bytemobile.com>
Date:	Wed, 21 Mar 2012 20:38:02 +0000
From:	Jeff Haran <jharan@...emobile.com>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: locking in net_device_ops callbacks

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@...tta.com]
> Sent: Wednesday, March 21, 2012 12:25 PM
> To: Jeff Haran
> Cc: netdev@...r.kernel.org
> Subject: Re: locking in net_device_ops callbacks
> 
> On Wed, 21 Mar 2012 18:59:30 +0000
> Jeff Haran <jharan@...emobile.com> wrote:
> 
> > Hi,
> >
> > I had posted the below to the kernelnewbies email list and never got a
> response. I am hoping somebody on this list could provide some feedback.
> >
> > Just to be clear, it's not the issue of copying the MAC address that I am
> asking about. That's just an example.
> >
> > What I am trying to understand is, what mechanisms generally are at play
> to serialize access to struct net_device private data that is accessed in both
> process and softirq contexts? Explicit locking "seems" to be mostly absent
> from the driver sources I've inspected so I can't help but believe I am missing
> something fundamental here.
> 
> Look at rtnl_lock() in net/core/rtnetlink.c; this is global mutex against
> all changes to network device state.

Steve,

Thanks for the response.

rtnl_lock() does this:

void rtnl_lock(void)
{
        mutex_lock(&rtnl_mutex);
}

I can see where that would serialize process context access, but as I understand it much of the networking stack runs in soft IRQ context. Soft IRQs can't take mutexes, can they?

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.

Jeff Haran



--
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