Re: [PATCH] 2.3.34/pre-2.3.35-3 ramdisk/initrd NOT as a

Tigran Aivazian (tigran@ocston.org)
Mon, 27 Dec 1999 13:33:15 -0800 (PST)

On Mon, 27 Dec 1999, Andrea Arcangeli wrote:
> >I am sorry to say this but I get those OOMs even with your patch.
> >I have 48M RAM on this P133 and all I have to do is to dd 2 22M files to
> >/dev/ram0 and /dev/ram1 respectiely. This is on
> >2.3.35-pre6 + your patch below.
>
> So that's perfectly normal. That's a different issue in the ramdisk driver
> this time. You can as well create a ramdisk of 200mbyte with your 48Mbyte
> system. Then while you run `cp /dev/zero /dev/ram0` you must expect to to
> out of memory because you can't allocate 200mbyte of ram, you only have
> 48mbyte of ram (I can't make a patch to enlarge your hardware memory, if
> somebody has such a patch I need it too ;). You simply shouldn't do that.
>
> What instead I fixed is the case where you are doing a very normal thing
> that must work. You have say 40mbyte of ram in your system and you have
> only one ramdisk of 20mbyte. This is the usual case of a ramdisk used as
> root device after linuxrc returned. Then you run a mke2fs on a 200giga
> harddisk and you get mke2fs killed by OOM. I got 2.2.x reports for this
> and for now I suggested to simply decrease the bdflush dirty limit to 4%
> and that fixes the oom fine too as expected. I'll provide the real fix for
> 2.2.x too RSN.
>
> Andrea

Hmm, no, I really disagree with you on this issue, Andrea. Let me change
the scenario slightly so that it becomes clear why I believe this is
unacceptable.

First of all, when I make a filesystem on a block device I don't modify
every single block of that device so it is perfectly possible to create a
64M ext2 filesystem on a ramdisk on a 48M physical RAM machine.

Now, the root mounts it somewhere and creates a subdirectory to which a
non-privileged user can write so a non-privileged user starts creating
files in it and easily causes out of memory bringing the box down, fscking
all filesystems etc etc.

I hope you are not going to tell me "then use quotas on all ramdisk-based
filesystems", are you?

I still have not learnt enough of buffer cache internals to figure out the
way to solve this but if you (as someone who understands it better than
me) believe that the current framework of Linux Buffer Cache makes it
impossible then I believe we have a serious problem. And if so I will go
back to (now I understand a silly) idea of having vmalloc'd ramdisk, i.e.
until I understand how to solve this properly.

Does Linus think it is acceptable? Am I missing something fundamental
here? It clearly seems unacceptable to me, so I must be missing something
obvious :)

Regards,
Tigran.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/