Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Oct 2012 14:11:32 -0700
From:      Adrian Chadd <adrian.chadd@gmail.com>
To:        Monthadar Al Jaberi <monthadar@gmail.com>, freebsd-wireless@freebsd.org
Subject:   Re: remove some KASSERT in net80211?
Message-ID:  <CAJ-VmomUMnsvzhcjAPoOMkAVBpSUJBUBSDLP2eCN-=u1fvFnWA@mail.gmail.com>
In-Reply-To: <CA%2BsBSoJChwmC9Mn_ZVoskNSsj_OhABJufYY5Swy0ZrN_soWRLw@mail.gmail.com>
References:  <CA%2BsBSoLEme7PstVMmVmA-N0sTfxusEV6KKqzQLk0kYP=zJh8-Q@mail.gmail.com> <CAJ-VmomDBANnyruB3tAXb1VmzaP_Eyy2uAubf1=DCC8jckemMg@mail.gmail.com> <CA%2BsBSoJChwmC9Mn_ZVoskNSsj_OhABJufYY5Swy0ZrN_soWRLw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
cc'ing -wireless, as it's a useful discussion

On 21 October 2012 23:27, Monthadar Al Jaberi <monthadar@gmail.com> wrote:
> sorry for the looong delay... :(
>
> generally all packet come trhough ath_rx_pkt() (ath(4)),

Right. And that's a taskqueue.

> then it seems that ieee80211_input_* are not locked. So different
> packets can be handled in the stack the same time? What happens if
> Path Error and Path Reply run at almost the same time? Won't it be
> undefined behavior?

Well, what other RX path is there? It should only be run from the RX
taskqueue on ath(4), and thus serialised.
There's a few corner cases where that isn't true (notably during
reset) which needs to eventually be addressed.

> There is the possibility that a timer get down to zero and invalidate,
> but that timer is 5 s and it gets updated often so I guess this case
> can be ignored.
>
> We can also invalidate route when we receive Peer Close frame.
>
> So is this a question of serializing the stack? or am I missing
> something important?

Well, the RX path is mostly serialised - except for things like
channel scanning and any kind of reset.
Reset now flushes the RX queue and handles whatever frames were there,
but I -believe- I serialised that well enough (reset can't overlap
with RX and another reset in parallel.)

So, why else is this particular assertion being hit? :)


Adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomUMnsvzhcjAPoOMkAVBpSUJBUBSDLP2eCN-=u1fvFnWA>