linux-kernel - Re: [PATCH] pci: let pci_device_shutdown to call pci_disable

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: <86802c440804231031w4edc0caeoa1c7e3c4b550df9f@mail.gmail.com>
Date:	Wed, 23 Apr 2008 10:31:29 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	michael@...erman.id.au,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Jesse Barnes" <jbarnes@...tuousgeek.org>,
	"Greg KH" <greg@...ah.com>, "David Miller" <davem@...emloft.net>,
	"Jeff Garzik" <jeff@...zik.org>,
	linux-pci <linux-pci@...ey.karlin.mff.cuni.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"James Bottomley" <James.Bottomley@...senpartnership.com>,
	"Sathya Prakash" <sathya.prakash@....com>
Subject: Re: [PATCH] pci: let pci_device_shutdown to call pci_disable_msi

On Wed, Apr 23, 2008 at 6:08 AM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> Michael Ellerman <michael@...erman.id.au> writes:
>
>  > On Tue, 2008-04-22 at 21:48 -0700, Yinghai Lu wrote:
>  >> this change
>  >>
>  >> | commit 23a274c8a5adafc74a66f16988776fc7dd6f6e51
>  >> | Author: Prakash, Sathya <sathya.prakash@....com>
>  >> | Date:   Fri Mar 7 15:53:21 2008 +0530
>  >> |
>  >> |     [SCSI] mpt fusion: Enable MSI by default for SAS controllers
>  >> |
>  >> | This patch modifies the driver to enable MSI by default for all SAS chips.
>  >> |
>  >> |     Signed-off-by: Sathya Prakash <sathya.prakash@....com>
>  >> |     Signed-off-by: James Bottomley <James.Bottomley@...senPartnership.com>
>  >> |
>  >> cause kexec RHEL 5.1 kernel fail.
>  >>
>  >> root casue: the rhel 5.1 kernel still use INTx emulation.
>  >> and mptscsih_shutdown doesn't call pci_disable_msi to reenable INTx on kexec
>  > path
>  >>
>  >> so try to call pci_disable_msi in shutdown patch
>  >
>  > How is kdump going to work? Your shutdown routine won't be called and
>  > you'll have the same problem in the 2nd kernel, won't you?
>
>  Taking a quick look our current msi initialization appears robust in
>  not assuming the state of the msi config bits.
>
>  So the only remaining problem is running older software that
>  assumes the msi config bits are in the state they should be in
>  out of reset.
>
>  YH on that score it appears I goofed a little when I gave you
>  my suggestion on how to fix this in pci_disable_msi.
>
>  If we have crazy hardware that supports multi irqs in with
>  a plain msi capability.  During initialization we mask
>  all of the irqs.
>
>  from msi_capability_init:
>         if (entry->msi_attrib.maskbit) {
>                 unsigned int maskbits, temp;
>                 /* All MSIs are unmasked by default, Mask them all */
>                 pci_read_config_dword(dev,
>                         msi_mask_bits_reg(pos, is_64bit_address(control)),
>                         &maskbits);
>                 temp = (1 << multi_msi_capable(control));
>                 temp = ((temp - 1) & ~temp);
>                 maskbits |= temp;
>                 pci_write_config_dword(dev,
>                         msi_mask_bits_reg(pos, is_64bit_address(control)),
>                         maskbits);
>         }
>
>  So it appears to truly return to the reset state we should unmask
>  them all, instead of just that one.  Not that it matters in practice,
>  but handling that corner case would be polite.

will extend that a little bit.

YH
--
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/