From: Denis Kenzior <denkenz@gmail.com>
To: James Prestwood <prestwoj@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH v3] offchannel: handle out of order ACKs/events
Date: Thu, 26 Oct 2023 09:32:22 -0500 [thread overview]
Message-ID: <e8833170-5df6-47e3-91a3-3e991cc7358a@gmail.com> (raw)
In-Reply-To: <20231025175639.262390-1-prestwoj@gmail.com>
Hi James,
On 10/25/23 12:56, James Prestwood wrote:
> Its been seen (so far only in mac80211_hwsim + UML) where an
> offchannel requests ACK comes after the ROC started event. This
> causes the ROC started event to never call back to notify since
> info->roc_cookie is unset and it appears to be coming from an
> external process.
>
> We can detect this situation in the ROC notify event by checking
> if there is a pending ROC command and if info->roc_cookie does
> not match. This can also be true for an external event so we just
> set a new "early_cookie" member and return.
>
> Then, when the ACK comes in for the ROC request, we can validate
> if the prior event was associated with IWD or some external
> process. If it was from IWD call the started callback, otherwise
> the ROC notify event should come later and handled under the
> normal logic where the cookies match.
> ---
> src/offchannel.c | 58 +++++++++++++++++++++++++++++++++++-------------
> 1 file changed, 43 insertions(+), 15 deletions(-)
>
> v3:
> * Handle the various cases in a for loop rather than two separate
> lookups
> * Fix incorrect comment about the request not hitting the kernel
> * For the "normal" case I didn't bother checking
> info->roc_cmd_id == 0 as you suggested since this _should_ always
> be true if the cookies matched. Adding that check shouldn't cause
> any issues but it just looked wrong:
>
> if (i->roc_cookie == cookie && i->roc_cmd_id == 0) {
> info = i;
> break;
> }
>
> // It would _appear_ we could reach this point with the cookies
> // matching but have not found the info object (which is
> // impossible, I know). Its up to you and doesn't functionally
> // matter either way, but this makes more sense when visually
> // inspecting the code IMO.
>
Applied, thanks.
Regards,
-Denis
prev parent reply other threads:[~2023-10-26 14:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 17:56 [PATCH v3] offchannel: handle out of order ACKs/events James Prestwood
2023-10-26 14:32 ` Denis Kenzior [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e8833170-5df6-47e3-91a3-3e991cc7358a@gmail.com \
--to=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=prestwoj@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).