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: <20120529095155.GA27043@redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ