All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob Copeland <me@bobcopeland.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] mac80211: remove ignore_plink_timer flag
Date: Wed, 4 Jun 2014 10:53:53 -0400	[thread overview]
Message-ID: <20140604145353.GA19299@localhost> (raw)
In-Reply-To: <1401890908.6079.32.camel@jlt4.sipsolutions.net>

On Wed, Jun 04, 2014 at 04:08:28PM +0200, Johannes Berg wrote:
> On Wed, 2014-06-04 at 09:27 -0400, Bob Copeland wrote:
> > However, using the mod_timer()/del_timer() return values to
> > detect these cases is broken.  As a result, timers get ignored
> > unnecessarily, and stations can get stuck in the peering state
> > machine.
> > 
> > Instead, we can detect the case by looking at the timer expiration.
> > In the case of del_timer, just ignore the timers in the following
> > (LISTEN/ESTAB) states since they won't have timers anyway.
> 
> I'm not entirely sure about the expiration thing - doesn't seem
> different from the outside flag? But anyway - applied.

Happy to be enlightened -- for what it's worth this is my reasoning:

My understanding of mod_timer() return value is that it just means
the timer was scheduled, not actually running, and the original code
assumed the latter.  So let's say the timer is already scheduled to
happen 5 seconds from now, the old code would do:

lock
/* changing state, timer now reflects a different state timeout */
rv = mod_timer(10 secs from now);
if (rv) /* timer was already scheduled */
   ignore_plink_timer = 1;
unlock

So when the timer runs in 10 seconds it would skip execution even though
the first handler hadn't executed yet.  It got the race case right, but
not the race-free case.

-- 
Bob Copeland %% www.bobcopeland.com

      reply	other threads:[~2014-06-04 14:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-04 13:27 [PATCH] mac80211: remove ignore_plink_timer flag Bob Copeland
2014-06-04 14:08 ` Johannes Berg
2014-06-04 14:53   ` Bob Copeland [this message]

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=20140604145353.GA19299@localhost \
    --to=me@bobcopeland.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /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.