Its possible for cfg80211 to have scheduled the work and for the global workqueue to not have kicked in prior to a cfg80211 driver's regulatory hint or wiphy_apply_custom_regulatory(). Although this is very unlikely its possible and should fix this race. When this race would happen you are expected to have hit a null pointer dereference panic. Cc: stable@xxxxxxxxxx Signed-off-by: Luis R. Rodriguez <lrodriguez@xxxxxxxxxxx> --- net/wireless/reg.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 041300e..a5fe1f3 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1554,6 +1554,13 @@ static int regulatory_hint_core(const char *alpha2) queue_regulatory_request(request); + /* + * This ensures last_request is populated once modules + * come swinging in and calling regulatory hints and + * wiphy_apply_custom_regulatory(). + */ + flush_scheduled_work(); + return 0; } -- 1.6.0.6 -- 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
