linux-kernel - Re: [PATCH] PCI/MSI: fix 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]

Date:	Sun, 8 Feb 2009 04:26:51 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Cc:	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	Matthew Wilcox <willy@...ux.intel.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [PATCH] PCI/MSI: fix msi_mask()

On Thu, Feb 05, 2009 at 11:47:36AM +0900, Hidetoshi Seto wrote:
> The commit bffac3c593eba1f9da3efd0199e49ea6558a40ce does:
> 
>  -    temp = (1 << multi_msi_capable(control));
>  -    temp = ((temp - 1) & ~temp);
>  +    temp = msi_mask((control & PCI_MSI_FLAGS_QMASK) >> 1);
> 
> and provides msi_mask() to avoid undefined shift by 32.
[...]
> This patch fix the wrong array in the msi_mask().

Quite correct.  While disconnected for a couple of weeks, I also
considered this possible fix:

static inline __attribute_const__ u32 msi_mask(unsigned x)
{
        /* Don't shift by >= width of type */
        if (x >= 5)
                return 0xffffffff;
        return (1 << (1 << x)) - 1;
}

which has the added bonus of not running off the end of the array if
some device has a bogus value in its config space.

What do you think?

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/