Kernel Traffic #174 For 7 Jul 2002

There were 316 different contributors. 141 posted more than once. 119 posted last week too.

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:

This has already been discussed on the LKML. Here's the thread: http://marc.theaimsgroup.com/?t=102348161100006&r=1&w=2

I posted the following message on this issue: http://marc.theaimsgroup.com/?l=linux-kernel&m=102348249521519&w=2

As I had said earlier, I've seen this happen before on both i386 and PPC machines.

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:

Using that code, I can reliably trigger the fault on 2.2.17 on a G4 desktop, while it doesn't trigger on 2.4.18 on a G4 cPCI blade.

I saw this a long time back (a year or two) on 2.2 but never really tracked it down properly as it wasn't a showstopper and I had other things to do at the time.

Given the fact that the relevant code has been almost completely rewritten for 2.4 (I'm the culprit), this is not surprising.

The rewrite was mostly to make the code more robust in case of missed ticks: all PPC are now guaranteed to withstand at least (HZ-1) lost clock interrupts before things go awfully wrong (this was very useful when the frame buffer drivers blocked interrupts for too long during screen switching). There are also several other less visible bug fixes: when connected to an NTP server, in some cases the timebase frequency appeared to vary depending on system load (fixed by a different algorithm to compute values to load into the decrementer) and other bogosities.

Now if you are able to trigger a problem with 2.4. I'm extremely interested.

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:

The 2.5 VFS supports Extended Attributes (since 2.5.3). I think the plan was use EAs to store capabilities. So I believe that the infrastructure is in place, someone with the proper skills just needs to:

Define how capabilities will be stored as a EA
Teach fs/exec.c to use the capabilities stored with the file
Write lscap(1)
Write chcap(1)
Audit/fix all SUID root binaries to use capabilities
Set appropriate capabilities with for each with chcap(1) and then:
# find / -type f -perm -4000 -user root -exec chmod u-s {} \;
Party and snicker in the general direction of that OS with the slogan "One remote hole in the default install, in nearly 6 years!"

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)."

due to a possible incompatibility between one of the OPN admins soliciting money on a regular basis and the policies of the network where kernelnewbies.org is hosted we have decided to move the #kernelnewbies IRC channel to another network.

You will be able to find us on:

irc.oftc.net / #kernelnewbies

Kernelnewbies is a project meant to help people learn about operating system development by providing information and operating a mailing list and IRC channel where current and future developers can help each other. More information about kernelnewbies can be found on http://kernelnewbies.org/

You realize that if you weren't _forcing_ people not to go to the channel on OPN, by making it useless, everyone would go there anyway.

Why?

Because a #kn that isn't on OPN is no #kn at all.

I hope the other one dies a slow, painful death, for the good of everyone.

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:

Not correct.. lilo was actually supprised when he found out it was moderated.

You should have asked lilo directly instead of spreading misinformation.

Anyhow one of the other chanops seems to have removed the +m and the channel is functional again.

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.

OK, I know that many people dislike this, but I know others who occasionally need it anyway. So I don't post it for general inclusion, but for interested people.

What is it ? it's a software emulator for x86 opcodes not handled by the processor. Emulations available are :

BSWAP, CMPXCHG, XADD on 386 (486 instructions)
CMOV on any x86 processor (pentium-pro instructions)

It is not meant to replace a correct compilation, but it may have happened to all of us to try to rescue a damaged system or with a boot disk, and copying some programs with a floppy, and then get an 'Illegal instruction' because these programs have been compiled with a badly configured compiler. I once had a gcc which did i686 by default, and I had a hard time trying to execute an e2fsck it had compiled, on my k6 notebook !

Same if you take a disk from a system, and try to boot it on another one. Well, I won't spend more time finding examples.

I've been using the 486 emulation on my 386 firewall for a few years now, and have been quite happy with it. I cleaned the code a bit and added support for cmov. All this will grow your bzImage with less than 1kB.

As I stated above, it is *NOT* meant to replace a recompilation for the correct target. Emulation is quite slow because of the time the CPU spends processing the trap. I measured about 450 cycles for a cmov, which is quite a overhead, but still acceptable for occasionnal purposes (1us on my k6/450).

I was thinking about adding some statistics informations, such as the number of traps caught, globally and by process, but finally realized that this was only bloat for something that should not be used permanently.

I didn't have the time to try VMWare on top of this. It could be interesting to be able to provide CMOV or other instructions to guest systems.

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.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	24 Jun 2002 - 30 Jun 2002	(22 posts)	gettimeofday() Shows Time Going Backwards
2.	26 Jun 2002 - 28 Jun 2002	(6 posts)	Status Of Filesystem Capabilities
3.	26 Jun 2002 - 28 Jun 2002	(7 posts)	#kernelnewbies Moves To A Different IRC Network
4.	27 Jun 2002 - 28 Jun 2002	(7 posts)	Status Of Write Barrier Support For 2.4 And 2.5
5.	29 Jun 2002 - 2 Jul 2002	(14 posts)	Opcode Emulator For Incompatible Processors
6.	2 Jul 2002 - 3 Jul 2002	(9 posts)	Ongoing BKL Removal

Kernel Traffic #174 For 7 Jul 2002

By Zack Brown