netdev - Re: [PATCH v5 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20240916105157.00001204@Huawei.com>
Date: Mon, 16 Sep 2024 10:51:57 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Adam Young <admiyo@...eremail.onmicrosoft.com>
CC: <admiyo@...amperecomputing.com>, Sudeep Holla <sudeep.holla@....com>,
	Jassi Brar <jassisinghbrar@...il.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>, Huisong Li
	<lihuisong@...wei.com>
Subject: Re: [PATCH v5 1/3] mctp pcc: Check before sending MCTP PCC response
 ACK

On Fri, 13 Sep 2024 17:21:06 -0400
Adam Young <admiyo@...eremail.onmicrosoft.com> wrote:

> >>+ * @shmem_base_addr: the virtual memory address of the shared buffer  
> 
> >If you are only going to map this from this pointer for the
> >initiator/responder shared memory region, maybe it would benefit
> >from a more specific name?  
> 
> 
> I am not certain what would be more correct.
> 
> 
> On 8/1/24 07:41, Jonathan Cameron wrote:
> 
> >> +	pchan->shmem_base_addr = devm_ioremap(chan->mbox->dev,
> >> +					      pchan->chan.shmem_base_addr,
> >> +					      pchan->chan.shmem_size);  
> > devm doesn't seem appropriate here given we have manual management
> > of other resources, so the ordering will be different in remove
> > vs probe.
> >
> > So I'd handle release of this manually in mbox_free_channel()  
> 
> 
> How fixed are you on this?  mbox_free_channel is the parent code, and 
> knows nothing about this resource.  It does no specific resource cleanup.


I've lost context on this unfortunately and don't have time to look
back at it this week. Maybe right answer is a cleanup callback?

> 
> The only place we could release it is in the pcc_mbox_free, but that is 
> essentially a call to the parent function.
> 
> All other comments should be addressed in the next version.
> 
>