netdev - Re: [PATCH] zd1211rw: Support for multicast addresses

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

Message-ID: <20061201062758.GA20548@p15091797.pureserver.info>
Date:	Fri, 1 Dec 2006 07:27:59 +0100
From:	Ulrich Kunitz <kune@...ne-taler.de>
To:	Daniel Drake <dsd@...too.org>
Cc:	Stephen Hemminger <shemminger@...l.org>, linville@...driver.com,
	netdev@...r.kernel.org, benoit.papillault@...e.fr
Subject: Re: [PATCH] zd1211rw: Support for multicast addresses

On 06-11-30 20:57 Daniel Drake wrote:

> Stephen Hemminger wrote:
> >Why all the trouble do it off work queue? Is someone calling
> >set_multicast_list with IRQ's disabled?
> 
> Register I/O involves sleeping, so we need to be in process context.
> 
> in_atomic() returns non-zero in the set_multicast_list handler. I 
> couldn't tell you which codepath this is in.
> 
> Daniel

The function dev_mc_upload() (net/core/dev_mcast.c) calls
netif_tx_lock_bh() which locks the tx spinlock.

The ZD1211 is a USB chip. Register reads will always require
sleeping, if the driver should not spend CPU cycles on polling in
atomic mode. One could implement register writes without waiting
for completion of the writes, but asynchronous error messages for
the writes would make debugging difficult. Additionally hardware
register accesses includes setting a firmware lock, which reqires
a register read. Given all that the driver is always sleeping in
the register access paths. RX and TX paths don't require register
access and work in atomic mode. 

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