From mboxrd@z Thu Jan 1 00:00:00 1970 From: SF Markus Elfring Date: Mon, 05 Jan 2015 21:55:16 +0000 Subject: Re: [PATCH 1/8] fs/9p: Deletion of unnecessary checks before the function call "p9_client_clunk" Message-Id: <54AB0844.5090405@users.sourceforge.net> List-Id: References: <530CD2C4.4050903@users.sourceforge.net> <530CF8FF.8080600@users.sourceforge.net> <530DD06F.4090703@users.sourceforge.net> <5317A59D.4@users.sourceforge.net> <54A01326.3050306@users.sourceforge.net> <54A06AB9.4020505@users.sourceforge.net> <20150105112206.GC15033@mwanda> <54AB02F3.5020308@users.sourceforge.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Julia Lawall Cc: Dan Carpenter , Eric Van Hensbergen , Latchesar Ionkov , Ron Minnich , v9fs-developer@lists.sourceforge.net, LKML , kernel-janitors@vger.kernel.org >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/ne= t/9p/client.c?id=D8282ea05ad119247122de23db7d48ad6098cfa2#n1448 >> http://lxr.free-electrons.com/source/net/9p/client.c#L1448 >=20 > What do you mean by "work in principle"? If I do not stumble on an unexpected name space issue from my static source analysis again, then I would see the linked function as relevant here. Its implementation provides a clear input parameter validation. > But you don't want to do a dump_stack for no reason. That would at best > be very misleading, and I would imagine be quite expensive. The error response is clear. Are any software developments efforts expected to clean-up the call stack for unwanted null pointers even more? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html