Messages in this thread | | | Date | Sun, 7 Feb 1999 15:22:49 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [patch] inode leakage again |
| |
On 7 Feb 1999, Linus Torvalds wrote:
>In article <Pine.LNX.3.96.990207035621.809A-100000@laser.bogus>, >Andrea Arcangeli <andrea@e-mind.com> wrote: >>On Sat, 6 Feb 1999, Oleg Drokin wrote: >> >>>This is after running inode hog. Fine to this point. (However in clean >>>2.2.2-pre2 the number is bigger, that's fine too as I have some free memory) >> >>It's not fine according to me. Could you try to kill your update daemon >>and see how much you can grow such number with many of your hog test? > >Umm? > > "Could you try to kill 'init' and see how long your machine survives > without running out of processes due to processes getting stuck in > zombie state?" > >If you kill the update deamon, your screwed. Don't do it. If you do >it, whatever happens is your own fault, and you only have yourself to >blame.
Personally I like that the kernel works fine even without update. I see update only as a `if you don't run it and you have a crash don't blame us for the fs damage'.
>So your whole point is meaningless.
I was asking for such experiment _only_ for know if I understood right how the inode syncing/freeing works.
My _real_ point is that with my ad-hoc proggy I am able to leak also 2.2.2-pre2 with update running. 5 sec (or more) is ethernity for a malicious proggy.
Here when all inodes are busy the machine survive fine, just tried (I see my message inode-max limit reached every time the allocation fails). Are you sure that in 2.0.x you was syncing back the dirty list as I do now, before failing to free the inodes on the inuse-list?
I can see though why you wanted to avoid failing in opening inodes. I think we could allow the root user to go throught allocating inodes. Should be a trivial implementation:
if (!capable of something) return NULL;
Do you agree?
Andrea Arcangeli
- 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/
| |