From: Johannes Berg <johannes@sipsolutions.net>
To: Vivek Natarajan <vivek.natraj@gmail.com>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] mac80211: Fix a race on enabling power save.
Date: Tue, 15 Feb 2011 13:44:18 +0100 [thread overview]
Message-ID: <1297773858.3935.13.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <AANLkTi=eJf+ge7_w1-r1hmZE0aaPzm_NP-Y-v81uctXG@mail.gmail.com>
On Tue, 2011-02-08 at 15:43 +0530, Vivek Natarajan wrote:
> > Maybe the subif queues should be stopped, then flush, then tx nullfunc,
> > then stop all queues to configure the HW or something like that?
>
> I tried this sequence:
> the subif queues stopped, then flush, then tx nullfunc, and wake subif
> queues,(we cannot have the queues stopped till we receive tx_status
> because nullfunc might have failed during tx path itself and mac80211
> will not receive tx_status)
I've recently been thinking about this -- I'm thinking that maybe we
should change this behaviour. Right now the tx() routine basically
always returns OK (except in at76) and I suppose instead it could return
whether the frame was queued up successfully...
> After some time interval, once again stop queues on receiving ack for
> nullfunc, configure the hw and then wake up queues. So, during the
> above time interval, there is a race of queuing a frame to the hw. I
> have tested this and the issue is quickly reproducible.
Right. The code that sends the nullfunc -- I think it can probably
sleep? If so, instead of starting the queue for the TX it could just
flush TX again after sending the nullfunc -- after that either it had
status for the frame, or the frame was dropped, no?
johannes
next prev parent reply other threads:[~2011-02-15 12:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-04 12:25 [PATCH v2] mac80211: Fix a race on enabling power save Vivek Natarajan
2011-02-04 13:05 ` Johannes Berg
2011-02-04 13:07 ` Johannes Berg
2011-02-04 13:08 ` Johannes Berg
2011-02-04 13:12 ` Johannes Berg
2011-02-04 13:28 ` Vivek Natarajan
2011-02-04 14:08 ` Johannes Berg
2011-02-04 14:28 ` Vivek Natarajan
2011-02-15 14:28 ` Vivek Natarajan
2011-02-08 10:13 ` Vivek Natarajan
2011-02-15 12:44 ` Johannes Berg [this message]
2011-02-15 14:04 ` Vivek Natarajan
2011-02-15 14:09 ` Johannes Berg
2011-02-15 14:41 ` Vivek Natarajan
2011-02-16 9:31 ` Vivek Natarajan
2011-02-16 11:11 ` Johannes Berg
2011-02-16 12:28 ` Vivek Natarajan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1297773858.3935.13.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=vivek.natraj@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.