Re: mac80211 truesize bugs

quoted

Why don't we update the socket allocation when doing pskb_expand_head()?
Sure, it could become negative, but is that so bad?

The socket locked state at this time is variable and unknown.

The socket must be locked in order to modify these values.
And such locks cannot be taken, for example, from HW interrupt
context, amongst other restrictions.

Ok, that makes sense.

quoted

We need more space though. Should we then just increase the built-in
headroom?

I simply don't know what to suggest at this point, that's why
we are having this discussion :-)

I'm still not sure about the dependencies between LL_MAX_HEADER,
dev->hard_header_len and similar. Why, for example, does ipip set it to
LL_MAX_HEADER + sizeof(struct iphdr)? Because it doesn't know better
since the packets it creates could be routed anywhere?

Could mac80211 announce it needs a very long hard_header_len (say 48 (or
54) bytes)? Am I right in thinking that then we'd have to increase
LL_MAX_HEADER as well? I haven't found a check somewhere that warns you
if you set dev->hard_header_len > LL_MAX_HEADER, should there be one?

If I increase dev->hard_header_len, will that have any negative impact
on the caching since I'm still just using regular ethernet headers?


As far as I understand we have a few options:

 (a) go along with it as we do now, use pskb_expand_head, just call
     skb_orphan before. I assume this has a number of requirements just
     like sock size accounting would have, does this work from within a
     hard_start_xmit path? I haven't seen any problems with it so far
     anyway.
 (b) clone the skb and free the original. pretty much equivalent
 (c) increase hard_header_len/LL_MAX_HEADER constants to 48 (54).

Options (a) and (b) make the accounting pretty useless since that would
drop the charge to the socket quite early. (c) doesn't seem to work, I
tried just increasing LL_MAX_HEADER doesn't seem to help although
MAX_TCP_HEADER suggests it should be getting enough headroom then.

Ideally, we'd have enough headroom in the skb to start with, since right
now we're apparently reallocating a lot, especially encrypted frames.
Not that I understand why we don't get a truesize bug (without the
monitors) when we do that.

With smart hardware like b43 we could even think about putting the
802.11 header stuff into a separate buffer and have the hardware to
gather-dma but there are so many dumb usb devices that this won't help
much anyway.

johannes