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: <87y1s7j3o4.ffs@tglx>
Date:   Fri, 18 Nov 2022 23:31:07 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Reinette Chatre <reinette.chatre@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     x86@...nel.org, Joerg Roedel <joro@...tes.org>,
        Will Deacon <will@...nel.org>, linux-pci@...r.kernel.org,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Marc Zyngier <maz@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jason Gunthorpe <jgg@...lanox.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Kevin Tian <kevin.tian@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Logan Gunthorpe <logang@...tatee.com>,
        Ashok Raj <ashok.raj@...el.com>, Jon Mason <jdmason@...zu.us>,
        Allen Hubbe <allenbh@...il.com>,
        "Ahmed S. Darwish" <darwi@...utronix.de>
Subject: Re: [patch 21/33] genirq/msi: Provide msi_domain_alloc_irq_at()

On Fri, Nov 18 2022 at 10:18, Reinette Chatre wrote:
>> @@ -141,7 +141,7 @@ static int msi_insert_desc(struct device *dev, struct msi_desc *desc,
>>  		if (ret)
>>  			goto fail;
>>  
>> -		desc->msi_index = index;
>> +		desc->msi_index = index - baseidx;
>
> Could msi_desc->msi_index be made bigger? The hardware I am testing
> on claims to support more IMS entries than what the u16 can
> accommodate.

Sure that's trivial. How big does it claim it is?

>> @@ -1476,9 +1476,10 @@ struct msi_map msi_domain_alloc_irq_at(struct device *dev, unsigned int domid, u
>>  				       const struct irq_affinity_desc *affdesc,
>>  				       union msi_dev_cookie *cookie)
>>  {
>> +	struct msi_ctrl ctrl = { .domid	= domid, .nirqs = 1, };
>> +	struct msi_domain_info *info;
>>  	struct irq_domain *domain;
>>  	struct msi_map map = { };
>> -	struct msi_desc *desc;
>
> (*desc is still needed)

Yes, I figured that out later :)

> Thank you very much. With the above snippet it is possible to
> allocate an IMS IRQ. I am not yet able to use the IRQ and I am working
> on more tracing to figure out why. In the mean time, I did
> just try the pci_ims_alloc_irq()/pci_ims_free_irq() flow and
> pci_ims_free_irq() triggered the WARN below:
>
> remove_proc_entry: removing non-empty directory 'irq/220', leaking at least 'idxd-portal'

Hrm, that's the irq action directory. No idea why that is not torn down.

I assume your sequence is:

  pci_ims_alloc();
  request_irq();        <- This creates it
  free_irq();           <- This removes it
  pci_ims_free();

Right?

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ