Bugs, Problems and Questions

Wolfram Kleff (kleff@athene.informatik.uni-bonn.de)
Fri, 6 Sep 1996 22:18:06 +0200 (MET DST)

I have some questions/problems regarding the Linux Kernel:
(verified with Linux Kernel 2.0.18)

1) In /proc/mounts the root filesystem device is called "rootfs"
but in ../src/linux/Documentation/devices.txt it is called:
"/dev/root root device symbolic Current root filesystem"
so why don't we call it "/dev/root" instead of "rootfs" ?
(I have patched the kernel: works ok)

2) A security problem: The "setterm -reset" escape seqence doesn't clean
the console history-scrollback buffer !
The Problem: A logged out console user leaves his "footprints"
in the history-scrollback buffer which is a vulnerability in
a multiuser environment.
There should be a escape sequence like "setterm -reset" that
cleans the history-scrollback buffer without using "ways-around".

3) /proc/cpuinfo claims a 0.01 less BogoMIPS value than the bootup code.(dmesg)
Which value is correct and why is there a difference ? (bug ?)
(Why is it calculated two times with a different formula ?)

4) A seek to /dev/full returns e.g. "unknown error 10000" for seek 10000.
(The kernel device driver doesn't change the input value,
so input value=return value - in this case 10000)
Is this correct ?
Wouldn't ESPIPE be better ?

5) If I create a directory with mkdir(dirname,01777) the permisson of
the created directory is 0777 (no sticky flag). (Yes, umask IS 0000)
Is this a bug or a feature ?

6) Real bug: "cp /proc/kcore /...." can hold ("freeze") the kernel
e.g. with X started. Not even a klog bug report is delivered.
Ok, never do nasty things with the superuser, but there should be a
few "savety belts" around/in the kernel memory get routine.

7) Why do we need the updated as a real process ?
Yes, I know its functionality, I just want to know why it isn't a
kernel process like kflushd or kswapd ?
Is there a reason for it, I don't understand ?
The problem is, if the updated is killed accidently, never started
or whatever might happen, the blocks wouldn't be written back to disk.
Wouldn't it be a good idea for 2.1.x to implement it as a kernel process ?

I hope for answers (and official bug fixes/kernel patches),
Wolfram Kleff