netdev - Re: [PATCH 12/21] r8169: confusion between hardware and IP header alignment

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

Date:	Mon, 26 Nov 2007 23:42:01 +0100
From:	Francois Romieu <romieu@...zoreil.com>
To:	Martin Michlmayr <tbm@...ius.com>
Cc:	netdev@...r.kernel.org, Edward Hsu <edward_hsu@...ltek.com.tw>,
	bunk@...sta.de
Subject: Re: [PATCH 12/21] r8169: confusion between hardware and IP header
	alignment

Martin Michlmayr <tbm@...ius.com> :
> * Francois Romieu <romieu@...zoreil.com> [2007-11-26 00:05]:
> > > I'd like to backport the fix to the 2.6.18 kernel that is in our
> > > stable release and have a couple of questions:
> > >  - Does your later patch "align the IP header when there is no DMA
> > >    constraint" fix any bugs or is it merely an improvement?
> > It fixes a "it was faster before" problem.
> 
> Before the patch I'm interested in backporting, right?  In that case,
> the patch I suggested would fix a bug but also introduce a performance
> regression.  So maybe the later patch should also be backported.  What
> do you think?

The regression was due to cc9f022d97d08e4e36d38661857991fe91447d68.
cc9f022d.. does not appear to be in v2.6.18.8.

[...]
> > >  - Should I change "align" to 8 for RTL_CFG_1, as it's done in
> > >    current kernels?
> > No. RTL_CFG_1 is for the 8168 (slightly different beast).
> 
> Yes, but might 8168 users face similar problems as the one I saw?

Clearly.

There is a pentachiée* of patches to handle correctly the different
flavors of 8168 devices in the recent kernels (not speaking for the
genuine bugs). Until someone analyzes the log of the r8169, extracts
the relevant pieces and tests them with 2.6.18.x, it will be hard to
claim to support the 8168 with this kernel.

[*] en français dans le texte.

> 
> > If you have 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 applied, you
> > want c946b3047205d7e107be16885bbb42ab9f10350a too.
> ...
> > If you move from the 8110SB to the 8110SC, you will probably want to apply
> > 65d916d95314566f426cc40ff0f17b754a773b0b
> 
> I don't have 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 and it still
> says 8110SB, so I won't need these patches for my device.  However,
> these patches look like candidates to put into 2.6.18 anyway.  I'd
> like to avoid backporting too many changes from 2.6.24 to 2.6.18, but
> are there any fixes we should absolutely have?

Let aside the "align" fixes, the short list below contains some candidates
in reverse order:

315917d23fdd20a0f4ff99b9228de5840d9d276c
9cb427b6ff0b3e235c518acf5c1fcbbfc95f0ae2
d03902b8864d7814c938f67befade5a3bba68708 | you should already have those
a27993f3d9daca0dffa26577a83822db99c952e2 |
eb2a021c4710b98081daa797d5a729ac23c240cd
2efa53f373ed811d4860904f5205b8a3b376e253
99f252b097a3bd6280047ba2175b605671da4a23
1371fa6db0bbb8e23f988a641f5ae7361bc629dd

It's gross though: there are 99 changes from v2.6.18.8 to current master
for the r8169 driver and some registers init changes may have been partially
reverted later.

Sorry if it is not terribly specific but I really, really, really need to
spend more time on several bugs first.

[...]
> With 2.6.24-rc2-g8c086340-dirty:
> r8169 Gigabit Ethernet driver 2.2LK loaded
> eth0: RTL8169sb/8110sb at 0xe085c200, 00:14:fd:10:33:8e, XID 10000000 IRQ 27
> r8169 Gigabit Ethernet driver 2.2LK loaded
> eth1: RTL8169sb/8110sb at 0xe085e300, 00:14:fd:10:33:8f, XID 10000000 IRQ 30

Nice. Thanks.

-- 
Ueimor
-
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