netdev - Re: [PATCH] Revert "mailbox/pcc: support mailbox management of the shared buffer"

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CABb+yY2Uap0ePDmsy7x14mBJO9BnTcCKZ7EXFPdwigt5SO1LwQ@mail.gmail.com>
Date: Mon, 29 Sep 2025 19:19:27 -0500
From: Jassi Brar <jassisinghbrar@...il.com>
To: Adam Young <admiyo@...eremail.onmicrosoft.com>
Cc: Sudeep Holla <sudeep.holla@....com>, Adam Young <admiyo@...amperecomputing.com>, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "mailbox/pcc: support mailbox management of the
 shared buffer"

On Mon, Sep 29, 2025 at 12:11 PM Adam Young
<admiyo@...eremail.onmicrosoft.com> wrote:
>
> I posted a patch that addresses a few of these issues.  Here is a top
> level description of the isse
>
>
> The correct way to use the mailbox API would be to allocate a buffer for
> the message,write the message to that buffer, and pass it in to
> mbox_send_message.  The abstraction is designed to then provide
> sequential access to the shared resource in order to send the messages
> in order.  The existing PCC Mailbox implementation violated this
> abstraction.  It requires each individual driver re-implement all of the
> sequential ordering to access the shared buffer.
>
> Why? Because they are all type 2 drivers, and the shared buffer is
> 64bits in length:  32bits for signature, 16 bits for command, 16 bits
> for status.  It would be execessive to kmalloc a buffer of this size.
>
> This shows the shortcoming of the mailbox API.  The mailbox API assumes
> that there is a large enough buffer passed in to only provide a void *
> pointer to the message.  Since the value is small enough to fit into a
> single register, it the mailbox abstraction could provide an
> implementation that stored a union of a void * and word.
>
Mailbox api does not make assumptions about the format of message
hence it simply asks for void*.
Probably I don't understand your requirement, but why can't you pass the pointer
to the 'word' you want to use otherwise?

-jassi