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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ