Kernel Traffic #30 For 5 Aug 1999

It doesn't. It generates inumbers on the fly. Cluster numbering is unusable for that - truncate() *shouldn't* change inumber. FAT *has* no file invariants that would survive (a) rename, (b) truncate(), (c) write and (d) umount. Of all those umount give the least pain wrt races. New code guarantees constant inumbers for opened files.

The bottom line - inumbers on FAT will suck anyway. There is no inodes in normal sense. And inumbers changing after reboot are *much* better than exploitable races. On FAT usage of (old) inumbers for any backup stuff was broken - rename() would go unnoticed.

You may remember that 2.1 had a Linux implementation that was removed after 2.1.91, due to performance problems, i gather. Our implementation is unrelated to that 2.1.x implementation (except, obviously, that they're both Vegas implementations :-), and makes several critical improvements over that earlier Vegas implementation:

• use of fine-grained time stamps (10ms-granularity doesn't cut it)
• careful filtering and accounting to cope with delayed ACKs.
• speedier slow-start due to increasing cwnd every RTT, just like traditional TCP congestion control

From looking at the older Vegas implementation, i'd guess that these fixes address many of the performance problems in that implementation. Other fixes and enhancements are described on the web page.

I have rewritten the PPP driver, separating the generic part from the async serial part. The new code is IMHO a lot cleaner than the old ppp.c. There is now a ppp_generic.c, which implements the ppp network interface units and the /dev/ppp device, and ppp_async.c, which implements the PPP encapsulation and framing for async serial lines.

The patch is at ftp://cs.anu.edu.au/pub/people/Paul.Mackerras/newppp.patch.gz

It should apply OK against either 2.2.10 or 2.3.10. You will need a new pppd, which you can get at ftp://cs.anu.edu.au/pub/software/ppp/ppp-pre-2.3.9.tar.gz

I did all this before I became aware of Daniel Marmier's post of a week or two ago. I'm looking at merging his changes and mine.

I should have mentioned that if you want to try my new PPP driver (with the new pppd), you will need to do

mknod /dev/ppp c 108 0

If you use module autoloading and have PPP as a module, you will need to add the following to /etc/conf.modules:

alias tty-ldisc-3 ppp_async
alias char-major-108 ppp_generic

the implementation I have submitted is the bare bones super minimum POSIX implementation. Now everybody can add her own special clock/timer to the kernel. For instance if I would want to add an IRIG-B clock I just needed to write a device driver for the card and hook it into the system call infrastructure I have provided. It is not necessary to provide timer and clock functionality for each CLOCK_^lt;type>. Some clocks cannot generate interrupts in order to be usable as a timer, but can only be used as a clock. In that case you just implement the clock_* functions.

Secondly I remember that not too long ago I heard someone ask for greater precision for the clock function gettimeofday. So someone is interested in nanosecond precision. So there it is, go ahead, and implement gettimeofday as clock_gettime(CLOCK_REALTIME, :-).

Basically, the new setup is:

• we have "real address spaces" and "anonymous address spaces". The difference is that an anonymous address space doesn't care about the user-level page tables at all, so when we do a context switch into an anonymous address space we just leave the previous address space active.

  The obvious use for a "anonymous address space" is any thread that doesn't need any user mappings - all kernel threads basically fall into this category, but even "real" threads can temporarily say that for some amount of time they are not going to be interested in user space, and that the scheduler might as well try to avoid wasting time on switching the VM state around. Currently only the old-style bdflush sync does that.

• "tsk->mm" points to the "real address space". For an anonymous process, tsk->mm will be NULL, for the logical reason that an anonymous process really doesn't _have_ a real address space at all.

• however, we obviously need to keep track of which address space we "stole" for such an anonymous user. For that, we have "tsk->active_mm", which shows what the currently active address space is.

  The rule is that for a process with a real address space (ie tsk->mm is non-NULL) the active_mm obviously always has to be the same as the real one.

  For a anonymous process, tsk->mm == NULL, and tsk->active_mm is the "borrowed" mm while the anonymous process is running. When the anonymous process gets scheduled away, the borrowed address space is returned and cleared.

To support all that, the "struct mm_struct" now has two counters: a "mm_users" counter that is how many "real address space users" there are, and a "mm_count" counter that is the number of "lazy" users (ie anonymous users) plus one if there are any real users.

Usually there is at least one real user, but it could be that the real user exited on another CPU while a lazy user was still active, so you do actually get cases where you have a address space that is _only_ used by lazy users. That is often a short-lived state, because once that thread gets scheduled away in favour of a real thread, the "zombie" mm gets released because "mm_users" becomes zero.

Also, a new rule is that _nobody_ ever has "init_mm" as a real MM any more. "init_mm" should be considered just a "lazy context when no other context is available", and in fact it is mainly used just at bootup when no real VM has yet been created. So code that used to check

        if (current->mm == &init_mm)

should generally just do

        if (!current->mm)

instead (which makes more sense anyway - the test is basically one of "do we have a user context", and is generally done by the page fault handler and things like that).

Anyway, I put a pre-patch-2.3.13-1 on ftp.kernel.org just a moment ago, because it slightly changes the interfaces to accomodate the alpha (who would have thought it, but the alpha actually ends up having one of the ugliest context switch codes - unlike the other architectures where the MM and register state is separate, the alpha PALcode joins the two, and you need to switch both together).

It's more a reaction to a (temporary and already removed) naming issue. Ingo got rid of the 1:1 mapping of "hard" thread structures on the x86 side, so now we only have one TSS per CPU, and all the kernel thread structures are completely independent of the CPU-imposed thread structure on x86.

While Ingo was working on it, he called the kernel thread structure a "soft_thread_struct", while the intel TSS structure was then called a "hard_thread_struct". That was purely temporary and never saw the light of day: the real names are "thread_struct" for the kernel thread structure, and "tss_struct" for the intel TSS.

Feature freeze in about two weeks is the current plan.

In short, people who think they have major requirements had better get their act together. That means that if ISDN people actually want to try to get into a real release one of these years, they don't have all that much time to futz around any more.

And it does mean that if it's not in working order already, it probably won't make it into 2.4.