netdev - netdev: question on ndo_set_rx

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-next>] [day] [month] [year] [list]

Message-ID: <55FC44CF.8050001@ti.com>
Date:	Fri, 18 Sep 2015 13:07:27 -0400
From:	Murali Karicheri <m-karicheri2@...com>
To:	open list: TI NETCP ETHERNET DRIVER <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>, ;
Subject: netdev: question on ndo_set_rx_mode() API

Hello Netdev experts,

I am seeing an issue with netcp driver that has a mutex lock/unlock() 
call. When kernel hack debug options are enabled, I see a warning that 
this function is taking a mutex that can sleep and is not allowed. I am 
working to fix this. Looking at other drivers, I see many drivers such 
as e1000_main.c are not holding any driver specific lock as part of the 
API implementation. So my first attempt is to remove the mutex. But 
wondering what kind of synchronization is required in this API to run it 
properly on an SMP kernel. Based on my search following files are 
calling dev_change_flags() which in turn calls ndo_set_rx_mode()

Set-1
======
net/ipv4/devinet.c
net/ipv4/ipconfig.c
net/core/dev_ioctl.c

Set-2
=====
net/8021q/vlan.c
net/core/rtnetlink.c

Set-1 seems to call this with rtnl_lock (mutex) held. So there is 
already protection between processes that calls this function and driver 
doesn't need to provide any explicit synchronization. Is this correct?

For Set-2, I can't figure out in what context this is calling this API 
Can someone help me understand this?

However I see below.

Documentation/networking/netdevices.txt explains,

ndo_set_rx_mode:
Synchronization: netif_addr_lock spinlock.
Context: BHs disabled

So is there any synchronization required from the driver perspective? If 
yes, what kind of synchronization is needed? Thanks in advance for your 
response.

-- 
Murali Karicheri
Linux Kernel, Keystone
--
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