Re: [PATCH v2 1/1] wiphy: fix regdom change wiphy dump logic

[James Prestwood <prestwoj@gmail.com>]

Hi Denis,

On 5/17/23 8:21 PM, Denis Kenzior wrote:
> Hi James,
> 
>>> NAK.  Please stop right there.  genl is already a queue.  There's no 
>>> sense adding queuing on top of it in this particular case.  If 
>>> l_genl_family_cancel isn't doing the right thing, then fix that instead.
>>
>> Well l_genl_family_cancel really cant do anything about it. Once the 
>> dump hits the kernel you cant cancel it (this is why we added 
>> l_genl_family_request_sent). 
> 
> This was done for a different reason.  In the case of 
> CMD_REMAIN_ON_CHANNEL we must wait for the ack to obtain the cookie.  We 
> can cancel the ROC only if we know the cookie.  Otherwise, even if we 
> call l_genl_family_cancel, the ROC would still go ahead.
> 
> What you have here is a different and simpler case.
> 
>> So the only alternative I can think of, if we cant do it in IWD, would 
>> be to make l_genl queue dumps and not issue more dumps until the 
>> previous one finishes. This is obviously a significant behavioral change.
> 
> I'm lost?  That is what is supposed to happen and happens already 
> today.  If you issue two dumps like:
> 
> l_genl_family_dump(..., msg1, ...);
> l_genl_family_dump(..., msg2, ...);
> 
> Then msg2 will not be sent to the kernel until NLMSG_DONE flagged 
> message is received.  So what exactly would be the behavioral change you 
> are referring to?

Ok this was not my understanding of how l_genl messaging worked. I 
thought you could have multiple in-flight messages. But looking at it 
you can't, the IO writer only sends a single message.

So I'll fix l_genl_family_cancel to not remove the message from the 
pending queue until we get NLMSG_DONE.

> 
> Anyway, looking at l_genl_family_cancel, it is doing the wrong thing, so 
> that should be fixed.
> 
> Regards,
> -Denis