netdev - Re: [PATCH net-next v29 1/3] mailbox: add callback function for rx buffer allocation

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: <5dacc0c7-0399-4363-ba9c-944a95afab20@amperemail.onmicrosoft.com>
Date: Sun, 5 Oct 2025 01:13:17 -0400
From: Adam Young <admiyo@...eremail.onmicrosoft.com>
To: Adam Young <admiyo@...amperecomputing.com>,
 Jassi Brar <jassisinghbrar@...il.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 Jeremy Kerr <jk@...econstruct.com.au>,
 Matt Johnston <matt@...econstruct.com.au>,
 "David S . Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Sudeep Holla <sudeep.holla@....com>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 Huisong Li <lihuisong@...wei.com>
Subject: Re: [PATCH net-next v29 1/3] mailbox: add callback function for rx
 buffer allocation

Jassi, this one needs your attention specifically.

Do you have an issue with adding this callback?  I think it will add an 
important ability to the receive path for the mailbox API: letting the 
client driver specify how to allocate the memory that the message is 
coming in.  For general purpose mechanisms like PCC, this is essential:  
the mailbox cannot know all of the different formats that the drivers 
are going to require.  For example, the same system might have MPAM 
(Memory Protection) and MCTP (Network Protocol) driven by the same PCC 
Mailbox.

On 9/25/25 15:00, Adam Young wrote:
> Allows the mailbox client to specify how to allocate the memory
> that the mailbox controller uses to send the message to the client.
>
> In the case of a network driver, the message should be allocated as
> a struct sk_buff allocated and managed by the network subsystem.  The
> two parameters passed back from the callback represent the sk_buff
> itself and the data section inside the skbuff where the message gets
> written.
>
> For simpler cases where the client kmallocs a buffer or returns
> static memory, both pointers should point to the same value.
>
> Signed-off-by: Adam Young <admiyo@...amperecomputing.com>
> ---
>   include/linux/mailbox_client.h | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
> index c6eea9afb943..901184d0515e 100644
> --- a/include/linux/mailbox_client.h
> +++ b/include/linux/mailbox_client.h
> @@ -21,6 +21,12 @@ struct mbox_chan;
>    * @knows_txdone:	If the client could run the TX state machine. Usually
>    *			if the client receives some ACK packet for transmission.
>    *			Unused if the controller already has TX_Done/RTR IRQ.
> + * @rx_alloc		Optional callback that allows the driver
> + *			to allocate the memory used for receiving
> + *			messages.  The handle parameter is the value to return
> + *			to the client,buffer is the location the mailbox should
> + *			write to, and size it the size of the buffer to allocate.
> + *			inside the buffer where the mailbox should write the data.
>    * @rx_callback:	Atomic callback to provide client the data received
>    * @tx_prepare: 	Atomic callback to ask client to prepare the payload
>    *			before initiating the transmission if required.
> @@ -32,6 +38,7 @@ struct mbox_client {
>   	unsigned long tx_tout;
>   	bool knows_txdone;
>   
> +	void (*rx_alloc)(struct mbox_client *cl, void **handle, void **buffer, int size);
>   	void (*rx_callback)(struct mbox_client *cl, void *mssg);
>   	void (*tx_prepare)(struct mbox_client *cl, void *mssg);
>   	void (*tx_done)(struct mbox_client *cl, void *mssg, int r);