linux-kernel - Re: [PATCH 4.19 044/321] mac80211: fix station inactive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANczwAHaRT1=heEamuMiS=6dme4r+P+f7g97Rargn_1rpSCLgg@mail.gmail.com>
Date:   Wed, 4 Dec 2019 14:26:06 +0200
From:   Ahmed Zaki <anzaki@...il.com>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Pavel Machek <pavel@...x.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 044/321] mac80211: fix station inactive_time shortly
 after boot

On Wed, 4 Dec 2019 at 14:05, Johannes Berg <johannes@...solutions.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