panic when calling drv_get_tsf

Dear all,

I'm having some issues in a modified version of mac80211, which I hope you will help me with.
I want to report a lower bound of the channel utilization to which a mesh device is tuned in for a research project. So far, I can read successfully from debugfs this new statistic updated periodically, targeting mesh interfaces and tested only with atheros cards. However, I would like to improve it as I describe at the end. The strategy is to keep adding the rx and tx used time until a [mesh] beacon is sent, and then, trigger a custom function that derives the utilization for that given interval. This one reads the elapsed time since the previous beacon (should be 1000 TU in mesh mode) and resets the counters. Caller function:

    --- tx.c ---
    struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
                                             struct ieee80211_vif *vif,
                                             u16 *tim_offset, u16
    *tim_length)
    {
            struct ieee80211_local *local = hw_to_local(hw);
    ...

            rcu_read_lock();
            sdata = vif_to_sdata(vif);
    ...

     out:
            rcu_read_unlock();       

            /* HERE */
            my_function(local, sdata->name, sdata);

            return skb;
    }

My function. Note that I've modified ieee80211_local to share data between "rx", "tx status" and "beacon tx" contexts. The line comments fix the error.

    --- tx.c ---
    static void my_function(struct ieee80211_local *local, char
    *if_name, struct ieee80211_sub_if_data *sdata){
            u64 beacon_interval = 1000 * 1024 // 1.024 seconds.
            /* Retrieve counters and add them up */

            /* ↓ KERNEL PANIC HERE ↓ */
            // current_tsf = drv_get_tsf(local, sdata);
            // beacon_interval = current_tsf -
    local->ch_load.last_tsf_channel_load_update;

            rem = do_div(total_used_time, beacon_interval); // compute
    utilization

            /* do some averaging and save */
            /* reset counters */
    }

So firstly, why can't I call drv_get_tsf from there? Is it because TSF is exactly then being reset? Secondly, I feel unsafe about synchronization. Should I rcu-protect all operations on ieee80211_sub_if_data, ieee80211_hw and sk_buff? Worker functions on rx.c and status.c do read values from those structures.

Finally, I would be interested on using TSF to measure the time passed since a packet is scheduled to transmit in tx.c and its report is received at status.c. Do you think that TSF be usable for this?

Thanks for your help!
Ferran

You left out posting the actual panic/warning you got, but one possibility is beacon_get is called under a lock that the driver also takes inside drv_get_tsf(). Usually this function just reads a register so it's unlikely that reading the tsf itself during an update will give any troubles (other than wrong values).

I am not sure what you want to do, but some things to think about regarding TSF:

- reading the TSF from the driver with drv_get_tsf() will give you something that may or may not be usable. For example, depending on calling context, the process that reads the TSF might get scheduled out for an unknown amount of time between when you read it and when you use it.

- in mesh, the TSF changes as the network operates. The stations try to adjust their clocks so that their timing offsets are synchronized (making it possible to know a neighbor's TBTT).

Bob Copeland %% www.bobcopeland.com

Qm9iIENvcGVsYW5kIDxtZUAuLi4+IHdyaXRlczoKCgpIaSBCb2IsCgpUaGFuayB5b3UgZm9yIGNvbnRyaWJ1dGluZyBhbmQgc3VwcG9ydGluZyBzbyBhY3RpdmVseSB0aGUgbWVzaCBkZXZlbG9wbWVudC4KSSB1bmRlcnN0b29kIHRoZSBpc3N1ZXMgd2l0aCBUU0YsIHNvIEkgc3RvcHBlZCB1c2luZyBpdC4KCk15IGFpbSBpcyB0byBhcHByb3hpbWF0ZSBob3cgbXVjaCB0aW1lIHRoZSB3aXJlbGVzcyBjaGFubmVsIHRvIHdoaWNoIHRoZQpjYXJkIGlzIHR1bmVkIGluLCBpcyBidXN5LiBJIHVzZSBpZWVlODAyMTFfZnJhbWVfZHVyYXRpb24gZm9yIGVhY2gKaW4vb3V0Y29taW5nIHBhY2tldC4gSSB1c2UgdGhlIGJlYWNvbiB0cmlnZ2VycyBmb3IgcGVyaW9kaWNhbGx5IGF2ZXJhZ2luZwphbmQgc3RvcmluZyBzYW1wbGVzLgoKSSB3b3JrZWQgYXJvdW5kIHRoYXQgZXJyb3IgYXNzdW1pbmcgYSBmaXhlZCBiZWFjb24gdGltZSBpbnRlcnZhbCBpbnN0ZWFkIG9mCnVzaW5nIFRTRiwgd2hpY2ggaXMgcHJldHR5IHNvbGlkIGluIGEgY29udHJvbGxlZCBlbnZpcm9ubWVudC4gSG93ZXZlciwgdGhlCmFwcHJveGltYXRpb24gd291bGQgaW1wcm92ZSBhIGxvdCBjb3VudGluZyB0aGUgdXNlZCB0aW1lIGluc3RlYWQgb2YKY29tcHV0aW5nIGl0IGFmdGVyd2FyZHMuCgpQdXJzdWluZyBhIHNpbWlsYXIgcHVycG9zZSwgc29tZWJvZHkgaGFzIGFscmVhZHkgaW1wbGVtZW50ZWQgdGhhdCBmb3IKQXRoZXJvcywgdXNpbmcga2VybmVsIHRpbWUgYW5kIHJlYWRpbmcgcmVnaXN0ZXJzLiBIZXJlIGlzIHRoZSBwcmVzZW50YXRpb24KbWFpbCBodHRwczovL2xpc3RzLmF0aDlrLm9yZy9waXBlcm1haWwvYXRoOWstZGV2ZWwvMjAxNS1BdWd1c3QvMDE0MTQxLmh0bWwKYW5kIHRoZSBwcm9qZWN0IGxpbmsgaHR0cHM6Ly9naXRodWIuY29tL3RodWVobi9SZWdNb24gLiBUaGUgYXV0aG9yIGlzCkRyLi1JbmcuIFRob21hcyBIw7xobi4KCkkgcGxhbiB0byB1c2UgaXQgaW4gdGhlIG1pZCBmdXR1cmUuCgpUaGFuayB5b3UsCkZlcnJhbg==