linux-kernel - Re: [PATCH 2/2 RESEND] mailbox: Make mbox_send

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: <20260206100622.4166528-1-joonwonkang@google.com>
Date: Fri,  6 Feb 2026 10:06:22 +0000
From: Joonwon Kang <joonwonkang@...gle.com>
To: jassisinghbrar@...il.com
Cc: joonwonkang@...gle.com, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org, lee@...nel.org
Subject: Re: [PATCH 2/2 RESEND] mailbox: Make mbox_send_message() return error

> > Previously, when the mailbox controller failed transmitting message, the
> > error code was only passed to the client's tx done handler and not to
> > mbox_send_message(). For this reason, the function could return a false
> > success. This commit resolves the issue by introducing the tx status and
> > checking it before mbox_send_message() returns.
> >
> A client submitted the message, and that client gets the actual
> status. mbox_send_message does not (can not) tell if the message was
> successfully sent or not. For example, consider non-blocking mode when
> mbox_send_message() immediately returns after simply placing the
> message in the fifo. It returns 0, but still the message transmission
> may fail when its turn comes. So I think it is fine as is.

When it comes to non-blocking send function, the common expectation is that
users of the function do not expect the final send result in its return value
of the non-blocking function. And it makes sense for users to register a
callback to collect the final send result. It is a common practice for non-
blocking function.

For blocking send function, however, it will be quite unexpected behavior if
the blocking send function returns no error code but it actually has failed.
Also, it will be uncommon if users of the blocking send function have to
register additional callback just to collect the final send result. If that is
the case, the blocking function requires of users both blocking and callback,
which is redundant.

Overall, I think it will be better if we return error code in blocking mode if
it has actually failed transmiting the request. How do you think?