Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3232780yba; Tue, 16 Apr 2019 07:20:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqzN1LM6U70F91ykGZL8e/ROpEnU0tUctffI/KhONlgGLAIXJ6vk2PJqNgKHg3NKuEGQvRB8 X-Received: by 2002:a17:902:a706:: with SMTP id w6mr83379758plq.91.1555424454341; Tue, 16 Apr 2019 07:20:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555424454; cv=none; d=google.com; s=arc-20160816; b=Ych64QW7xUVP47zK3A5elc1y2q17p0UsFaSo/7wj4Riy+w51tGvchckvZxKAy9ArHH s0ZM5B+Bmx+EraAAsZhjujDuvrqZ0eE9QSRuWwQ/IdXWXclfoJWPmdfsFqUpMkJYTGjl f9fa9xlPLQ1E138ptYNu8rVlaBUyXiB6EEv/F/hGj1+XZarrUvp5G6uMXQOwzkhf/F4Q +l4zrilLXZN8SYH5XXn2FR45f490rN9xwVpwWS++6b1t+0HgNl9DTsdwa/KhQfd19z72 OsE0HXe77lreyvvmPo8mBGNBHMmQ2Fs2qMblyy5qB54i3T7Vu1oOF2oCbryS4WVUSc87 zfKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=gKLQKoaVXLvYCseDRjyEd4GoKzIzOixZJG/vcd1X8to=; b=so50RRArp5Jfs23OeRxeXbnKplyqQ1WXoXO+ZJvT/FCl1qNcAh4b6Hl8EjoQdDCfL0 jA9dolEbGJffjdt8EcoAHq5PbM6g/RCkcXZNLTXZF5ekk5YUNRn6KblCcF5MMOwy8EtA VCo8d5j9kpsRegfEdXry2rwnv6imfXP5bLCdGT6qMHzSDUOOYFBtGa2ziUJx1l1owbyW IJWzmtDAqvTQuKEyn5FXsmnpUpXdsDKrxwXbtKDHqG3NbqVzbKMIisKMde00e6boXCv2 ByautjVMwbdBAweu72dzONQ96GP2AHphnKjv4l5Aq5MWl/h2fecye5Y8kzT5fhVOb+gk s3kw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=IJ9Ugu4B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y8si47418123pll.313.2019.04.16.07.20.38; Tue, 16 Apr 2019 07:20:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=IJ9Ugu4B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728032AbfDPOT6 (ORCPT + 99 others); Tue, 16 Apr 2019 10:19:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:58736 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725796AbfDPOT5 (ORCPT ); Tue, 16 Apr 2019 10:19:57 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 57B4F223F9; Tue, 16 Apr 2019 14:19:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555424396; bh=tj2oqLYULvvLSyNlQMoQuuGucML1O57tO2NXSD6MMnM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IJ9Ugu4BLptS71Y5CUndU9to8xBxIx9YUjFVS3nLcFphIdrBMZDUJxUnCVUWEw9a2 vSEW5cqc+unS5wiqaxbjraJGKfzZR0TulGBDx32W9eUcJOkZTCAsDIFg0ousLmk1v0 AnH29CN1Hp3SLE5HZvFPL/vwhq4TRu69aFODtQK4= Date: Tue, 16 Apr 2019 15:29:25 +0200 From: Greg Kroah-Hartman To: "Life is hard, and then you die" Cc: Jonathan Corbet , "Rafael J. Wysocki" , Andy Shevchenko , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] debugfs: make return value of all debugfs helpers consistent Message-ID: <20190416132925.GA17483@kroah.com> References: <20190415082506.25610-1-ronald@innovation.ch> <20190415082506.25610-3-ronald@innovation.ch> <20190415084844.GA26101@kroah.com> <20190415232959.GC13033@innovation.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190415232959.GC13033@innovation.ch> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 15, 2019 at 04:29:59PM -0700, Life is hard, and then you die wrote: > > Hi Greg, > > On Mon, Apr 15, 2019 at 10:48:44AM +0200, Greg Kroah-Hartman wrote: > > On Mon, Apr 15, 2019 at 01:25:06AM -0700, Ronald Tschal?r wrote: > > > Since commit ff9fb72bc077 ("debugfs: return error values, not NULL") > > > almost all the debugfs helpers have stopped returning NULL. The lone > > > holdeout was debugfs_create_u32_array(). So fix that. > > > > > > Signed-off-by: Ronald Tschal?r > > > --- > > > fs/debugfs/file.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c > > > index ddd708b09fa1..bb706d073782 100644 > > > --- a/fs/debugfs/file.c > > > +++ b/fs/debugfs/file.c > > > @@ -999,8 +999,8 @@ static const struct file_operations u32_array_fops = { > > > * Once array is created its size can not be changed. > > > * > > > * The function returns a pointer to dentry on success. If an error occurs, > > > - * %ERR_PTR(-ERROR) or NULL will be returned. If debugfs is not enabled in > > > - * the kernel, the value %ERR_PTR(-ENODEV) will be returned. > > > + * %ERR_PTR(-ERROR) will be returned. If debugfs is not enabled in the kernel, > > > + * the value %ERR_PTR(-ENODEV) will be returned. > > > */ > > > struct dentry *debugfs_create_u32_array(const char *name, umode_t mode, > > > struct dentry *parent, > > > @@ -1009,7 +1009,7 @@ struct dentry *debugfs_create_u32_array(const char *name, umode_t mode, > > > struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL); > > > > > > if (data == NULL) > > > - return NULL; > > > + return ERR_PTR(-ENOMEM); > > > > > > data->array = array; > > > data->elements = elements; > > > > There is only one caller of this function in the kernel now, and it does > > not even care about the return value at all, so we should just remove > > the return value entirely as that's the easiest and best thing to do > > here. > > Interesting argument: since this is a helper/library function, and > therefore potentially used in the future by others, it seems to me > that consistency with the other functions and providing error feedback > would be important. Not if you never actually use the return value for anything :) > > I was going to start doing this slowly over time, but as you are > > touching the function now, might as well do it here :) > > Are you saying the plan is to make all these helpers return void? Yes, no caller should do anything "different" based on a return value of a debugfs call. Note, sometimes you do want to save off dentries for some files that you later remove, but that's it. thanks, greg k-h