linux-kernel - Re: [GIT]: Networking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090616.033554.102149558.davem@davemloft.net>
Date:	Tue, 16 Jun 2009 03:35:54 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mingo@...e.hu, eric.dumazet@...il.com
Cc:	alan@...rguk.ukuu.org.uk, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT]: Networking

From: Ingo Molnar <mingo@...e.hu>
Date: Tue, 16 Jun 2009 12:11:32 +0200

> sure, here you go (i also added a stack dump, just in case it's some 
> kernel-internal socket open):
> 
>  [ifconfig:3516]: Creates X25 socket.
> 
> so plain ifconfig. Part of the ~1.5 years old net-tools-1.60-84.fc8.

Ok, ifconfig seems to open one of every socket type when it starts up.
That explains why an X25 socket is openned and then closed.

Now the question is why is the X25 socket released by a timer?  This
should only happen if some socket memory is still pending in the
socket buffers.

Wait, I know why this is triggering now.  It's Eric Dumazet's SKB
accounting optimizations.

So, I'll fix the X25 timer bug.  It's always been there, but
beforehand this deferred-via-timer x25 socket destruction path almost
never triggers.  So we never saw it.  Now it happens every time.

Eric can you sniff around and see what you think about this unforseen
(at least for me) consequence of your changes?  Socket layers that use
the current sk_wmem_alloc/sk_rmem_alloc value at destroy time to
determine if a socket can be killed immediately, or need to be killed
later via timer, will always see that dummy one byte allocation you
now put there.

Can you look into that?

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