Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2453279pxb; Fri, 29 Oct 2021 01:30:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFOa9iSDoOaxl/uG3axSAaP8g9PuGz2Axkhu6MjXe6LFAHkFIh0BshZMj8JtEvkztVIs0t X-Received: by 2002:a05:6402:2690:: with SMTP id w16mr13575953edd.372.1635496245530; Fri, 29 Oct 2021 01:30:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635496245; cv=none; d=google.com; s=arc-20160816; b=vlxOL7f/7sAIWEEmeOC7y5OuexcUxuvr4ibqIDy9eW3600jfneDs2xTGq/4EXpB0sb ESE3lZwqhVMVn7eiC1sjbysAqBSK1NIdHErzcykri4L+LgUN+Q5sCNd2YeYBydalxSDY 6GDQdUJbFXccQdyBuFHV5O3KER6dKvzhGS9X9jEJQ4UOCPb2QAluc6r8+jTx4kaObZ5X ayAyhctIUPC28a6zGtzfBi8ar07T3lKBsCgbRh7eZkIc9K2qSC2n8gQoWgBbS7dMidel 82tSnEAGgT9MR2rC+xHOaq3OkZ0X+jgaf715HnFac5TfqidfEbfiiztMg9WFB5KtmZ2A eD0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=B8c1GSQZX0PHWlLxvPAg8J8zAkz2La0RWPA702Zvrm8=; b=IRVuESyRnk8MRIzuUNG+qy1kKEVGXNOhNbiQZ+PxWrEuszRVFBvP47j5Iwz5ae5Fe7 eRioxPLNtZs+ObndPlQI07CWqoRU/KXloCLViU02FeVlBu++c62xndB8O6GO7EEmAn7/ qlbqfGBEC6Clx6Xvq4hsAW5M99U2wfZxLumRSJTszDunSoAuZHwMTJWNyiVLKW237pyw So4Kf1aAzkn81iDKwDMJfxkSlAy2MeKExkITJAOjGE2XRR80XPPwEWx5njh6kKBfAQoA xKe/9ZTd+uZ6XlYQQQ0cCNVc1gDqC627fu8fTRgS2bwhFmQwKypUhjLgdOgNzbAFRJMK irAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g12si8636712edb.152.2021.10.29.01.30.18; Fri, 29 Oct 2021 01:30:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232381AbhJ2I2x (ORCPT + 99 others); Fri, 29 Oct 2021 04:28:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:42892 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232305AbhJ2I2x (ORCPT ); Fri, 29 Oct 2021 04:28:53 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id F2B776115C; Fri, 29 Oct 2021 08:26:22 +0000 (UTC) Date: Fri, 29 Oct 2021 10:26:20 +0200 From: Christian Brauner To: Muchun Song Cc: andriy.shevchenko@linux.intel.com, akpm@linux-foundation.org, sfr@canb.auug.org.au, revest@chromium.org, adobriyan@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] seq_file: fix passing wrong private data Message-ID: <20211029082620.jlnauplkyqmaz3ze@wittgenstein> References: <20211029032638.84884-1-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211029032638.84884-1-songmuchun@bytedance.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 29, 2021 at 11:26:38AM +0800, Muchun Song wrote: > DEFINE_PROC_SHOW_ATTRIBUTE() is supposed to be used to define a series > of functions and variables to register proc file easily. And the users > can use proc_create_data() to pass their own private data and get it > via seq->private in the callback. Unfortunately, the proc file system > use PDE_DATA() to get private data instead of inode->i_private. So fix > it. Fortunately, there only one user of it which does not pass any > private data, so this bug does not break any in-tree codes. > > Fixes: 97a32539b956 ("proc: convert everything to "struct proc_ops"") > Signed-off-by: Muchun Song > --- > include/linux/seq_file.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h > index 103776e18555..72dbb44a4573 100644 > --- a/include/linux/seq_file.h > +++ b/include/linux/seq_file.h > @@ -209,7 +209,7 @@ static const struct file_operations __name ## _fops = { \ > #define DEFINE_PROC_SHOW_ATTRIBUTE(__name) \ > static int __name ## _open(struct inode *inode, struct file *file) \ > { \ > - return single_open(file, __name ## _show, inode->i_private); \ > + return single_open(file, __name ## _show, PDE_DATA(inode)); \ > } \ > \ > static const struct proc_ops __name ## _proc_ops = { \ Hm, after your change DEFINE_SHOW_ATTRIBUTE() and DEFINE_PROC_SHOW_ATTRIBUTE() macros do exactly the same things, right?: #define DEFINE_SHOW_ATTRIBUTE(__name) \ static int __name ## _open(struct inode *inode, struct file *file) \ { \ return single_open(file, __name ## _show, inode->i_private); \ } \ \ static const struct file_operations __name ## _fops = { \ .owner = THIS_MODULE, \ .open = __name ## _open, \ .read = seq_read, \ .llseek = seq_lseek, \ .release = single_release, \ } #define DEFINE_PROC_SHOW_ATTRIBUTE(__name) \ static int __name ## _open(struct inode *inode, struct file *file) \ { \ return single_open(file, __name ## _show, inode->i_private); \ } \ Can't you just replace the single instance where DEFINE_PROC_SHOW_ATTRIBUTE with DEFINE_SHOW_ATTRIBUTE() and remove DEFINE_PROC_SHOW_ATTRIBUTE completely? Christian