netdev - RE: SCTP seems to lose its socket state.

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: <063D6719AE5E284EB5DD2968C1650D6D1725D0F0@AcuExch.aculab.com>
Date:	Mon, 16 Jun 2014 14:46:22 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Vlad Yasevich' <vyasevich@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: SCTP seems to lose its socket state.

From: Vlad Yasevich [mailto:vyasevich@...il.com]
> On 06/16/2014 04:40 AM, David Laight wrote:
...
> > I wonder why commands get queued, rather than just actioned with
> > an immediate function call?
> 
> I don't know precisely why this decision was make in the 2.5 days
> (before my time).  If I had to guess, I'd say that it was simple
> to do at the time to provide a kind of buffering of multiple
> actions that resulted from processing of multiple chunks.

It rather goes with the arrays of function pointers rather than
switch statements for the per-state actions.

I'd guess that originally the list of 'actions' was made of dynamically
allocated blocks. They might have been processed much later on, but that
would give lots of timing issues.
The other possible reason was to make it easier to trace actions,
but any generic trace ends up missing the important 'state' info
so is almost useless after the initial debug.

If the actions get accumulated across chunks, then the list will
never be large enough.
OTOH I think they are now cleared after each chunk has been processed.

	David

--
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