net_device::destructor patch for brcmfmac

net_device::destructor patch for brcmfmac

[Arend van Spriel]

Hi Kalle,

I have a fix for brcmfmac, which is related to a change Dave made in
struct net_device, ie. commit cf124db566e6 ("net: Fix inconsistent
teardown and release of private netdev state."). This change is not in
wireless-drivers-next, but it is in mac80211-next and thus in
wireless-testing. What should I do? Submit to net-next, or
mac80211-next, or will you merge net-next into wireless-drivers-next?

Regards,
Arend

Re: net_device::destructor patch for brcmfmac

[Johannes Berg]

On Thu, 2017-06-22 at 11:45 +0200, Arend van Spriel wrote:
> Hi Kalle,
> 
> I have a fix for brcmfmac, which is related to a change Dave made in
> struct net_device, ie. commit cf124db566e6 ("net: Fix inconsistent
> teardown and release of private netdev state."). This change is not
> in
> wireless-drivers-next, but it is in mac80211-next and thus in
> wireless-testing. What should I do? Submit to net-next, or
> mac80211-next, or will you merge net-next into wireless-drivers-next?

Actually, it's even in *net* I believe, so you should submit it to
there, or Kalle should integrate (fast-forward, rebase?) that into
wireless-drivers.

johannes

Re: net_device::destructor patch for brcmfmac

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Thu, 2017-06-22 at 11:45 +0200, Arend van Spriel wrote:
>> Hi Kalle,
>> 
>> I have a fix for brcmfmac, which is related to a change Dave made in
>> struct net_device, ie. commit cf124db566e6 ("net: Fix inconsistent
>> teardown and release of private netdev state.").

Is there a report from users or is this more like a theoretical issue?

We are quite late in 4.12 cycle so I would prefer to push this via
wireless-drivers-next and stable tree to 4.12.x, unless it's really
critical of course.

>> This change is not in wireless-drivers-next, but it is in
>> mac80211-next and thus in wireless-testing. What should I do? Submit
>> to net-next, or mac80211-next, or will you merge net-next into
>> wireless-drivers-next?
>
> Actually, it's even in *net* I believe, so you should submit it to
> there, or Kalle should integrate (fast-forward, rebase?) that into
> wireless-drivers.

My plan is to send a pull request to Dave this week still (unless
Midsummer celebrations last too long, knowing Finland's weather that's
unlikely) and I could fast forward then. I have also other patches
waiting for stuff in net-next.

Arend, I think the best is that you use wireless-testing as baseline and
clearly document what commit your patch depends on. Once I have fast
forwarded wireless-drivers-next to latest net-next it _should_ apply
just fine.

-- 
Kalle Valo

Re: net_device::destructor patch for brcmfmac

[Arend van Spriel]

On 22-06-17 12:02, Kalle Valo wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
> 
>> On Thu, 2017-06-22 at 11:45 +0200, Arend van Spriel wrote:
>>> Hi Kalle,
>>>
>>> I have a fix for brcmfmac, which is related to a change Dave made in
>>> struct net_device, ie. commit cf124db566e6 ("net: Fix inconsistent
>>> teardown and release of private netdev state.").
> 
> Is there a report from users or is this more like a theoretical issue?

Well, it a real issue but not reported by users. It only occurs when
register_netdevice() fails which does not happen often enough(?).

> We are quite late in 4.12 cycle so I would prefer to push this via
> wireless-drivers-next and stable tree to 4.12.x, unless it's really
> critical of course.

That was my idea.

>>> This change is not in wireless-drivers-next, but it is in
>>> mac80211-next and thus in wireless-testing. What should I do? Submit
>>> to net-next, or mac80211-next, or will you merge net-next into
>>> wireless-drivers-next?
>>
>> Actually, it's even in *net* I believe, so you should submit it to
>> there, or Kalle should integrate (fast-forward, rebase?) that into
>> wireless-drivers.
> 
> My plan is to send a pull request to Dave this week still (unless
> Midsummer celebrations last too long, knowing Finland's weather that's
> unlikely) and I could fast forward then. I have also other patches
> waiting for stuff in net-next.
> 
> Arend, I think the best is that you use wireless-testing as baseline and
> clearly document what commit your patch depends on. Once I have fast
> forwarded wireless-drivers-next to latest net-next it _should_ apply
> just fine.

That works for me. Thanks,
Arend