Salvatore D'Angelo noticed that calling gettimeofday() twice in sequence in 2.4.18 seemed to show time going backwards. The second result was not necessarily larger than the first. He posted some code to reproduce the behavior and said it manifested itself about 10% of the time. Matti Aarnio gave it a try, and confirmed the problem, but reported only a single case in about 216 million iterations. Salvatore admitted that his estimate of 10% was probably too high. He ran his test again and came up with approximately .01% reproducibility. At this point Karim Yaghmour said:

Elsewhere, Richard B. Johnson was unable to reproduce the problem using his own test program, but Frank van de Pol used the same program and did find several occurrences. He speculated, Possibly it might have to do with the fact that my machine is an SMP box (dual pentium II) Richard replied, Well, I have a dual Pentium also, but I didn't mix two different CPUs as you have done. I'm supprised that your combination even works! It could be a good 'checker' for hard-to-make race conditions. Chris Friesen also said:

And Gabriel Paubert added:

Michael Kerrisk asked how filesystem capabilities were doing in the 2.4 and kernel. He knew there had been at least partial support since 2.2, and wondered if any further work had been done. Dax Kelson replied:

But Jesse Pollard gave a link and said, Actually, I think most of that work has already been done by the Linux Security Module project (well, except #7). Chris Wright clarified, The LSM project supports capabilities exactly as it appears in the kernel right now. The EA linkage is still missing. Of course, we are accepting patches ;-) And Jesse came back with, Absolutely - I was just meaning that the effort of identifing the location(s) in the kernel the hooks will have to be to set the capabilities from the EA reference has been done. And in a central location too. Also, the hooks in the filesystem will provide the location, if not access to, the EA when they become available in/to the VFS (at least I hope that's where they end up).

Rik van Riel announced:

Andrew Rodland said:

Stephen Frost thought this was a very silly attitude, saying, That's silly and if #kn had to be on OPN then it wouldn't exist due to the policies as riel pointed out. As far as forcing people not to use the channel at Openprojects Network, he added, Uh, I believe you have the OPN ircops to thank for making it +m. I know that it was done by Chanserv directly after riel had left. An anonymous person pointed out that Rik would have had to set the channel himself before leaving. If Chanserv had done it, the channel would not let anyone else in. Stephen replied, The irc ops could do either, of course. I find it very likely that it was done by lilo [Rob Levin] after I mentioned that the channel had moved on a channel he was on. Stephen added, As far as I could tell, riel had already left the network at that point. Additionally, if you /m chanserv info #kernelnewbies you will see that the 'Mode Lock' is only +s and that +m is *not* there. Gerhard Mack replied:

Stephen replied, It wasn't misinformation, it's what I felt likely, and still do, honestly.

Matthias Andree asked about the status of write barrier support, and asked if there were a web page somewhere that tracked documentation and new patches. Jens Axboe said he didn't know of any such web page, but he summarized, We have stable support for IDE (ie block layer barrier support works, IDE implementation works). I doubt we'll ever do 2.4 SCSI support, it would be too invasive to really make it safe. Matthias shook his head sadly, saying he needed the SCSI support. He thought aloud, that he'd probably have to start using 2.5 on his system in the near future.

Willy Tarreau announced:

Denis Vlasenko noticed some performance-critical areas of the code that were not optimized as far as they could be, and posted some patches to speed them up. Willy looked over Denis' modifications, and pointed out some objections. He added that he had been coding for correctness rather than speed, and that if speed were really an issue, he'd want to translate most of the code into assembler. Bill Davidsen replied, This sounds good, the idea is that it should work at all, clarity is good, I can't imagine anyone running this long term instead of building a compile with the right machine type. Denis felt the speed issue could become serious, and might give casual users the impression that Linux was slow. They discussed various ways to profile the code or at least warn when a slowdown could be expected; and the thread petered out.

Paul Menage said, This patch removes BKL protection from the invocation of the super_operations ->statfs() method, and shifts it into the filesystems where necessary. Any out-of-tree filesystems may need to take the BKL in their statfs() methods if they were relying on it for synchronisation. He added, All modified filesystems have been compiled except for the disabled umsdos; only ext2 and shmfs have actually been tested. Matthew Wilcox suggested there were even more Big Kernel Lock usages that could be removed, and Paul replied, I'm sure the BKL can be ripped out further, but I preferred not to risk breakage in this patch due to unfamiliarity with the locking rules for particular filesystems - I just left the BKL out of those that were clearly not touching mutable data. Patches that shrink the BKL usage for individual filesystems can be sent (hopefully with copious justifications) once this or something like it is applied. But later on and in a different subthread, he posted an expanded patch to remove the BKL from yet more areas of code. Various folks posted more suggestions of areas of filesystem code that could do without the BKL.