All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Masashi Honma <masashi.honma@gmail.com>
Cc: linux-wireless@vger.kernel.org, me@bobcopeland.com
Subject: Re: [PATCH v3] mac80211: Avoid STA expiration timer truncation to u32
Date: Fri, 23 Jan 2015 10:42:54 +0100	[thread overview]
Message-ID: <1422006174.2728.12.camel@sipsolutions.net> (raw)
In-Reply-To: <1421722023-4691-1-git-send-email-masashi.honma@gmail.com> (sfid-20150120_034734_203758_428E04AE)

On Tue, 2015-01-20 at 11:47 +0900, Masashi Honma wrote:
> On some combination of plink_timeout and HZ, the STA expiration timer will be
> unexpectedly truncated to u32. Maybe there is a question "Who sets such a large
> number to plink_timeout ?". At least wpa_supplicant will set 0xffffffff to
> plink_timeout to disable this timer because wpa_supplicant has it's own
> expiration mechanism.

Ok - but that doesn't really disable the timer? Perhaps we should have a
new userspace API to explicitly disable it? OTOH, worst case I guess
that means it's like >100 years in the future, so I guess it doesn't
matter. However, though, you can hardly rely on this fix being present
in the kernel, so you can't really set such a large value
unconditionally anyway, no? Otherwise a newer wpa_supplicant running on
an older kernel would suddenly behave incorrectly. That doesn't seem
right.

Having an explicit feature to disable plink timeout would perhaps be
better?

> --- a/net/mac80211/mesh.c
> +++ b/net/mac80211/mesh.c
> @@ -573,8 +573,11 @@ static void ieee80211_mesh_housekeeping(struct ieee80211_sub_if_data *sdata)
>  {
>  	struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
>  	u32 changed;
> +	u64 exp_time;
>  
> -	ieee80211_sta_expire(sdata, ifmsh->mshcfg.plink_timeout * HZ);
> +	exp_time = ifmsh->mshcfg.plink_timeout * (u64)HZ;
> +	if (exp_time < 0x100000000)
> +		ieee80211_sta_expire(sdata, exp_time);

I'm not convinced this is right. For one, I believe on 32-bit machines
you'll need to write "0x100000000ULL" instead of the plain constant.
Perhaps preferably, you'd use use ">= MAX_UINT".

However, the argument to ieee80211_sta_expire() is an unsigned long (as
is jiffies), so on 64-bit machines you could even still use the value
and the conditional isn't needed.

Given these complications, I would prefer having a feature attribute to
treat e.g. 0 as disabling the timer entirely, and if this feature isn't
present then have wpa_supplicant instead use a safe value that doesn't
trigger the kernel bug - e.g. 0xffffffff/1000 [which is the max possible
HZ].

johannes


  reply	other threads:[~2015-01-23  9:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16  5:17 [PATCH] mesh: Avoid STA expiration timer truncation to u32 Masashi Honma
2015-01-16  5:49 ` Kalle Valo
2015-01-16  6:12   ` Masashi Honma
2015-01-16  6:18     ` [PATCH v2] mac80211: " Masashi Honma
2015-01-16 13:31       ` Bob Copeland
2015-01-20  2:44         ` Masashi Honma
2015-01-20  2:47           ` [PATCH v3] " Masashi Honma
2015-01-23  9:42             ` Johannes Berg [this message]
2015-01-23 14:27               ` Masashi Honma
2015-02-04  2:22                 ` [PATCH v4] mac80211: Allow 0 for NL80211_MESHCONF_PLINK_TIMEOUT to disable STA expiration Masashi Honma
2015-02-24  9:46                   ` Johannes Berg
     [not found]                     ` <CAFk-A4nyEvsaCah97ohnbLW7a0+GRbnuJGLyFkBLbpWVffn85w@mail.gmail.com>
2015-02-24 10:03                       ` Fwd: " Masashi Honma
2015-02-24 13:42                         ` [PATCH v5] " Masashi Honma
2015-02-24 20:08                           ` Johannes Berg
2015-02-24 23:24                             ` Masashi Honma

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=1422006174.2728.12.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=masashi.honma@gmail.com \
    --cc=me@bobcopeland.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.