Date: Wed, 28 May 2014 18:56:19 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Julian Elischer <julian@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, dmitryluhtionov@gmail.com Subject: Re: svn commit: r266806 - head/sys/netgraph Message-ID: <20140528145619.GM50679@FreeBSD.org> In-Reply-To: <5385EED0.1010506@freebsd.org> References: <201405281315.s4SDFEvc061176@svn.freebsd.org> <5385EED0.1010506@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 28, 2014 at 10:12:32PM +0800, Julian Elischer wrote: J> On 5/28/14, 9:15 PM, Gleb Smirnoff wrote: J> > Author: glebius J> > Date: Wed May 28 13:15:14 2014 J> > New Revision: 266806 J> > URL: http://svnweb.freebsd.org/changeset/base/266806 J> > J> > Log: J> > Use M_WAITOK for the NGM_PIPE_SET_CFG control message. We expect it to J> > arrive from userland only. J> > J> > Submitted by: Dmitry Luhtionov <dmitryluhtionov gmail.com> J> what's to stop another node from generating it and sending it on? J> generally a message may come from anywhere. J> Just becasue YOU don't have module that J> sends messages to ng_pipe, doesn't mean there never will be.. J> also there are cases when the locking may force a message to be J> delivered asynchronously. I know that. After resolving many issues with netgraph, I feel that our policy should be towards putting some invariants on what events SHOULD come from userland only and which events SHOULD be serviced without memory failures. Current paradigma that messages are fully symmetrical and can come from anywhere are quite a curious thought experiment. I liked that for a long time. But in practice if we want to build a robust software we should make more strict rules of using it. You could disagree, but if you try to fix this particular one liner in the paradigma of "messages come from anywhere", then you will end up with smth like 20 lines of code to this particular module. Next comes the need to fix any software or script that sends NGM_PIPE_SET_CFG, it now should be taught of dealing with ENOMEM. So, instead of one liner you will bury yourself under tons of work. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140528145619.GM50679>