Steve Bradshaw found an extremely disturbing bug on SMP systems. He posted a small program that would cause one process to modify another process' data under certain conditions. Stephen C. Tweedie replied, Ack. I looked at this for a while, but it's one of those things that you just know *can't* be happening... until you realise what's going wrong. He pinpointed the problem, explaining, OK, what happens is that munmap() of a MAP_SHARED mapped file is trashing the data of another process on a different CPU which happens still to have the same page mapped. He added that NFS had the same problem.

He posted a patch against 2.2, adding that the problem was moot for 2.3 kernels because of the VM infrastructure changes. He admitted his patch was "a little messy", though he felt there was no truly clean solution.

Linus Torvalds commented (incidentally settling once and for all any question of who really owns the stable kernels), It's a singularly ugly fix, regardless. I would never let code like that near any of my kernels, but Alan is the one who gets to decide in the stable tree.

Alan Cox, from under a pile of 3500 emails accrued during his vacation, came up for air to say, Since 2.2 is going to be around for quite a while yet it wants doing right, painful or otherwise, tested in 2.3.x first if need be.

And Stephen replied to Linus, The trouble is that a correct fix --- the clean way of doing things --- is to back-port the 2.3 changes, which is obviously a non-starter. He described one alternative, but added, but that is a change in the definition of the VFS which I wanted to avoid for 2.2. He went on to explain, The code paths in 2.2 simply don't let us pass information to the fs about whether or not an update_vm_cache() is necessary or not. Either we check in update_vm_cache or we change the VFS definitions. If Alan would prefer the latter then I'm certainly willing to code it that way, but it will be incompatible with existing fs modules.

Linus suggested a two-line solution that wasn't perfect, adding, It's a trade-off - do you do the cheezy two-liner that gets the basic cases right, or do you do the more complex solution that should get everything right but might have some subtle problem. I will accept either from Alan.

Alan's previous comment about "doing it right, painful or otherwise", though at an earlier point in the thread, was actually made after Linus' last remarks, so presumably the more complex solution will be the one to go in.

Bernd Paysan felt something should be done about out-of-memory (OOM) conditions. Rik van Riel gave a pointer to his patch page, and said, Please, somebody grab the OOM patch, integrate it into a new kernel and send it to Linus... However, a discussion ensued about implementation, some of which ignored his patch, and some of which was intended to extend his patch. One of his later comments in the discussion, ran:

A few posts later, he added:

Some news on the egcs/gcc front, last discussed in and before then in (which also links several other articles). Dmitry Veprintsev asked which libc and compiler was being used for kernel development, and Steve Dodd replied, egcs /generally/ works, but you won't get so much sympathy if something breaks. If you must use it, grab the 1.1.2 release (egcs-2.91.66); IIRC earlier versions had bugs. Later versions may also cause problems: the (pre-??) versions of gcc-2.95 that are floating around apparently cause problems if you don't use -fno-strict-aliasing; I don't know if they're OK if you do use that flag.

But Horst von Brand replied, gcc-2.95 is around the corner, its prereleases generate _much_ better code than gcc-2.7.2. I have been compiling my kernels with egcs (lately gcc-2.95 snapshots, after EGCS got appointed keeper of GCC in April) for more than a year and a half now with mostly minor hickups (if that much), many others have done so too. The problems that surfaced have generally promptly been fixed. Many distributions ship kernels compiled with egcs. He added, gcc-2.7.2 is going to go away soon.

Steve replied, I was under the impression that Linus has disputed the code generation thing, but compilers are certainly not my domain so I won't comment. It'll just be nice to have a working C compiler and a working C++ compiler in the same package..

Horst gave this bit of analysis: What Linus has been questioning (AFAIU him :) is that he knows exactly (more or less) what code gcc-2.7.2 will generate, and this isn't true with later versions. You'd have to understand that Linus is a efficiency freak, he wants minute control over the object code. The changed code generation algorithms, new and rewamped optimizations, and assorted other changes in the compiler mean that the certain way of writing code that used to give the fastest object doesn't necessarily do so so anymore. I'd also say that the linux kernel is _the_ piece of code that most uses (and stresses) the different extensions (and quirks, even bugs) of the gcc compiler. So the push towards more standards conformance, even the elimination of bugs in the compiler got at odds with Linus. A famous case was the bug in ia32 that allowed to write illegal asm statements (sadly in a way that was quite logical). Linus does have a point, but the egcs people have to care not just for the linux-kernel-compiler, they have to care for a general purpose tool, even a host of other languages (The current GCC (GNU Compiler Collection) includes C, C++, Objective C, FORTRAN 77, Java, and chill. More are to come, at least Pascal is supposed to be integrated soon AFAIK). I'd say that you loose somewhat locally, but the overall quality of the code is much better. And the egcs folks _do_ care for the kernel, a bug in the compiler exposed by the kernel is high priority; also caveats and workarounds for problems compiling the kernel are routinely posted in the compiler FAQ.

Richard Gooch announced:

Alan Cox announced 2.2.10ac11, and said:

James W. Laferriere got an error:

inet.c: In function net_init':
inet.c:1105: `SOCK_DGRAM' undeclared (first use in this function)
inet.c:1105: (Each undeclared identifier is reported only once
inet.c:1105: for each function it appears in.)
inet.c:1139: warning: implicit declaration of function `inet_aton'
make[1]: *** [inet.o] Error 1

and said, Hello Alan, something in the < ac10 , breaks the sys/socket.h include structure. Making the below under 2.2.10-vanilla compiles like a charm (minus some silly warnings). I have dug into the sys/socket.h tree of includes & I find SOCK_DGRAM defined in asm/socket.h which is included by linux/socket.h which in turn is included by sys/socket.h. But the below happens anyway. Where might I be going wrong ?

Alan replied, The include file changes break libc5 it seems. Right now I've not figured the right way to fix that without upsetting glibc

Several folks posted patches, but Alan had no comment, and the thread ended.

Benjamin C.R. LaHaise asked, I'm wondering if anyone has tackled the problem I pointed out a while ago where an ack manages to arrive before data sent on the same connection due, causing the tcp paws support in 2.2/2.3 to dump the data packet? The traces at http://www.kvack.org/~blah/a.(leeloo|mole) are still valid against 2.3.10, and the behaviour disappears when timestamps are disabled. Debugging verified that tcp_paws_discard is the source of the packet drops, specifically the second term (...tsval - tp->ts_recent) < 0.

Pete Wyckoff noticed from the linked page that leeloo was setting ts_recent for the dup ack packet it was getting. He didn't see where RFC1323 ("TCP Extensions for High Performance") called for such behavior. Ben posted a patch, and replied, Ahh, you're right! I went back over RFC1323 and found out that the code in tcp_replace_ts_recent seems to be the root of this problem. The comment simply don't jive with the code or my reading of the rfc. I've changed things to abide by RFC1323 and the commented change, and now things are flying, even with reordered packets. My reading of RFC1323 is that it tries to only update ts_recent for in-order packets, which makes sense if packets are reordered.

David S. Miller replied:

Linus Torvalds reported:

Richard Gooch replied that the Seti@Home people were probably not behind the forgeries, since they seemed reputable. There was also some small discussion about PGP signatures.

Matthew Kirkwood posted a patch to drivers/char/mem.c, requiring CAP_SYS_RAWIO to open /dev/mem, /dev/kmem and /dev/port. Chris Evans replied, I was working under the assumption we already limit /dev/mem et. al to CAP_SYS_RAWIO. If we don't then this needs applying ASAP.

Andries Brouwer announced:

Wichert Akkerman reported, I upgraded my system from 2.2.6 to 2.2.10-ac11 yesterday and noticed an interesting problem: multiple sockets can now bind to the same port on the same interface. I noticed this when I suddenly had 10 ircd running and client connections were getting accepted by the wrong server (ie not the first one). I've been told this also happens with 2.2.10-ac10. He included a simple test program to illustrate the problem.

Brandon S. Allbery replied, Would you believe that Solaris 2.6 lets you do this as well? But Wichert said, Perhaps, I don't use that. It might even be correct behaviour officialy, but introducing such a change in a 2.2 kernel is a Really-Bad-Idea(TM) since it breaks a lot of programs.

Alexey Kuznetsov said, It was not deliberate, certainly. The patch is appended.

Daniel Kobras said, The attached patch against 2.3.10 (applies fine up to 2.3.11pre5, haven't checked pre6 yet) adds two ioctl()s BLKSSTAT and BLKGSTAT that provide disk i/o statistics per (minor) block device. It's an extension of the basic accounting already exported via /proc/stat. In order to use it, you have to turn on CONFIG_BLK_EXT_STATS and furthermore issue an approriate BLKSSTAT-ioctl() on each device you want to account for. See the comments on top of drivers/block/diskstat.c for details. He also gave a URL to patches against 2.2 kernels.

Alex Buell announced:

Tim Waugh announced: