linux-kernel - Re: [PATCH v9 02/15] cxl/regs: Prepare for multiple users of register mappings

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]

Date:   Fri, 1 Sep 2023 10:10:03 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Dan Williams <dan.j.williams@...el.com>
CC:     Terry Bowman <terry.bowman@....com>, <alison.schofield@...el.com>,
        <vishal.l.verma@...el.com>, <ira.weiny@...el.com>,
        <bwidawsk@...nel.org>, <dave.jiang@...el.com>,
        <linux-cxl@...r.kernel.org>, <rrichter@....com>,
        <linux-kernel@...r.kernel.org>, <bhelgaas@...gle.com>
Subject: Re: [PATCH v9 02/15] cxl/regs: Prepare for multiple users of
 register mappings

On Thu, 31 Aug 2023 11:11:40 -0700
Dan Williams <dan.j.williams@...el.com> wrote:

> Terry Bowman wrote:
> > From: Robert Richter <rrichter@....com>
> > 
> > The function devm_cxl_iomap_block() is used to map register mappings
> > of CXL component or device registers. A @dev is used to unmap the IO
> > regions during device removal.
> > 
> > Now, there are multiple devices using the register mappings. E.g. the
> > RAS cap of the Component Registers is used by cxl_pci, the HDM cap
> > used in cxl_mem. This could cause IO blocks not being freed and a
> > subsequent reinitialization to fail if the same device is used for
> > both.
> > 
> > To prevent that, expand cxl_map_component_regs() to pass a @dev to be
> > used with devm to IO unmap. This allows to pass the device that
> > actually is creating and using the IO region.
> > 
> > For symmetry also change the function i/f of cxl_map_device_regs().  
> 
> I think @dev is too ambiguous as a name. I.e. when does @dev refer to
> the 'struct device *' instance that the registers belong, and when does
> @dev refer to the 'struct device *' instance hosting the mapping for
> devm operations?
> 
> One of the ways I have tried to disambiguate that distinction is using
> the name @host to explicitly refer to the context of devm operations,
> and @dev is only for context for dev_dbg() operations. Can you clarify
> this patch by using @host everywhere that the devm context is being
> handled?
> 
> This would also satisfy Jonathan's concern. I think it needs to be the
> case that @map is explicit about when it is conveying some @dev context for
> dev_dbg() messages and when it is conveying the @host for devm
> operations because those are 2 different concepts.

I should read all the replies before I reply to any of them.
Agreed that renaming it would satisfy my concern over the confusion.

> 
> It looks like @dev argument you are plumbing here is for when @map->dev
> cannot be used for devm operations, so at a minimum use @host as the
> variable name to make that clear...
> 
> ...or always make it the case that @map carries an @host parameter which
> would mean that ports would need their own copy of the comp_map versus
> directly reusing the one in the cxlds since those 2 mapping instances
> need different @host parameters. That feels cleaner to me then
> "sometimes map->dev can be used for devm and sometimes not". @map->host
> is always the devm context.

Agreed that may be better still.

Jonathan