This was the second longest thread ever covered in Kernel Traffic, the first
being covered in
Peter Zaitsev found that a simple program that just kept allocating 4K
chunks of memory until swap was used up, would reduce the system to an
unusable state, and would eventually kill off important processes. He added
that on Solaris, this same program would just get an out of memory error
eventually, and not unduly inconvenience any other processes at all. Carlos
Morgado explained what was happening, Basicly
all the swaped out runnable processes will die when they page fault. since
we're oom basicly all processes are more or less swaped out. as consequence,
at least syslogd dies. if you're lucky and the offending process dies too
meanwhile nothing else bad will happen.
And Rik van Riel, also in a
response to Peter, sounded a warning note of the discussion to come:
It is trivial to solve this problem in a satisfactory way for 99% of the situations. There has never been a 100% solution however and the last three times I sent such code to linux-kernel a (small) flamewar started.
If Linus indicates he's willing to accept something like my 2.2 oom killer patch into 2.3, I'll code something up.
Victor Khimenko also replied to Peter with a similar tune:
Ok. This discussion is serveral YEARS old. So do not hold you breath. There were lots and lots of discussion about this and fewdifferent patches are floating around for ages (in 2.2.15pre some OOM patches was tried; perhaps 2.2.15 will include one of them). But ALL patches are designed to help in case of run-away process and NOT protect against malicious user.
P.S. Of course if you'll be able to cook up patch and solve this outstanding problem still not solved after few years of exercises by Linux's memory wizards you are welcome. Just don't think it's so easy :-(
Still in the first day of the discussion, Rik replied:
On the contrary, putting together a solution to this problem is easy. The problem has been that people don't understand the issues involved and start a flamewar as soon as a patch (re)surfaces.
Also, making a solution that everybody agrees with seems to be impossible in this situation :)
There followed a really long discussion, in which some folks made suggestions, others told them they should go read a book, and various problems were elucidated.
Hector Facundo Arena was trying to get linux 0.0.1 going as a school
project, but was getting compiler errors. Actually the assembler would not
recognize the '-c' option. Paul Gortmaker replied, Unless you really have your heart stuck on v0.0.1 then I'd
suggest going to v1.0.9. It is still super small (tarball fits on a floppy
with space to spare!) which should make it appealing for school research and
a while back I hacked on v1.0.9 so that it would build (and run!) on a more
current linux system (like gcc-2.7.2 and libc5, which was current at the
time). You should be able to find it on linux ftp archives (look for
linux-lite).
Andrew Pam noticed that Alan Cox's Task List for 2.4 did not include the
fact that APM suspend no longer worked on the Sony VAIO PCG-505TR with
recent kernels. He urged, If APM suspend is broken,
then since ACPI suspend isn't expected for a while yet I would be completely
unable to suspend my laptop with a 2.4 kernel - which would prevent me from
using the 2.4 kernel series until it is fixed.
Alan pointed out that
ACPI would usually be off by default, and asked if suspend would work on
that machine, with ACPI off, and APM on. Andrew replied that no, it would
not work, and he'd received email from someone else with the same problem.
Another person replied to Alan, saying that on his X505SX, suspend, standby,
and hibernate all worked fine. Andrew replied that he was unable to reliably
reproduce the problem, but he had received more emails from people
experiencing the same thing. End of thread.
Andrew Morton reported that his bogomips were calculated at twice their
normal value under 2.3.99-pre1; he replied to himself, I see now that if the CPU has a timestamp counter the loops_per_sec
is in fact cpu cycles per sec and is hence higher. Is this a plot to make
people think 2.4 is faster?
Horst von Brand replied, Oops, you found out... now we'll have to kill
you.
And Alan Cox also replied to Andrew, 2.2.15pre also does it. Its required for some of the upcoming
processors.
Elsewhere, he clarified, Its
-BOGO- mips. Its a bogus meaningless indication of process speed. We've
changed the way we measure it for delay loops to use the TSC on chips that
support RDTSC.
Pavel Machek posted a patch, and objected to the
previous situation, But it is still broken. Let
laptop boot in maximum powersaving mode (low bateries will do the trick on
my toshiba), then plug AC in. Suddenly, all your udelay() loops take only
HALF of expected time; that's problem. I've got a code which detects such
events, warns, and recalibrates.
There was no reply.
Someone reported that under 2.3.99, 'MAKEDEV' would return "major_pty/m%d=2: No such file or directory" errors. Nick Holloway (former 'MAKEDEV' maintainer) explained that 'MAKEDEV' read '/proc/devices', which in turn looked like this:
2 pty/m%d
3 pty/s%d
4 tts/%d
5 cua/%d
He pointed out that this would be meaningful if 'devfs' were installed, and
that '/proc/devices' had had this format since 'devfs' had been included in
2.3.46; Alan Cox replied, That change is right - but
only if devfs is included. If devfs is not present the old names should be
reported by /proc/devices IMHO.
And Theodore Y. Ts'o volunteered,
I was tempted to do this for the serial
driver, but was concerned people (especially Linus) might not accept the
extra #ifdef's. I'd be happy to fix this for all of the tty devices if folks
think it's a good idea.
Anders Peter Fugmann reported that his Xircom 10/100 Mbit PCMCIA model
rbe-100 network card wouldn't work on his Compaq Armada M700 notebook, since
2.3.37; Jeff Garzik replied, The Xircom Tulip
lookalikes currently have known problems due to the death of tulip_cb. A fix
should appear this weekend, but it not present at the moment...
A
little while later, he posted a
patch and added, You can now use the
xircom_tulip_cb driver in kernel 2.3.99-pre3-pre3 or later, provided you
have this patch. (this patch has been sent to Linus, so it should appear in
the next kernel release...)
Anders replied that the patch had
already been included in pre3-6, and worked.
Donald Becker quoted Jamie Lokier as saying, I
wrote and posted an open-by-inode extension to ext2 about a year ago. You
simply open <fs>/.inode/<number>. But nobody was interested, so
I guess there isn't much demand after all.
In the same quoted text,
Horst von Brand replied to Jamie, Open by inode
allows to completely bypass placing files in non-x directories, thus
breaking security big time.
In reply to this, Donald mentioned in his post to linux-kernel, that a module existed to allow opening inodes by their inode-number; but he warned:
I mention our implementation only as a point of interest. This is *not* a general purpose mechanism. There is no reason to provide this as a kernel feature.
Most filesystems get *really nervous* when you access an inconsistent inode, and some even become unhappy if you merely reference a inode with a zero count. We only use it with devices that are marked unwritable, preferably with a hardware mechanism or loopback mounted.
Needless to say, any mechanism that so readily cause kernel corruption is available only to 'root', so the file security issue never even needs to be considered.
Jamie replied:
My patch is for ext2 only. It adds a new ext2 attribute meaning "this is an open-by-inode directory". So you create .inode in a filesystem, chattr it, and then .inode/<number> refers to a specific inode in that filesystem.
Being ext2-specific, the patch ensures the correct behaviour when you try opening a non-existent inode: the entry in .inode doesn't exist. A little care is needed to avoid negative dentries here.
Because this works, it is safe to use on writable filesystems. Access through .inode is determined by the permissions on that directory as usual, and of course access to the files and directories themselves is determined by their permission as usual too.
It seems to work very well, but I don't have a use for it so I've never given it a thorough test.
My patch is better than Donald Becker's for another reason: you can use it over NFS ;-)
Theodore Y. Ts'o replied:
Linus hates the ability to do this, despite the calls from some application programs to be able to be able to do iopen(). I've sometimes been tempted to do something like this, but I suspect Linus and/or Al Viro would burn an image of me in effigy. :-)
Note that the ability to set the "open-by-inode" attribute had better be allowed only by root, since being able to open by inode can completely bypass filesystem hierarchy security. (Consider a publically readable file located in a mode 700 directory. It wouldn't be accessible because of the mode 700 directory, but someone who could open-by-inode would be able to gain access to it.)
Jamie agreed that only root should be allowed to set the "open-by-inode"
attribute, and had the last word, with, Well, it's
not really any business of the VFS or the kernel. It's just part of the
filesystem's namespace. So the ext2 maintainer should be making these
decisions not Linus or Al Viro ;-)
Daniel J Blueman was having trouble booting Linux on his greater-than-8-gig harddisk. He knew that 'lilo' version 12 would not support this, and asked what would. Several people suggested the 'grub' bootloader, but Patrick J. Kobly reported that he had dealt with the problem several times and learned that 'grub' would definitely not work. But Chris Wedgwood said that 'grub' seemed to support large drives as of February. There was no reply to that, but Michel Catudal said that he seemed to recall a newer version of 'lilo' that would handle large drives, although he hadn't checked it out. Werner Almesberger confirmed this, and gave a pointer to John Coffman's 'lilo' version 21-3.
Michael Harnois posted a one-line patch to 'drivers/net/tulip/tulip.h', to
include 'asm/io.h'. Jeff Garzik thanked him, and Paul Laufer added, If you do this, you might as well remove the
'#include <asm/io.h>' from files that '#include "tulip.h"'.
Unless there is a good reason to not do so?
he posted a patch, and
Jeff replied, looks good to me, applied locally...
will test tomorrow along with a few other things.
Erik Arjan Hendriks wrote a module that would load and start a new Linux
kernel from a running Linux 2.2.x system. He gave a link to code and documentation,
and added, A limitation right now is that
it doesn't handle reboots of SMP boxes. That seems pretty hairy. Any
comments on the code and/or suggestions about what to do with SMP would be
greatly appreciated.
Alan Cox replied, The
problem with the SMP case is you need to spin the other processors (you
might find the MP1.4 bios writers info very useful since it basically tells
you what is expected). You'd have to find somewhere to hide a small piece of
code across the reboot (eg in the low 4K or EBDA). The bios is the low 1K
from memory so putting it at the end of the 4K we preserve ought to
work.
Ronald G. Minnich said he wanted to talk to anyone working on
that. Elsewhere, Erik said to someone else that he had previously done no
work at all on the SMP case, but planned on checking out the MP1.4 bios
writers info, now that Alan had pointed it out.
Per Lundberg reported that the VCD format seemed to be unsupported under
Linux. He asked why this was so. A lot of people replied, saying that it
most definitely was supported, and Jens Axboe put it, It's not unsupported, it's just not supported through the
regular block device interface.
Everyone named software players for
VCDs; and Quang Nguy gave pointers to some links
Steffen Kern added, the more important question
(for me) is, how to write video cds? i have mpeg1 video files and want to
burn one....tried to burn one file directly as a XA2 track using
cdrecord..the result were a lots of data overrun detected messages from the
kernel... is there anyone who successfully burned a video cd and can tell me
how?
Brian Litzinger replied:
I know how and have done it. Sadly I paid $350 for the knowledge and signed an NDA.
One of the confusions that people run into when dealing with VideoCDs is that there are two TOCs (Table of Contents) tables on a VideoCD. One is for use by computationally advantaged mechanisms, such as computers, the other is for computational disadvantaged mechanisms such as VideoCD players.
The former is a file system by any reasonable definition.
He offered this advice:
There is a book called the 'Green Book'. It has all the answers in it. You can buy it from the Phillips/Sony consortium that owns the technology, and from that you shouldn't have any troubles making VideoCDs. You might be more interested in the newer Super VCD standard.
Just use Google and look for 'VideoCD Green Book'. There are other books, such as the 'White Book' which would probably be helpful too.
Most of the VideoCD player software I have seen are what I would call rippers. They basically know how to find the mostly MPEG 1 compliant video stream on the VideoCD and suck it off, skipping the TOCs all together.
Paul Burkacki asked about porting a character driver from 2.0 to 2.2, and Augusto Cesar Radtke gave a pointer to Richard Gooch's Porting To 2.2 page. Ed Taranto (also porting a driver) said this was a great page, but he wanted more detailed information about specific changes relating to his driver. There was no reply to this, but elsewhere, someone suggested porting to 2.4 instead, since it was almost out the door.
In the course of discussion, Jeff Garzik asked, If
we are adding ELAN support to the kernel, has anyone tested David Hinds'
SC300 PCMCIA driver?
David replied:
I've just been sitting on that, because after I wrote it, no one (including the people who paid me to write it!) seemed interested in using it. And the company that paid me for it never got around to sending me the prototype hardware, so it is completely untested.
If someone wants to look at it / test it / port it to 2.3, I'll send it to them. But I don't really want to spend more time on it if there is no evidence that it will ever be used.
Myles Uyema asked if the stable series supported NFSv3 as a client. Neil Brown gave a status report:
Yep. It is in hand. You can get patches for 2.2.14 for both nfs client and nfs server at
ftp://nfs.sourceforge.net/pub/nfs/dhiggen-2.2.14
Hopefully this will all go into an early 2.2.16-pre release.
The server stuff is all in 2.3.99pre3. The client stuff is being merged in now.
He added, Trond
[Myklebust] is the guy who has been doing the NFS client improvements, including
NFSv3.
Bert Hubert announced his intention to write an iproute2 & netfilter
HOWTO, and asked if any similar projects existed. Marc Mutz recommended
asking the Linux HOWTO Maintainer; Erik Andersen replied to Bert, and gave a
pointer to Linux 2.2 (Mostly
Networking). Someone else replied to Bert with a pointer to IP Quality Of Service On
Linux, a tutorial given by Jamal Hadi Salim at the 1999 Ottawa Linux
Symposium; and Bert replied, This is really good
stuff. Hard to find with a search engine however because all the text is in
images. Thanks.
Paul Rusty Russell replied to Bert's original post:
Netfilter HOWTO has been obsoleted by a clean division between:
- Networking Concepts HOWTO
- 2.4 Packet Filtering HOWTO
- 2.4 NAT HOWTO
A 2.4 Routing HOWTO would complete the set. My preference would be for a HOWTO which doesn't assume anything beyond the (elementry) stuff in the Networking Concepts HOWTO.
Not an easy task though: this HOWTO could easily run to 10k lines and still not be complete.
Bert gave a pointer to what he had done so far, and elsewhere, reported on his progress:
Work is progressing well. Some people have mailed that they are willing to help. Gregory Maxwell has offered to send his work so far and told me that he has lots of real world examples, which suits me just fine :-)
The idea currently is to refer to Rustys netfilter HOWTOs as an introduction, and then explain how the 'mark' ability can be used to guide iproute2 and tc to route & shape your traffic, which is then described.
I'm currently studying CBQ so I can give a very short introduction on it. The main point of the HOWTO however is 'hands-on'.
Charles C. H. Jui posted a patch and reported:
After a lot of struggle and lack of useful information from Creative Labs North America, I have stumbled onto the secret of running the CREATIVE DVD-RAM RAM1216S drive under Linux kernel 2.2.
In thoery, a patch exists for Linux kernel 2.2.1-2.2.12 for the CREATIVE DVD-RAM drive, and support is built into kernels 2.2.13 and 2.2.14. Please see, for example, http://www.bitwizard.nl/dvd/.
Alas, when I try either patching an older kernel or running the new ones, the drive would be properly recognized, but when I attempt to write to it, it would start "clicking" and then hang the SCSI bus.
In looking more closely at what people reported on the web, this patch (and the support in the latest kernel) are for the Creative DVD-RAM RAM1220S. Whereas what I have is a RAM1216S. I called up Creative and theyn drew a complete blank. The Technical Support folks have no information on the 1216S at all--they in fact claim the drive is not marketed in North America.
Looking closely at the physical appearance of the drive, I decided the 1216S must have come from a different OEM source than the 1220S. The 1220S is an OEM from Panasonic/Matsushita. I looked at other drives and discovered that the front and back panels of the drive are similar to the Toshiba SD-W1101 and SD-W1111 DVD-RAM drives. The fact that both drives shipped with a metal pin to force the cartridge to eject was the smoking gun.
I t turns out that Reed Meyer of Yale Astronomy had determined that the SD-W1101 drive had a special problem. It does not recgnize 6-byte SCSI commands. Please see, for example, http://www.uwsg.iu.edu/hypermail/linux/kernel/9908.3/0738.html, for a copy of the original posting.
The fix is therefore to revert back to 10-byte SCSI commands. Reed Meyer had posted two patches. One was a patch to recognize the drive as a removable disk (which the previously mentioned patches and the new kernels already addresse), and a second was the patch for sd.c. Both of these patches are for 2.2.11.
I attach below the patch for sd.c under kernel 2.2.14, which is the current stable kernel. This patch did the trick. I did still have to follow the instructions that a block size of 2048 (-b 2048) is needed for both "fdisk" and "mke2fs".
I have since attempted to call both Creative and Toshiba North America to inquire about a firmware upgrade (I really don't like messing with sd.c). Creative again has no information about the drive, even though it hastheir name on it. Toshiba simply said that they do not support OEM'ed products-talk to Creative.
Daniel J Blueman gave a link to CD-R, CD-RW, DVD-ROM and DVD-RW firmware. Adam Heath also replied to Charles, confirming that the drive had always been a problem for him. But Trying Charles' patch actually made things worse for him. Before the patch, he couldn't write to the drive at all under 2.2.14; and could only make ext2 or reiserfs filesystems under 2.2.15pre15, but couldn't write any files. But 2.2.15pre15 with the patch applied, caused 'mkfs.ext2' to try to write beyond the end of the device.
Rick van Rein announced a patch (his first kernel patch) to allow the use of damaged RAM chips. He gave a pointer to the patch, and described:
My computer currently runs smoothly with two DIMMs that were considered dead, just because they suffered from static discharge. A RAM checker told me what sections of the RAMs were indeed dead, and all the rest could be exploited.
I can use 61 MB out of 64 MB, which is a great result, and good for trees. My main concern regarding trees is not reuse of RAM that suffered from static electricity, but to be able to use RAM in spite of manufacturing errors; a very large portion of RAMs (95% of the production?) must now be discarded of due to such errors. Trees don't like that. Neither do I.
Richard Gooch took exception to his use of the term trees, and Val Henson
replied, If you accept the (somewhat goofy) use of
"trees" to mean "the environment in general," it makes sense. I recently
read a book on microchip manufacture and visited the Intel plant near
Albuquerque. In short, chip manufacture is "resource-intensive." I recommend
learning the basics of microchip manufacture to any curious computer
person.
Regarding the actual patch, Bert Hubert pointed out, It may interest you to know that the venerable ZX Spectrum (Possibly
known als a 'Timex' to US viewers) already employed this technique for all
of its 16384 bytes of RAM. Sir Clive bought chips with single errors, and
only used the ones where the error was in lower part of the chip (I
believe). He then modified the Spectrum to only use the upper part.
Someone replied privately to Rick, asking about performance measurements with and without his patch. Rick quoted the post and replied that he didn't notice any difference in normal use, but that formal testing would be difficult because, without the patch, he couldn't use his broken RAM chips, and didn't have identical broken and unbroken chips to compare against each other. Also, he pointed out that the quantity of RAM would be different for the broken and unbroken chips, which would affect the results as well. He didn't discuss benchmarks done with or without the patch on a system with only healthy RAM chips.
Brad Whitehead asked about source routing in Linux. He described his
situation, I have two available routes out to
the internet. The branch occurs after several hops. eg. Packets travel the
same route for hops 1, 2 and 3, but then can be routed either through router
4 or 5. I dont have permission (access) to change the routing tables on any
of these routers. I would like to be able to choose between router 4 or 5
on-the-fly. eg. if router 4 goes down, then I would like to be able to
switch the route to use router 5.
He added that if this was not yet
possible, he'd volunteer to code up a general solution that all could use.
Michael H. Warfield replied at length:
Source routing has been in the kernel for a long long time. There use to be configuration option to suppress or prohibit source routing (since it is a security hole) but that option disappeared many revs back. I just glanced at net/ipv4/ipoptions.c and the code for IPOPT_SSRR (strict source routing) and IPOPT_LSRR (loose source routing) are still there. I don't know how they are enabled and disabled at this time. I would guess maybe a proc or sysctl interface much like forwarding became.
That being said... The chances of you getting source routing to work over a significant path in the net are extremely slim. You say you don't have control over the routers which determine which route to take. Chance are very good that one or more routers along that path are going to prohibit source routing. Many routers, concentrators, and terminal servers are now dropping all source routed packets as their default (or possibly only) configuration. Manufactures and ISPs have come to recognize the security risk present in unrestrained source routing and have stopped supporting it. You may get source routing to work in Linux only to discover that you still can't get it to work on the net.
The reason I know about this is that I'm the Senior Researcher and Fellow at Internet Security Systems on the X-Force. One test that we have in one of our products is a test for source routing bypassing a firewall (clue alert - guess where the security hole is). I've had source routing working in a test lab to demonstrate the test, both positive and negative. This was many kernel revs back, but I was able to use a "source route enabled" version of telnet on Linux to validate when we had source routing enabled on another Linux box and when we had it disabled. Linux is one of the few system, at the time, that made it relatively easy to enable it and disable it.
In the lab is one thing. I have yet to ever see it work past an outside ISP. Everything, and I do mean absolutely everything, in the path from your source to your finally destination must permit source routing options. If even one router or one dialing server blocks it, it won't work at all. Even if they are not specifically called out as a host on the loose source route, they can still block the packet with the source route option, and many already do.
He went on, what it sounds like is that you
want to set up a source routing table in the kernel to source route packets
even if the app has not set the source route option on the socket. This
would be a bad thing. Even if you could get it to work, what would you do if
the application DID set the source route option. This has always been left
up to the application to enable and specify on a socket by socket
basis.
And concluded, Look
elsewhere for your solution.