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.
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ