lkml.org 
[lkml]   [2005]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory leak in 2.6.11-rc1?


On Wed, 2 Feb 2005, Dave Hansen wrote:
>
> In any case, I'm running a horribly hacked up kernel, but this is
> certainly a new problem, and not one that I've run into before. Here's
> output from the new CONFIG_PAGE_OWNER code:

Hmm.. Everything looks fine. One new thing about the pipe code is that it
historically never allocated HIGHMEM pages, and the new code no longer
cares and thus can allocate anything. So there's nothing strange in your
output that I can see.

How many of these pages do you see? It's normal for a single pipe to be
associated with up to 16 pages (although that would only happen if there
is no reader or a slow reader, which is obviously not very common).

Now, if your memory freeing code depends on the fact that all HIGHMEM
pages are always "freeable" (page cache + VM mappings only), then yes, the
new pipe code introduces highmem pages that weren't highmem before. But
such long-lived and unfreeable pages have been there before too: kernel
modules (or any other vmalloc() user, for that matter) also do the same
thing.

Now, there _is_ another possibility here: we might have had a pipe leak
before, and the new pipe code would potentially make it a lot more
noticeable, with up to sixteen times as many pages lost if somebody freed
a pipe inode without calling "free_pipe_info()". I don't see where that
would happen - all the normal "release" functions seem fine.

Hmm.. Adding a

WARN_ON(inode->i_pipe);

to "iput_final()" might be a good idea - showing if somebody is releasing
an inode while it still associated with a pipe-info data structure.

Also, while I don't see how a write could leak, but maybe you could you
add a

WARN_ON(buf->ops);

to the pipe_writev() case just before we insert a new buffer (ie to just
after the comment that says "Insert it into the buffer array"). Just to
see if the circular buffer handling might overwrite an old entry (although
I _really_ don't see that - it's not like the code is complex, and it
would also be accompanied by data-loss in the pipe, so we'd have seen
that, methinks).

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.098 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site