>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/