[lkml]   [1999]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] inode leakage again
    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?

    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;

    int fd;

    if (!(i++ % 100))
    if (mkdir("p", 0700) < 0)
    if (chdir("p") < 0)

    snprintf(filename, 20, "%d", rand());
    fd = open(filename, O_CREAT|O_EXCL, 0600);
    if (fd < 0)

    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

    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
    >(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! 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.


    Andrea Arcangeli

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [W:0.026 / U:5.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site