netdev - sunhme duplicate macs

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>] [day] [month] [year] [list]

Date:	Thu, 18 Jun 2009 14:39:49 +1000
From:	Adam Bernau <adam.r.bernau@...il.com>
To:	netdev@...r.kernel.org
Subject: sunhme duplicate macs

I've been annoyed at the duplicate macs on my Sun qfe card (sunhme
driver) for a while, and was doing some research. Back in Oct 2007
there was a patch on the linux-kernel and netdev mailing lists. At the
time the patch was rejected as the incorrect fix, and it was suggested
that the is_quattro_p function might be the problem by always
returning 0. I noticed that it has the following check at the start of
the function

2867        if (busdev == NULL ||
2868            busdev->vendor != PCI_VENDOR_ID_DEC ||
2869            busdev->device != PCI_DEVICE_ID_DEC_21153)
2870                return 0;

A few lines lower down, it iterates through devices looking for SUN
PCI IDS and increments the count.

2877                if (this_pdev->vendor == PCI_VENDOR_ID_SUN &&
2878                    this_pdev->device == PCI_DEVICE_ID_SUN_HAPPYMEAL)
2879                        n_hmes++;

According to lspci my qfe cards have the vendor ID of Sun and are
happymeals, not DECs. Does this mean that the first checks on lines
2868, 2869 are actually incorrect, which causes the return 0 to be hit
every time - ie a relic or copy/paste problem from another driver.
Alternatively, did DEC make some qfe's, and Sun some others? There is
also another DEC reference on lines 3152,3

    Adam
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html