Re: p54usb kernel panic on recent mainline kernels

[Christian Lamparter <chunkeey@googlemail.com>]

[Readded Larry to the CC]

On Saturday, December 27, 2014 12:15:58 AM Christopher Chavez wrote:
> > My bisection led to a branch commit d17ec4d as the "bad" commit. 
> > Rather than finding out where the bisection went bad, I added 
> > code to check skb->tail, skb->end, and the length to be added.
> > At the time of the call that panics, there are 6 bytes between
> > tail and end with 8 bytes needed.
> >
> > I will be looking for the place where the driver calculates how
> > large the skb should be.

I think this narrows it down. However, I'm not 100% sure yet if the
problem is just because of "mac80211: don't resize skbs needlessly".

>From looking at a other patch from that time and context. I think: "

commit ca34e3b5c808385b175650605faa29e71e91991b
Author: Ido Yariv <ido@wizery.com>
Date:   Tue Jul 29 15:38:53 2014 +0300

    mac80211: Fix accounting of the tailroom-needed counter [1]
    
    When hw acceleration is enabled, the GENERATE_IV or PUT_IV_SPACE flags
    will only require headroom space. Consequently, the tailroom-needed
    counter can safely be decremented."

changed/broke things for p54* (note: cw1200 could be affected as well?
This driver also modifies the tailroom for skbs in cw1200_tx_h_crypt).
Previously, the driver didn't need to manage the tailroom. If the 
IEEE80211_KEY_FLAG_GENERATE_IV flag was set, mac80211 would take care of
resizing the skb at the right time and just in one place [of course the
downside was that mac80211 did the resize needlessly].

I can think of several ways of dealing with this issue:

 1. move the expand and trim tailroom into the driver.
    AFAICT this would add an additional resize [at a bad time].

 2. add extra IEEE80211_KEY_FLAG_ or HW_FLAG to restore the old behavior.
    This should be possible and relatively simple. But we/I have to be
    especially careful to differentiate properly between the old and new.
    [i.e.: I need to know what the deal is behind: 
    IEEE80211_KEY_FLAG_GENERATE_IV_MGMT in this case? Looks like it can
    be ignored?]

 3. suggestions?
    [No, I'm not going to touch crypto_tx_tailroom_needed_cnt outside of
    mac80211 :D]

Regards,
Christian

[1] <http://www.spinics.net/lists/linux-wireless/msg125374.html>