Return-Path: Received: from fieldses.org ([173.255.197.46]:58652 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753165AbdEIORJ (ORCPT ); Tue, 9 May 2017 10:17:09 -0400 Date: Tue, 9 May 2017 10:17:08 -0400 From: "J. Bruce Fields" To: Jeff Layton Cc: Christoph Hellwig , "Mkrtchyan, Tigran" , Trond Myklebust , Anna Schumaker , linux-nfs Subject: Re: [PATCH 02/32] sunrpc: fix encoder callback prototypes Message-ID: <20170509141708.GA18466@fieldses.org> References: <20170509092010.30752-1-hch@lst.de> <20170509092010.30752-3-hch@lst.de> <779451235.5133504.1494323029528.JavaMail.zimbra@desy.de> <20170509131108.GA15042@lst.de> <1494336641.2659.5.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: <1494336641.2659.5.camel@redhat.com> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, May 09, 2017 at 09:30:41AM -0400, Jeff Layton wrote: > On Tue, 2017-05-09 at 15:11 +0200, Christoph Hellwig wrote: > > On Tue, May 09, 2017 at 11:43:49AM +0200, Mkrtchyan, Tigran wrote: > > > just out of curiosity: you are talking about increasing type safety, but > > > at the same time replaces arguments to 'const void *data', which will accept > > > everything. Is there something special which I don't understand? > > > > Nothing special - cast are potentially dangerous in general, and > > function pointer cases are especially dangerous as there is no > > verify the caller and callee signatures match at all. As generic > > method call patterns need to have private data of some points they > > need to have a void pointer somewhere - either in the signature or > > as a pointer from a passed structure. For those the compiler at least > > can do some basic sanity checking, and good static analysis tools can > > even verify we get the proper object using whole program analysis. > > Strong ACK on all of this. Also very much in favor of these patches. Though I can't actually remembering seeing a bug here. So... > I've been bitten before (in userland code) by having a function that > took 3 arguments cast to something that took 2. So the callers ends up > passing in too few arguments, and the function then just ends up using > junk out of a register or off the the stack to satisfy the missing one. > Not fun to track down. OK, that's good to know. I'm more worried about the encoders and decoders themselves, but I don't know what to do about them. --b.