LWN: Comments on "3.9 Merge window, second episode"

3.9 Merge window, second episode

makomk — 2013-03-16T12:38:24+00:00

The most interesting comment is this one:

"For the avoidance of doubt the "preferred form" of this code is one which is in an open non patent encumbered format. Where cryptographic key signing forms part of the process of creating an executable the information including keys needed to generate an equivalently functional executable are deemed to be part of the source code."

Apparently stuff like tivoization and Secure Boot were foreseen some time ago...

3.9 Merge window, second episode

nix — 2013-03-01T18:06:33+00:00

I couldn't allow those 3c501 comments to perish uncelebrated, and then looked through the rest and saw so many more... :)

3.9 Merge window, second episode

dashesy — 2013-03-01T00:36:48+00:00

Addition of SO_REUSEPORT is very interesting! I can think of many use-cases, for one it can be used as a clean/easy IPC.

3.9 Merge window, second episode

dashesy — 2013-03-01T00:21:00+00:00

Thanks for digging this up, museum quality kernel archeology :)

3.9 Merge window, second episode

nix — 2013-02-28T19:37:51+00:00

In addition to a number of DEC copyrights and a bunch of Don Becker's drivers, a number of fabulous comments have disappeared from the kernel this day. A selection:

*!@$ protocol=eth_type_trans -- now packets flow

The EtherWORKS 3 driver in this distribution is designed to work with all kernels > 1.1.33 (approx) and includes tools in the 'ewrk3tools' subdirectory to allow set up of the card, similar to the MSDOS 'NICSETUP.EXE' tools provided on the DOS drivers disk (type 'make' in that subdirectory to make the tools).

2) if you wish, edit the source code near line 1530 to reflect the I/O address and IRQ you're using

Fix the last fix...sorry, must be galloping senility

case DEPCA_SAY_BOO:     /* Say "Boo!" to the kernel log file */
        if(!capable(CAP_NET_ADMIN))
                return -EPERM;
        printk("%s: Boo!\n", dev->name);
        break;

/* This should be probed for (or set via an ioctl()) at run-time. Right now we use a sleazy hack to pass in the interface number at boot-time via the low bits of the mem_end field. That value is unused, and the low bits would be discarded even if it was used. */

[This is currently quite safe.... but if one day the 3c503 explodes you know where to come looking ;)]

The E2100 series ethercard is a fairly generic shared memory 8390 implementation. The only unusual aspect is the way the shared memory registers are set: first you do an inb() in what is normally the station address region, and the low three bits of next outb() *address* is used as the write value for that register. Either someone wasn't too used to dem bit en bites, or they were trying to obfuscate the programming interface.
[...]
One bug on the chip is that even a hard reset won't disable the memory window, usually resulting in a hung machine if mem_off() isn't called. If this happens, you must power down the machine for about 30 seconds.

The MB86965 has a design flaw that makes all probes unreliable. Not only is it difficult to detect, it also moves around in I/O space in response to inb()s from other device probes!

results from ftp performance tests with Linux 1.2.5
send and receive about 350-400 KByte/s (peak up to 460 kbytes/s)
sending in NOP-mode: peak performance up to 530K/s (but better don't run this mode)

The card has 256k of on-board RAM, which is used to buffer received packets. It might seem at first that more buffers are better, but in fact this isn't true. From my tests, it seems that more than about 10 buffers are unnecessary, and there is a noticeable performance hit in having more active on the card. So the majority of the card's memory isn't, in fact, used.

And, of course, the immortal 3c501:

Do not purchase this card, even as a joke. It's performance is horrible, and it breaks in many ways.

Some documentation is available from 3Com. Due to the boards age standard responses when you ask for this will range from 'be serious' to 'give it to a museum'. The documentation is incomplete and mostly of historical interest anyway.

The driver is less efficient than it could be. It switches through receive mode even if more transmits are queued. If this worries you buy a real Ethernet card.

Attempt to send a packet to a 3c501 card. There are some interesting catches here because the 3c501 is an extremely old and therefore stupid piece of technology.

We have a good packet. Well, not really "good", just mostly not broken.

3.9 Merge window, second episode

jimparis — 2013-02-28T16:27:22+00:00

Maybe kernel.org could start providing a machine-readable list of known-dangerous commits, the commits that fix them, and a description. A git bisect wrapper could read this list and warn the user (or skip over it) when it lands on something known to be bad.

3.9 Merge window, second episode

tytso — 2013-02-28T15:22:02+00:00

The ext4 bug only affects file systems > 512GB. If you are using smaller file systems on your test/development box, or you make sure you unmount your larger file systems while you are doing your bisection search, you should be fine.

That being said, I'm very embarrassed this bug slipped through our code review and testing processes. We have been discussing how to improve the testing that we do on ext4 file systems to avoid this sort of problem from slipping through our development cycle in the future.