On Fri, 2012-09-28 at 12:47 -0700, Bing Zhao wrote:
> > Here, you could just pass "jiffies - SCAN_RESULT_EXPIRE" as the maxage
> > and get pretty much the same behaviour as before without a second
> > parameter.
>
> __cfg80211_bss_expire(dev, jiffies - IEEE80211_SCAN_RESULT_EXPIRE);
>
> This is similar to the code in v1 (below):
>
> __cfg80211_bss_expire(rdev, jiffies - request->scan_start);
Well, they look similar, but these are different calculations. The first
yields an absolute time, while the second yields a relative time. With
these, say we call them T_abs and T_rel, you'd do the following
comparisons
remove = (timestamp < T_abs)
or
remove = (timestamp < jiffies - T_rel)
respectively. The "problem" that I pointed out is that in the latter
case jiffies keeps running, so you would really have (resolving T_rel)
remove = (timestamp < jiffies_1 - (jiffies_2 - scan_start))
= (timestamp < jiffies_1 - jiffies_2 + scan_start)
when you really want
remove = timestamp < scan_start
If jiffies_1 == jiffies_2, then the two are the same, obviously, but
since you're doing calculations against a running counter it's not
guaranteed. With the absolute timestamp based calculations (T_abs above)
you don't run into that problem.
> It may still have the small race condition you commented in v1?
> Please let me know if I misunderstood it.
Well I should also say that the race condition is really fairly
theoretical, unless you have a very small HZ and calculate T_rel just
before the roll-over, in which case jiffies_1 and jiffies_2 above could
actually differ by a fair amount (tens of milliseconds in wall time.)
Regardless, I think if we're going to have absolute time here in any way
(today we only have relative time for age-based expiry) we should do
calculations and comparisons in absolute rather than relative time.
Hth!
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
