linux-kernel - RE: [PATCH 1/2] PCI: hv: Reuse existing ITRE allocation in compose_msi

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

Message-ID: <BYAPR21MB1270A579B909B31FA271FC08BFC69@BYAPR21MB1270.namprd21.prod.outlook.com>
Date:   Mon, 9 May 2022 23:13:38 +0000
From:   Dexuan Cui <decui@...rosoft.com>
To:     Jeffrey Hugo <quic_jhugo@...cinc.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "robh@...nel.org" <robh@...nel.org>, "kw@...ux.com" <kw@...ux.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>
CC:     Jake Oshins <jakeo@...rosoft.com>,
        David Zhang <dazhan@...rosoft.com>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2] PCI: hv: Reuse existing ITRE allocation in
 compose_msi_msg()

> From: Jeffrey Hugo <quic_jhugo@...cinc.com>
> Sent: Monday, May 9, 2022 2:48 PM
> Subject: [PATCH 1/2] PCI: hv: Reuse existing ITRE allocation in

s/ITRE/IRTE. I suppose Wei can help fix this without a v2 :-)

> compose_msi_msg()
> ...
> Currently if compose_msi_msg() is called multiple times, it will free any
> previous ITRE allocation, and generate a new allocation.  While nothing
> prevents this from occurring, it is extranious when Linux could just reuse

s/extranious/extraneous

> the existing allocation and avoid a bunch of overhead.
> 
> However, when future ITRE allocations operate on blocks of MSIs instead of

s/ITRE/IRTE

> a single line, freeing the allocation will impact all of the lines.  This
> could cause an issue where an allocation of N MSIs occurs, then some of
> the lines are retargeted, and finally the allocation is freed/reallocated.
> The freeing of the allocation removes all of the configuration for the
> entire block, which requires all the lines to be retargeted, which might
> not happen since some lines might already be unmasked/active.
> 
> Signed-off-by: Jeffrey Hugo <quic_jhugo@...cinc.com>

Reviewed-by: Dexuan Cui <decui@...rosoft.com>
Tested-by: Dexuan Cui <decui@...rosoft.com>