Eric Lee / smarc-fsl-linux-kernel

31 Oct, 2005

1 commit

28 Oct, 2005

1 commit

24 Oct, 2005

1 commit

  • 8d3b35914   [PATCH] inotify/idr leak fix ... Browse Code »

    Fix a bug which was reported and diagnosed by
    Stefan Jones

    IDR trees include a cache of idr_layer objects. There's no way to destroy
    this cache, so when we discard an overall idr tree we end up leaking some
    memory.

    Add and use idr_destroy() for this. v9fs and infiniband also need to use
    idr_destroy() to avoid leaks.

    Or, we make the cache global, like radix_tree_preload(). Which is probably
    better. Later.

    Cc: Eric Van Hensbergen
    Cc: Roland Dreier
    Cc: Robert Love
    Cc: John McCutchan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

27 Aug, 2005

1 commit

  • 7c657f2f2   [PATCH] Document idr_get_new_above() semantics, update inotify ... Browse Code »

    There is an off by one problem with idr_get_new_above.

    The comment and function name suggest that it will return an id >
    starting_id, but it actually returned an id >= starting_id, and kernel
    callers other than inotify treated it as such.

    The patch below fixes the comment, and fixes inotifys usage. The
    function name still doesn't match the behaviour, but it never did.

    Signed-off-by: John McCutchan
    Signed-off-by: Linus Torvalds

    John McCutchan
     

22 Jun, 2005

1 commit

  • 589777eab   [PATCH] coverity: idr_get_new_above_int() overrun fix ... Browse Code »

    This patch fixes overrun of array pa:
    92 struct idr_layer *pa[MAX_LEVEL];

    in

    98 l = idp->layers;
    99 pa[l--] = NULL;

    by passing idp->layers, set in
    202 idp->layers = layers;
    to function sub_alloc in
    203 v = sub_alloc(idp, ptr, &id);

    Signed-off-by: Zaur Kambarov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zaur Kambarov
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds