linux-kernel - Re: [PATCH] PCI: Mark INTx masking support of Chelsio T310 10GbE NIC as broken

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:	Tue, 29 May 2012 12:51:55 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Jan Kiszka <jan.kiszka@...mens.com>
Cc:	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Alexey Kardashevskiy <aik@...abs.ru>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alex Williamson <alex.williamson@...hat.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	David Gibson <david@...son.dropbear.id.au>,
	Alexander Graf <agraf@...e.de>, kvm <kvm@...r.kernel.org>
Subject: Re: [PATCH] PCI: Mark INTx masking support of Chelsio T310 10GbE NIC
 as broken

On Tue, May 29, 2012 at 09:51:09AM +0200, Jan Kiszka wrote:
> On 2012-05-28 15:39, Michael S. Tsirkin wrote:
> > On Mon, May 28, 2012 at 03:29:58PM +0200, Jan Kiszka wrote:
> >> On 2012-05-28 15:21, Michael S. Tsirkin wrote:
> >>> On Mon, May 28, 2012 at 02:51:25PM +0200, Jan Kiszka wrote:
> >>>> On 2012-05-28 14:39, Michael S. Tsirkin wrote:
> >>>>> On Fri, May 25, 2012 at 11:02:13AM -0300, Jan Kiszka wrote:
> >>>>>> According to Alexey, the T310 does not properly support INTx masking as
> >>>>>> it fails to keep the PCI_STATUS_INTERRUPT bit updated once the interrupt
> >>>>>> is masked. Mark this adapter as broken so that pci_intx_mask_supported
> >>>>>> won't report it as compatible.
> >>>>>>
> >>>>>> Reported-by: Alexey Kardashevskiy <aik@...abs.ru>
> >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@....de>
> >>>>>
> >>>>>
> >>>>> Just a thought: would be nice to have a way to discover
> >>>>> the quirk was activated. Add an attribute so that
> >>>>> userspace can detect and report this properly to users?
> >>>>> Or just log a warning message ...
> >>>>
> >>>> pr_notice_once?
> >>>
> >>> OK IMO.
> >>>
> >>>> A flag for userspace would be significantly more
> >>>> complicated (and not PCI layer hands).
> >>>
> >>> Why not? I meant e.g. an attribute in pci-sysfs.
> >>
> >> Possible. But what is the preferred way of doing this? Are there any
> >> precedences?
> >>
> >> Jan
> >>
> > 
> > E.g. a reset attribute is there only if device reset is supported.
> > I don't insist on this - merely asking how does userspace report
> > an attempt to share IRQs and whether the reason is
> > discoverable in some way.
> 
> Well, so far there is no attribute associated with INTx masking that we
> could hide to express this.
> 
> Jan

Thinking about it some more, userspace using this functionality
is pretty recent. So if we just teach it to report
'intx mask or status bit unsupported' on failure,
plus add pr_notice as you suggested, then that's
probably enough.


> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
--
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/