Re: [PATCH v8 09/28] mailbox: Add Gunyah message queue mailbox

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/10/23 12:16 PM, Elliot Berman wrote:
+    ret = gh_hypercall_msgq_send(msgq->tx_ghrsc->capid, msgq_data->length,
+                    (uintptr_t)msgq_data->data, tx_flags, &ready);
+
+    /**
+     * unlikely because Linux tracks state of msgq and should not try to
+     * send message when msgq is full.
+     */

Is it just unlikely, or is it impossible?


This would require multiple mailbox controllers interacting with the same message queue.

The only way I can think this is possible is if the Gunyah drivers are unloaded when the message queue is full; drivers are then re-loaded before the receiver processes the messages. The initial internal state of the message queue controller assumes that there is space in the message queue. We would get a Tx vIRQ once space becomes available and the message would then be attempted to sent again. Since there's a safe flow to recover from a inconsistent internal state and it's very unlikely to start in that state, I don't think we need to add calls to check if the message queue is full during initialization.

First, your explanation is appreciated but more than what I
was looking for...  I just mentioned it because if it were
impossible, then there's no point in having this code handle
something that literally can't happen.

But as far as your explanation, I *hope* if the Gunyah drivers
are unloaded, everything gets fully cleaned up before that
completes.  There should be no in-flight activity, or
any "previous generation" messages that could be processed.

In any case, I think my question is answered.  Thanks.

					-Alex



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux