>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?
The only place I can see that sync inode to disk and so that generate
freeable inodes is sync_old_buffers() that it's recalled only by the
update daemon. I don't want a kernel that base it's stability on the
update userspace daemon.
According to me you should able to leak 2.2.2-pre2 as 2.2.1. You could try
with a proggy like this (inspired to your original one):
/*
* Linux 2.2.[01] inode leakage exploit. 19990205 Andrea Arcangeli
*/
#include <stdio.h>
#include <fcntl.h>
#include <stdlib.h>
int main(void)
{
char filename[100];
int i = 0;
for(;;)
{
int fd;
if (!(i++ % 100))
{
if (mkdir("p", 0700) < 0)
{
perror("mkdir");
break;
}
if (chdir("p") < 0)
{
perror("chdir");
break;
}
}
snprintf(filename, 20, "%d", rand());
fd = open(filename, O_CREAT|O_EXCL, 0600);
if (fd < 0)
perror("open");
close(fd);
}
}
You can try to run this proggy on clean 2.2.2-pre2 with `update` killed
and see how much you can grow up the inode-nr (first value of
inode-stats).
To delete the produced tree you can do:
while :; do mv p/p d; rm -r p; mv d/p p; rm -r d; done
note, the deleting is slowww.
Then you can try the same on 2.2.2-pre2 + my inode patch.
I am sure that with my patch the inode-nr will not grow up. I am pretty
sure that without my patch it will grow up instead.
Don't run the proggy for a long time otherwise you could create a bit too
much of inodes only your fs ;).
>Now I am running memory hog that eats all my memory and 99% of swap,
>that's what happens with inodes:
>mordor:~# cat /proc/sys/fs/inode-state
>2058 1885 0 0 0 0 0
>mordor:~# cat /proc/sys/fs/inode-state
>2058 1885 0 0 0 0 0
>mordor:~# cat /proc/sys/fs/inode-state
>2058 1883 0 0 0 0 0
>mordor:~# cat /proc/sys/fs/inode-state
>2058 1882 0 0 0 0 0
>mordor:~# cat /proc/sys/fs/inode-max
>2048
>(I understand that the difference between inode-max and inode-nr
>in this case probably due to more than one inode in a page)
Yes.
>Yes! 1882 inodes goes as "freeable", but they are not shrinked and still
>use memory, that otherwise can be used by my programs, that do not need
>such a big inode cache this time.
Infact. 1882 is wasted memory. For this reason the fs try to take the
number of unused inodes close to 0. But if you are deleting an inode, the
info you had on such inode can't be useful anymore, so better to put the
deleted inode in the unused list to reclain it back fast when you'll ask
for a new (not cached) inode.
I'll do some test tomorrow myself too.
Thanks.
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/