From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F233CC31E5B for ; Tue, 18 Jun 2019 17:46:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CBCDD20B1F for ; Tue, 18 Jun 2019 17:46:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZiTnctxg"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="KfKzUrNO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CBCDD20B1F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fUoYldzmk7m4ZINvXLZUQtRu1f8jBITCVMTUhtZvtmQ=; b=ZiTnctxg9ChgqP P/AYHSZU71/k1W8aSSDXt3dhoqDzpzkKMJQ02VjnAKzMK+XYH9WeC3D/61KdUfD3k7OhwrjGgNbA9 1sueMJArnFc6270bVDk6xDd/24wigh10hcoiQE86Xs8yEyiYY2JUmqyGWjC1D/q0vQ93hKErMf0FZ 5496aj84quKXY+YDukS4s/ANzUH0Iu24Ufbmk71s64I28rzcb1+ZlxsJyUwV/9wnVSe+Sxu1ZbgiA 5apyrRJSkRAliTV4YHRmhBrUaStpIhLZOG3yy20WdELfOvhxL/Y0hw3a/SxpV7eUoOXix6yJezAq2 AQqhmUUoqppfRP0OZdYw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hdIBu-0002bV-TI; Tue, 18 Jun 2019 17:46:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hdIBs-0002b9-FG for linux-arm-kernel@lists.infradead.org; Tue, 18 Jun 2019 17:46:41 +0000 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 8C1F920863; Tue, 18 Jun 2019 17:46:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560880000; bh=9SFIGqVkYnOiCP5yLgl1678SefgAZl/mMS63NLlXlcg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KfKzUrNOb3B2OUNT2v8wAZwCp5TB7RGc+r9C/SGz/rnF10fKRRU7ZtcJjANzWPn/H X+0+Fo2tjt2rROzCMzEKBoVSV6C/KUGsF7BVrAYPwidLAKl/9STj8TYrjWTJRTBSPo 2E1GPZMjV6guaQy0dg0AcN6UqO2HfdGzBKAUBG3Y= Date: Tue, 18 Jun 2019 19:46:37 +0200 From: Greg Kroah-Hartman To: Mathieu Poirier Subject: Re: [PATCH] coresight: cpu-debug: no need to check return value of debugfs_create functions Message-ID: <20190618174637.GC3649@kroah.com> References: <20190618155246.GA17788@kroah.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190618_104640_541933_8C94402E X-CRM114-Status: GOOD ( 19.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexander Shishkin , linux-arm-kernel , Suzuki K Poulose Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 18, 2019 at 11:23:25AM -0600, Mathieu Poirier wrote: > Hi Greg, > > On Tue, 18 Jun 2019 at 09:52, Greg Kroah-Hartman > wrote: > > > > When calling debugfs functions, there is no need to ever check the > > return value. The function can work or not, but the code logic should > > never do something different based on this. > > Looking around in the kernel there is no shortage of instances where > the return value of debugfs functions are checked and the logic > altered based on these values. But there are also just as many that > don't... It also seems counter intuitive to ignore the return value > of any function, something that in most case is guaranteed to raise > admonition. In my tree, those instances are almost all gone. I've also posted over 100+ patches in the past few weeks to clean this up. > That being said I am sure there is a good reason to support your > position - would you mind expanding a little so that I can follow? No kernel code should ever care if debugfs works or not. No user code should ever require it for normal operation either. debugfs was written to be simple and easy to use, no need to check any return values at all. Any return value of a debugfs call can be fed back into another call with no issues at all. Also, due to some debugfs core changes a few kernel releases ago, the checks: if (!debug_debugfs_dir) { ... if (!file) { can never trigger as debugfs_create_dir() or debugfs_create_file() can never return NULL (and in the past, it almost never would either). So as it is, that code isn't correct anyway (my fault, I know, hey, I'm trying to fix it!) I'm trying to make things simple, and easy, and impossible to get wrong. I know it goes against the normal "robust" kernel development mentality, but there is no need to ever care about debugfs at all. The reason I started all of this is that we have found places where userspace, and the kernel, was depending on the proper operation of debugfs. In one horrid example, a device would not display the batter level if debugfs was disabled. In another case, the kernel was actually relying on a debugfs call to fail in order to handle some logic the subsystem should have been doing on its own. All of that has now been cleaned up, and I am working on making debugfs just not return any values at all to prevent this type of mess happening again. And hey, I am removing code, here's my current tree as a diff from what is not already merged into linux-next: 301 files changed, 1394 insertions(+), 4637 deletions(-) that's always a good thing :) Hopefully this helps explain things better. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel