Re: Flush scan list on resume

[Dan Williams <dcbw redhat com>]

On Wed, 2009-02-04 at 15:40 -0800, Howard Chu wrote:
> Dan Williams wrote:
> > On Wed, 2009-02-04 at 18:04 -0500, Tony Espy wrote:
> >> Dan Williams wrote:
> >>> So here's why old access points show up after resume...
> >>>
> >>> Executive summary: exclusively a *driver* problem
> >>>
> >>>
> >>> Detailed explanation:
> >>>
> >>> Most kernel drivers use 'jiffies' as the timestamp for each scan result.
> >>> jiffies is a kernel counter that counts *while the kernel is alive*, and
> >>> thus does not reflect time spent in suspend and hibernate.
> >>>
> >>> When the supplicant requests scan results from the driver on resume, the
> >>> supplicant (and NM) gets back a list of scan results with recent-looking
> >>> timestamps that do not reflect the time the machine was suspended.
> >>>
> >>> The solutions are to move drivers to using the actual machine clock (the
> >>> kernel equivalent of time(2)) for last_beacon, or to be more agressive
> >>> about expiring entries on resume with something like (10 - time spent in
> >>> sleep).
> 
> OK. Having looked in my wireless-testing tree, I see that most of the drivers 
> are now just allowing mac80211 to handle scanning, so this is not a per-driver 
> issue. At least that makes the scope of fixing easier to manage.
> 
> >> How 'bout getting drivers to add code to their resume functions that
> >> just clears the scan results queue?
> 
> I was actually thinking it makes sense to clear results on suspend, no reason 
> to keep kmem allocated at that point. (No point in saving an obsolete queue on 
> a hibernate, after all.)
> 
> > That's not desirable on mobile platforms like OLPC that do
> > suspend/resume very quickly and very often.  The best mechanism is to
> > make the *actual* last seen time available to the userspace programs
> > that implement the policy (like connection managers) so they can do
> > what's appropriate.
> 
> OK. I suggest a compromise then, since fetching kernel time will also be 
> expensive if done frequently - just fetch it at driver load and resume time, 
> and store it as a <base> in the driver. Cache entries then store base+jiffy. 
> This allows cache stamps to continue to be cheap, but also solves the 
> sleep/resume mismatch.

Yeah, that might work.  Want to whip up a quick patch we can use for
further discussion?

Dan