netdev - Re: [PATCH 1/2] mac802154: add a software MAC 802.15.4 implementation

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: <1250023198.13529.69.camel@johannes.local>
Date:	Tue, 11 Aug 2009 22:39:58 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>
Cc:	netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
	Sergey Lapin <slapin@...fans.org>
Subject: Re: [PATCH 1/2] mac802154: add a software MAC 802.15.4
 implementation

On Wed, 2009-08-12 at 00:23 +0400, Dmitry Eremin-Solenikov wrote:

> > That return value is strange.
> 
> The idea is that tx function can return info about errors during
> transmit (busy channel, no ACK, etc).

Well, TX functions don't usually wait for anything so busy channel or no
ack wouldn't be possible to return there but more like a TX status, and
I think people are more used to NETDEV_TX_OK etc. return values. But
it's your choice to make, obviously. If you want to return specific
information like that though I would recommend making an enum so you get
at least some type checking (and things like 'return -1' are more
obviously wrong).

> > We've had no end to trouble with the master netdev, I suggest you look
> > into the current mac80211 code and see if you can get rid of it.
> 
> What troubles w/ master netdev did you have had? I do still see the
> master devices in mac80211. IIUC, it's planned to replace (from
> management point of view) the mdev with wiphy instance, isn't it?

Mostly the userspace API was a mess, and you can't actually _do_
anything with the master netdev. It also doesn't see all the frames,
only outgoing. It's very strange.

Yes, you still see it in the current tree, but it's gone in our -next
tree.

The biggest problem is that it really clutters up the userspace API
since you can't do any netdev things with it, it's just a placeholder.

In addition to that, you can't put anything into skb->cb, then push the
frame to the master netdev, and expect things in skb->cb to still be
there when the frame arrives at the master netdev. Not sure you do that
(I hope not because that would be very buggy), but eventually you'll
probably find that you do want that, etc.

IMHO it's just better practise to not use it in situations like this
where it can't be really used as a netdev.

> Hmm. I thought that one may be able to rmmod the module w/ ops while the
> device is still hanging in the system. On the other hand, ops are
> provided by the driver, so if one rmmods the driver and the device is
> still there, it's a bug...

Exactly. You _want_ to be able to rmmod the module and have it
unregister itself.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)