lkml.org 
[lkml]   [2019]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 4.19 044/321] mac80211: fix station inactive_time shortly after boot
On Wed, 4 Dec 2019 at 14:05, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Wed, 2019-12-04 at 11:56 +0000, Pavel Machek wrote:
>
> > > - if (time_after(stats->last_rx, sta->status_stats.last_ack))
> > > + if (!sta->status_stats.last_ack ||
> > > + time_after(stats->last_rx, sta->status_stats.last_ack))
> > > return stats->last_rx;
> > > return sta->status_stats.last_ack;
> > > }
> >
> > I mean, jiffies do wrapraound periodically, so eventually we'll have
> > sta->status_stats.last_ack == 0 even through it is not short after
> > boot, no?
>
> Yeah. I contemplated that when I applied the original patch - it's a bit
> complicated otherwise, you have to track "is this valid" etc.
>
> Since this is updated on pretty much every frame, it's highly unlikely
> you'll go without the value for long, so I figured this was good enough.
>
> johannes
>

That happened when I was testing an IBSS network, so a unit would have
last_ack = 0
for some neighbours for extended period of time, but last_rx was
always valid (from
broadcasts and beacons I guess). In this case, it makes sense to use
last_rx, no matter
jiffies had wrapped around or not.

For STA/AP situations, last_ack should pretty much be valid and non-zero.

Ahmed

\
 
 \ /
  Last update: 2019-12-04 13:27    [W:0.272 / U:3.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site