linux-kernel - Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_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: <20130905200608.GA3846@htj.dyndns.org>
Date:	Thu, 5 Sep 2013 16:06:08 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Alexander Gordeev <agordeev@...hat.com>
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org,
	linux-pci@...r.kernel.org, linux-ide@...r.kernel.org,
	Ingo Molnar <mingo@...nel.org>, Joerg Roedel <joro@...tes.org>,
	Jan Beulich <JBeulich@...e.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

Hello, Alexander.

On Thu, Sep 05, 2013 at 08:54:40PM +0200, Alexander Gordeev wrote:
> I assume reasons for having this type of interface at the moment of
> taking design decision about pci_enable_msi_block() still hold true.
> I do not know what those reasons were, but I think the fact multiple
> MSIs are rarely used and MSI-X exists does not invalidate them now.

Well, it does change the underlying assumptions to make trade-offs
against.  If something is widely used, expected to continue to expand,
additional complexity to achieve better outcome is likely to be more
justifiable.  Nothing exists in vacuum.  That said, I'm not even sure
whether we want this sort of interface even if multiple MSI were still
the hot thing.

> I did consider the other argument - since pci_enable_msi_block_part()
> is explicitly provided with a value of MME the caller will not be
> satisfied with any other value and hence a repeated call with a lesser
> MME does not make sense for the caller. Therefore we could just fail
> in case the architecture returned a positive value. Same result, but
> different reasoning.

Just making the whole thing including arch methods to return 0/-errno
would probably be a lot cleaner.

> At the moment I still prefer pci_enable_msi_block_part() to be similar
> to pci_enable_msi_block(). I do agree the fallback logic is error-prone,
> but I would not dare to scrap it all right away.

Yeah, of course, pci_enable_msi_block() would need to be updated to
match too.  I understand this is going a bit off the original scope of
the patchset but I can't help but cringing at the interface and the
resulting "fallback" logic it ends up creating in its users.  Bjorn,
what do you think?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/