Messages in this thread | | | Date | Wed, 29 Mar 2006 16:06:48 -0800 | From | Andrew Morton <> | Subject | Re: 2.6.16-mm1 leaks in dvb playback |
| |
adrian <adrian@smop.co.uk> wrote: > > On Mon, Mar 27, 2006 at 23:16:30 -0800 (-0800), Andrew Morton wrote: > > It's unlikely that the sock_inode_cache leak is related to the dcache leak, > > but we won't know until we know... > > Looks like this might be the same issus as "dcache leak in 2.6.16-git8 > (II)"... > > I think I've found the patch which causes the leak - it was the > "use fget_light() in net/socket.c" patch. I can't see anything > obviously wrong, although the patch changes the code so that in > sys_sendto and sys_recvfrom it now does a sockfd_put(sock) if the > sock_from_file call fails which didn't use to happen. That seems to > agree more with other bits of code, but I've no idea what is the right > thing todo.
OK, thanks, that helps heaps.
The code does look OK, so it that's the source of the leak then something subtle might be happening.
If it _is_ a fget/fput thing then I'd expect files_cache to be leaking too.
> One item I spotted whilst perusing the code is that in net/core/sock.c > in compat_sock_common_getsockopt, it checks if > sk->sk_prot->compat_setsockopt is NULL before calling > sk->sk_prot->compat_getsockopt (set vs get).
Ah. I guess nobody ever implements compat_getsockopt without also implementing compat_setsockopt but yes, it'd be tidier to actually check the thing we're about to call ;)
> I'll try and confirm tomorrow with a nice fresh build. The command > I'm using to test is "dvbstream -f 650166.670 -v 570 -a 571 -o > > /dev/null"
Thanks again. - 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/
| |