netdev - Re: [PATCH RFC 08/14] net: wireless: mac80211: shrink ieee80211_tx

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: <20150302190316.GB9762@breakpoint.cc>
Date:	Mon, 2 Mar 2015 20:03:16 +0100
From:	Florian Westphal <fw@...len.de>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Florian Westphal <fw@...len.de>, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: [PATCH RFC 08/14] net: wireless: mac80211: shrink
 ieee80211_tx_info

Johannes Berg <johannes@...solutions.net> wrote:
> On Mon, 2015-03-02 at 18:40 +0100, Florian Westphal wrote:
> > to make it fit into (future) 44-byte sized skb->cb[].
> > 
> > This works, since flags is only used to store values
> > from mac80211_tx_control_flags enum, and these are just 2 bits.
> > We can thus move this to the padding hole inside the union.
> > 
> > Also add BUILD_BUG_ON magic to make sure that the new flags
> > field doesn't share storage w. other members of the union.
> 
> This is really ugly - what's the point of this?

Eventually reducing skb size to make it fit into 3 cachelines again even
on 64bit architectures.  For that 40 bytes need to go.

> Mind you - we are actually acutely out of space and would rather have
> *more*, not less.

:-(

I'm not familiar with mac80211, aside from that it seemed to me
that 40 byte cb would be doable, given enough work.

Where are to main problems, exactly?

I known that pushing something into ->cb is a lot easier than e.g. keeping
extra state on stack, but, IMO cb should really only be used when you
need to associate data strictly with an skb so that this data is still
availabe even when skb gets queued somewehere.

Is there a document somewhere that lists all of the per-skb data that
mac80211 needs to store (or wants to store)?

Thanks,
Florian
--
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