Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3161264ybc; Thu, 21 Nov 2019 04:19:45 -0800 (PST) X-Google-Smtp-Source: APXvYqyKtC4q4B5JKDMGaKsFkNmiL00zF72h6nUFJF+tmd0RqAVgrCkz4xm2rNsnVHxrPbYslyGR X-Received: by 2002:a17:906:601:: with SMTP id s1mr13658662ejb.287.1574338785498; Thu, 21 Nov 2019 04:19:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574338785; cv=none; d=google.com; s=arc-20160816; b=iN42DojPEzTKICNlA+4n8OeKz5N2AWCpPRDCr9wY2rEuirErcXajTIETPg7oM4SoZm iK+QNRu/sfmM+WIQ12jpuq8CNsWuDLFGakNdbbqDcjaieVPzSh9R5koctOO8Ay93MCpq Ru4oPiPLSeV4DcFfegQ7Pjeqk3HoBCBDB9qql+b2ktfyXwc6PP+BQ1vvpdHQpFMf73T2 CuNvNguips7t8APcoeUYSEDnq259TTJE6draLTt+wKhBLLiilHjnKOfBF9jpI4K+Meev X7Qe9y0oZ91PvbSzL3yJNjJpgOOkTyd4ldXQYy4RHx66wKK9zWbEQo5pI1CO2HQqbxlQ ypaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from; bh=FBrXxbmE/CfFalsxzLyicIr4AgAu8fSws9E9EScWBng=; b=hLRPtrVy45qbagmLCd6YMkRFfQ0KqRnfz610JNeFQDIxow8U/yv3eLQB9wkoLqE72j JljOk+GV5caaM72M4W8qSm6Ijl0tWfMB1OXahlBVaFUKfkc4SWPmSlryrAAt8gMgMKpv vLj+05KvEXokYb/Hlrka93qiOiB3OZiiz+Dx5fotk2bNXajH3Xyn8JZDj+exruuiSP9a uLDzyIegPRa0vZUTVWwhaImMvPOEKnhCqwUDkBuxZsxcVZHjU2e0ccYR69UfPIeNGPGe CsK+ohQmFX295KIUH9hlfWVFaYqQCPVh75ZpzaUrhPd7S09v6iWD9wXApzJKAjYuY0VU w9PQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-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 k4si1598451eji.269.2019.11.21.04.19.15; Thu, 21 Nov 2019 04:19:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726775AbfKUMSQ convert rfc822-to-8bit (ORCPT + 99 others); Thu, 21 Nov 2019 07:18:16 -0500 Received: from mx2.suse.de ([195.135.220.15]:32998 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726197AbfKUMSP (ORCPT ); Thu, 21 Nov 2019 07:18:15 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 2C9E2B033; Thu, 21 Nov 2019 12:18:13 +0000 (UTC) From: Nicolai Stange To: Stephan =?utf-8?Q?M=C3=BCller?= Cc: Arnd Bergmann , Greg Kroah-Hartman , linux-crypto@vger.kernel.org, LKML , linux-api@vger.kernel.org, "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Willy Tarreau , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , Andy Lutomirski , Florian Weimer , Lennart Poettering , Nicolai Stange , "Peter\, Matthias" , Marcelo Henrique Cerri , Roman Drahtmueller , Neil Horman Subject: Re: [PATCH v25 12/12] LRNG - add interface for gathering of raw entropy References: <6157374.ptSnyUpaCn@positron.chronox.de> <2787174.DQlWHN5GGo@positron.chronox.de> <3610406.x8mDjznOIz@positron.chronox.de> Date: Thu, 21 Nov 2019 13:18:10 +0100 In-Reply-To: <3610406.x8mDjznOIz@positron.chronox.de> ("Stephan \=\?utf-8\?Q\?M\=C3\=BCller\=22's\?\= message of "Sat, 16 Nov 2019 10:38:12 +0100") Message-ID: <87a78pl8xp.fsf@suse.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi Stephan, two general remarks on debugfs usage below Stephan Müller writes: > diff --git a/drivers/char/lrng/lrng_testing.c b/drivers/char/lrng/lrng_testing.c > new file mode 100644 > index 000000000000..5c33d3bd2172 > --- /dev/null > +++ b/drivers/char/lrng/lrng_testing.c > +/* > + * This data structure holds the dentry's of the debugfs files establishing > + * the interface to user space. > + */ > +struct lrng_raw_debugfs { > + struct dentry *lrng_raw_debugfs_root; /* root dentry */ > + struct dentry *lrng_raw_debugfs_lrng_raw; /* .../lrng_raw */ > +}; > + > +static struct lrng_raw_debugfs lrng_raw_debugfs; > + > +/* DebugFS operations and definition of the debugfs files */ > +static ssize_t lrng_raw_read(struct file *file, char __user *to, > + size_t count, loff_t *ppos) > +{ > + loff_t pos = *ppos; > + int ret; > + > + if (!count) > + return 0; > + lrng_raw_entropy_init(); > + ret = lrng_raw_extract_user(to, count); > + lrng_raw_entropy_fini(); > + if (ret < 0) > + return ret; > + count -= ret; > + *ppos = pos + count; > + return ret; > +} > + > +/* Module init: allocate memory, register the debugfs files */ > +static int lrng_raw_debugfs_init(void) > +{ > + lrng_raw_debugfs.lrng_raw_debugfs_root = > + debugfs_create_dir(KBUILD_MODNAME, NULL); > + if (IS_ERR(lrng_raw_debugfs.lrng_raw_debugfs_root)) { > + lrng_raw_debugfs.lrng_raw_debugfs_root = NULL; > + return PTR_ERR(lrng_raw_debugfs.lrng_raw_debugfs_root); > + } I think pointers returned by the debugfs API are not supposed to get checked for NULL/IS_ERR(), c.f commit ff9fb72bc077 ("debugfs: return error values, not NULL") or the the output from git log --pretty=oneline | grep 'no need to check return value of debugfs_create' (Also the above code is dubious: you're effectively returning PTR_ERR(NULL)). > + return 0; > +} > + > +static struct file_operations lrng_raw_name_fops = { > + .owner = THIS_MODULE, > + .read = lrng_raw_read, > +}; > + > +static int lrng_raw_debugfs_init_name(void) > +{ > + lrng_raw_debugfs.lrng_raw_debugfs_lrng_raw = > + debugfs_create_file("lrng_raw", 0400, > + lrng_raw_debugfs.lrng_raw_debugfs_root, > + NULL, &lrng_raw_name_fops);q CONFIG_LRNG_TESTING is a bool and thus, this debugfs file can't ever get removed. Even if it could, this inode hasn't got any data associated with it and so file removal would not be a problem for lrng_raw_read(). Please consider using debugfs_create_file_unsafe() instead to save debugfs from kmalloc()ing a proxy file_operations protecting your fops against concurrent file removal. > + if (IS_ERR(lrng_raw_debugfs.lrng_raw_debugfs_lrng_raw)) { > + lrng_raw_debugfs.lrng_raw_debugfs_lrng_raw = NULL; > + return PTR_ERR(lrng_raw_debugfs.lrng_raw_debugfs_lrng_raw); > + } Same comment regarding return value checking applies here. Thanks, Nicolai > + return 0; > +} > + > +static int __init lrng_raw_init(void) > +{ > + int ret = lrng_raw_debugfs_init(); > + > + if (ret < 0) > + return ret; > + > + ret = lrng_raw_debugfs_init_name(); > + if (ret < 0) > + debugfs_remove_recursive( > + lrng_raw_debugfs.lrng_raw_debugfs_root); > + > + return ret; > +} > + > +static void __exit lrng_raw_exit(void) > +{ > + debugfs_remove_recursive(lrng_raw_debugfs.lrng_raw_debugfs_root); > +} > + > +module_init(lrng_raw_init); > +module_exit(lrng_raw_exit); > + > +MODULE_LICENSE("Dual BSD/GPL"); > +MODULE_AUTHOR("Stephan Mueller "); > +MODULE_DESCRIPTION("Kernel module for gathering raw entropy"); -- SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg), GF: Felix Imendörffer