netdev - Re: [PATCH v3 1/3] mctp pcc: Check before sending MCTP PCC response ACK

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZnwJH5lJpefkzaWg@bogus>
Date: Wed, 26 Jun 2024 13:27:11 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: admiyo@...amperecomputing.com
Cc: Jassi Brar <jassisinghbrar@...il.com>,
	Sudeep Holla <sudeep.holla@....com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Len Brown <lenb@...nel.org>, Robert Moore <robert.moore@...el.com>,
	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>
Subject: Re: [PATCH v3 1/3] mctp pcc: Check before sending MCTP PCC response
 ACK

On Tue, Jun 25, 2024 at 02:53:31PM -0400, admiyo@...amperecomputing.com wrote:
> From: Adam Young <admiyo@...erecomputing.com>
> 
> Type 4 PCC channels have an option to send back a response
> to the platform when they are done processing the request.
> The flag to indicate whether or not to respond is inside
> the message body, and thus is not available to the pcc
> mailbox.  Since only one message can be processed at once per
> channel, the value of this flag is checked during message processing
> and passed back via the channels global structure.
> 
> Ideally, the mailbox callback function would return a value
> indicating whether the message requires an ACK, but that
> would be a change to the mailbox API.  That would involve
> some change to all (about 12) of the mailbox based drivers,
> and the majority of them would not need to know about the
> ACK call.
>

Next time when you post new series, I prefer to be cc-ed in all the patches.
So far I ignored v1 and v2 thinking it has landed in my mbox my mistake and
deleted them. But just checked the series on lore, sorry for that.

> Signed-off-by: Adam Young <admiyo@...amperecomputing.com>
> ---
>  drivers/mailbox/pcc.c | 6 +++++-
>  include/acpi/pcc.h    | 1 +
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 94885e411085..5cf792700d79 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -280,6 +280,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>  {
>  	struct pcc_chan_info *pchan;
>  	struct mbox_chan *chan = p;
> +	struct pcc_mbox_chan *pmchan;
>  	u64 val;
>  	int ret;
>  
> @@ -304,6 +305,8 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>  	if (pcc_chan_reg_read_modify_write(&pchan->plat_irq_ack))
>  		return IRQ_NONE;
>  
> +	pmchan = &pchan->chan;
> +	pmchan->ack_rx = true;  //TODO default to False

Indeed, default must be false. You need to do this conditionally at runtime
otherwise I see no need for this patch as it doesn't change anything as it
stands. It needs to be fixed to get this change merged.

Also we should set any such flag once at the boot, IRQ handler is not
the right place for sure.

-- 
Regards,
Sudeep