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]

Date:   Mon, 9 May 2022 20:29:19 -0600
From:   Jeffrey Hugo <quic_jhugo@...cinc.com>
To:     Dexuan Cui <decui@...rosoft.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()

On 5/9/2022 5:13 PM, Dexuan Cui wrote:
>> 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 :-)

Thanks for the review.

I have no problem sending out a V2.  Especially since you pointed out my 
mistakes on both patches.  I'll wait a little bit for any additional 
feedback, and then send out 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>