When iwl_txq_update_write_ptr fails, you have a huge problem: the skb is
linked on the queue, the write_ptr has been incremented, but you pretend
you can just free it.
johannes
On Fri, Oct 10, 2008 at 3:27 PM, Johannes Berg
<[email protected]> wrote:
> On Fri, 2008-10-10 at 14:20 +0200, Tomas Winkler wrote:
>> On Thu, Oct 9, 2008 at 11:04 AM, Johannes Berg
>> <[email protected]> wrote:
>> > When iwl_txq_update_write_ptr fails, you have a huge problem: the skb is
>> > linked on the queue, the write_ptr has been incremented, but you pretend
>> > you can just free it.
>>
>> It's not freed it's should be picket in the next round. We should
>> really return success to mac80211 in case
>
> No, it _is_ freed, by the caller, because you always return success to
> mac80211 anyway and kfree the skb before. And if you didn't return
> success it'd be just as wrong.
Yes I know, as I said we should return success there.
Tomas
On Fri, 2008-10-10 at 14:20 +0200, Tomas Winkler wrote:
> On Thu, Oct 9, 2008 at 11:04 AM, Johannes Berg
> <[email protected]> wrote:
> > When iwl_txq_update_write_ptr fails, you have a huge problem: the skb is
> > linked on the queue, the write_ptr has been incremented, but you pretend
> > you can just free it.
>
> It's not freed it's should be picket in the next round. We should
> really return success to mac80211 in case
No, it _is_ freed, by the caller, because you always return success to
mac80211 anyway and kfree the skb before. And if you didn't return
success it'd be just as wrong.
johannes
On Thu, Oct 9, 2008 at 11:04 AM, Johannes Berg
<[email protected]> wrote:
> When iwl_txq_update_write_ptr fails, you have a huge problem: the skb is
> linked on the queue, the write_ptr has been incremented, but you pretend
> you can just free it.
It's not freed it's should be picket in the next round. We should
really return success to mac80211 in case
HW is not awake which is only sound reason it will fail.
Thanks
Tomas