Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5089463imu; Tue, 29 Jan 2019 12:34:46 -0800 (PST) X-Google-Smtp-Source: ALg8bN7I9Atr89ypkgM6N22ESEDXurVjhM+XChS0v4yNwE2ereRh8cp0w9B1BIZELwbjbSyCZ3KC X-Received: by 2002:a62:f5da:: with SMTP id b87mr28095025pfm.253.1548794086014; Tue, 29 Jan 2019 12:34:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548794085; cv=none; d=google.com; s=arc-20160816; b=me3ebLPZBF42ATIIRdPisJZECFNtWqDj5wVfiv5Rc3Epq37Lvgukb7goAFjtR6ckot lwOp+966v1SmaqzR+AdH+CzUlFVmlhVQBeyHPaChluOn5YIoVMKkr7FdscQo70lqi4oO VqrH5e4LFulnqjPu3+qksHjhjcZesIi29wX/ZCn9fTbITmizdLHBufrywHXlR/92296D 5aU32v0Su/YjUNSCUUAcAjRj2b20QegjYw9L9D2ZDRWHu+1ykhqrL6EJAbU3TEswY/O9 DxsqPSckxBK3yzgzXIFDu6sbqMVtkUVyW0z5hmIUh3mdOqdC94WvO2lEIcI3aooIc5E4 pM2Q== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=UmiUSTgSat38Kz5OyIq2+KDdgAO34gIysAfUK3srYEo=; b=KBVJb4GAeM7vDIJpaNiQQ2yteVYXjaQNYlaGxhMuj7TpA8bH8r3o8Kx8+4MyrOoVTk IkhXyqW3YJLxAWwZOf7fMS+rwM8xQc6eBWMnSU5na9Wp2rd94X/kcvuDMVQVBRVfmrq3 5wLOsIPpE3IiLcq6cWagkgG76UcqS7WCFYCxzQGD8u/H43MAT101NX+48593VxSLWJds VeH66FkANwaZKQ2NtR8mpImX0N6xr75FWH2zIMU4HrfFK5RQmG09maaxvIDVFCLTF2x1 D01IzUeOB1LRXyx7wWap0Rm8q6V8o4z+TWoxG7M+oDPYEfWrd1viw9viuepSCEfwPlIG sckw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=xbHcsDb9; 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 e4si28879220pgk.127.2019.01.29.12.34.29; Tue, 29 Jan 2019 12:34:45 -0800 (PST) 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=xbHcsDb9; 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 S1727686AbfA2Ud3 (ORCPT + 99 others); Tue, 29 Jan 2019 15:33:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:59700 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726984AbfA2Ud3 (ORCPT ); Tue, 29 Jan 2019 15:33:29 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.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 C67A720881; Tue, 29 Jan 2019 20:33:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548794008; bh=DPvH4a8NS+v9FXY+mtxhNvQwoYBsLvv8TgIPjWa/rig=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xbHcsDb9z/t9SFcX7zbJvN0Y70JVgtoHVnofc5ApZrRHDseOF/6LXOxzrZT/DaNos DorLlUrMHz7AexuNH3hg/+0h8VKG6kaC1S+aSGG36dshtPMM1cb/HFR5bCuFQ7/dEt W2YU8l6kBJBV36AAypIa1G/iJw1Owiz1BwyS+NR8= Date: Tue, 29 Jan 2019 21:33:25 +0100 From: Greg Kroah-Hartman To: Dan Streetman Cc: linux-kernel , Seth Jennings , Linux-MM Subject: Re: [PATCH] zswap: ignore debugfs_create_dir() return value Message-ID: <20190129203325.GA2723@kroah.com> References: <20190122152151.16139-9-gregkh@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 29, 2019 at 02:46:30PM -0500, Dan Streetman wrote: > On Tue, Jan 22, 2019 at 10:23 AM 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. > > > > Cc: Seth Jennings > > Cc: Dan Streetman > > Cc: linux-mm@kvack.org > > Signed-off-by: Greg Kroah-Hartman > > --- > > mm/zswap.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/mm/zswap.c b/mm/zswap.c > > index a4e4d36ec085..f583d08f6e24 100644 > > --- a/mm/zswap.c > > +++ b/mm/zswap.c > > @@ -1262,8 +1262,6 @@ static int __init zswap_debugfs_init(void) > > return -ENODEV; > > > > zswap_debugfs_root = debugfs_create_dir("zswap", NULL); > > - if (!zswap_debugfs_root) > > - return -ENOMEM; > > > > debugfs_create_u64("pool_limit_hit", 0444, > > zswap_debugfs_root, &zswap_pool_limit_hit); > > wait, so if i'm reading the code right, in the case where > debugfs_create_dir() returns NULL, that will then be passed along to > debugfs_create_u64() as its parent directory - and the debugfs nodes > will then get created in the root debugfs directory. That's not what > we want to happen... True, but that is such a rare thing to ever happen (hint, you have to be out of memory), that it's not really a bad thing. But, you are not the first to mention this, which is why this patch is on its way to Linus for 5.0-final: https://lore.kernel.org/lkml/20190123102814.GB17123@kroah.com/ thanks, greg k-h