linux-kernel - Re: [PATCH] mailbox: Allow NULL message sending

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251204055733.759998-1-joonwonkang@google.com>
Date: Thu,  4 Dec 2025 05:57:26 +0000
From: Joonwon Kang <joonwonkang@...gle.com>
To: jassisinghbrar@...il.com
Cc: jonathanh@...dia.com, joonwonkang@...gle.com, linux-kernel@...r.kernel.org, 
	sudeep.holla@....com, thierry.reding@...il.com
Subject: Re: [PATCH] mailbox: Allow NULL message sending

On Tue, Nov 25, 2025 at 11:00 PM Joonwon Kang <joonwonkang@...gle.com> wrote:
> >
> > Clients may want to send interrupt only without any useful message
> > involved. Since the current mailbox framework does not allow NULL
> > message sending(although it allows receiving it), the clients should
> > allocate a dummy message buffer and pretend sending it. Besides, if
> > the mailbox controller calls `mbox_chan_txdone()` when the client
> > drivers happen to send NULL message anyway, it will result in unexpected
> > results by making the tx status messed up. This commit lifts the
> > limitation and allows the clients to send interrupt only without any
> > message buffer allocated.
> >
> Interrupts without data messages are called 'doorbells' and we already
> support them.
> thanks

I am not sure if it is already supported. Let me draw two cases which imply
that it is not supported. If the cases make sense, could you reconsider the
patch? If it is supported in another branch, could you refer me to that
branch? I am currently referring to the `for-next` branch of your mailbox
repo.

Case 1: Send API never returns.

```
mbox_client->tx_block = true;

mbox_chan = mbox_request_channel(mbox_client, index);

/*
 * This send function never returns. It is because the mailbox framework
 * will **not** call `complete(&mbox_chan->tx_complete)` when the sent
 * message is NULL. Refer to `tx_tick()` implementation.
 */
ret = mbox_send_message(mbox_chan, NULL);
```

Case 2: TX status is messed up when NULL and non-NULL messages are sent.

```
/* Thread 1: Send NULL message to the remote. */
ret = mbox_send_message(mbox_chan, NULL);

/*
 * Let's say that the mailbox controller has not received an ACK interrupt
 * from the remote. In this case, the mailbox framework should **not** try
 * picking up the next message from `mbox_chan->msg_data[]` and sending it.
 */

/*
 * Thread 2: However, the mailbox framework will think that there is no
 * pending message in `mbox_chan->msg_data[]`, because `mbox_chan->active_req`
 * is NULL, and thus try sending the message of `msg_buf`. Now,
 * `mbox_chan->active_req` will point to `msg_buf`.
 */
ret = mbox_send_message(mbox_chan, &msg_buf);

/*
 * Let's say that the mailbox controller now has received an ACK interrupt
 * for the NULL message sent by Thread 1 and not received it for Thread 2 yet.
 * Then, it will call in chain `mbox_chan_txdone(mbox_chan, 0)` -->
 * `tx_tick(mbox_chan, 0)`, and the last function will mark as if the message
 * sent by Thread 2 is done by assigning `mbox_chan->active_req` with NULL.
 * Now, the TX status is messed up.
 */
```

Thanks.