Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2467088pxb; Fri, 29 Oct 2021 01:52:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz05GDAfdJdtU1k0j3jjWSXl8EPs84JQGf9qhER2LPh58d6BgsJZ1D1lxChiDcPIK4Q4z4m X-Received: by 2002:a05:6a00:228e:b0:47c:18b1:b807 with SMTP id f14-20020a056a00228e00b0047c18b1b807mr9362807pfe.55.1635497561989; Fri, 29 Oct 2021 01:52:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635497561; cv=none; d=google.com; s=arc-20160816; b=BXWzZsr7yrx/caeUwk/+/SeVCfKzfJne94RYcd6gg62zEl75dlK0sgHR51yxQxvqSw fNnHQVipeTCUlr/9fjqDY3Q41GcaviY+QO9qNc786oTF1V7z3w0bofuRQai+vyU34efE fEnMjvp/oJuQXh8D1xsEnM+CeOaWqthjdYkMsa0BZbqQNRQlUa5NwyxESWykdrh5TvtX 3pfZvXE4lWwtxY3AOz7zlJrpSJ8xF80CF8QriZvTnyMPI2mmAz4i185O1aMuK3Qhz1Pj y6k24tNXDgTCs/7JdGbpSGmXhZSKYi0KtNCGSp4I/y5fVry4HOAPOyLJQmM9M0HaHJgc Usnw== 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=qzB9wVTsB9b2VK/TYc1Rd6aXEVlX1gcqZenZQEpFWaI=; b=JpitMqTNLMA885dYb2iH7MwOL907OiBsO/XOvjhVy/AC93Lpl10ihcKfCfPtZElpnn RNliK9PwgVplBRGPsqTMYvqrMS2kZNM2ZuPKV/tpRNxMWqKTF+vX6J2LO4N8Bi0mZjxi gRZQ46pbAruTKVdK7tnMjVvJyvu+gePI9bZU28vGbfOqXJwWyVV2MKuMOlhttY7wY7B4 xsJkqyiNnXAS76Kuvz6jZfY3RogXqyJFAX6wfxrL4C/xcDFR8GNZwRH/NnH/vBmYXR0D MRXI7ddXku6f3VXMBc5heHdBucFzeCtWX29/uByYF5fDKw9/6dTrM6s0FBSS+NER8SzJ f5hg== 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 n10si131213plc.36.2021.10.29.01.52.29; Fri, 29 Oct 2021 01:52:41 -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 S229797AbhJ2IxW (ORCPT + 99 others); Fri, 29 Oct 2021 04:53:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:49500 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231533AbhJ2IxO (ORCPT ); Fri, 29 Oct 2021 04:53:14 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 574DE61075; Fri, 29 Oct 2021 08:50:44 +0000 (UTC) Date: Fri, 29 Oct 2021 10:50:41 +0200 From: Christian Brauner To: Muchun Song Cc: andriy.shevchenko@linux.intel.com, Andrew Morton , Stephen Rothwell , revest@chromium.org, Alexey Dobriyan , LKML , linux-fsdevel Subject: Re: [PATCH] seq_file: fix passing wrong private data Message-ID: <20211029085041.fhyi2kn3bdmxt6h4@wittgenstein> References: <20211029032638.84884-1-songmuchun@bytedance.com> <20211029082620.jlnauplkyqmaz3ze@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 29, 2021 at 04:43:40PM +0800, Muchun Song wrote: > On Fri, Oct 29, 2021 at 4:26 PM Christian Brauner > wrote: > > > > 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?: > > Unfortunately, they are not the same. The difference is the > operation structure, namely "struct file_operations" and > "struct proc_ops". > > DEFINE_SHOW_ATTRIBUTE() is usually used by > debugfs while DEFINE_SHOW_ATTRIBUTE() is > used by procfs. Ugh, right, thanks for pointing that out. I overlooked the _proc_ops appendix. Not sure what's right here. There seem to have been earlier callers to DEFINE_PROC_SHOW_ATTRIBUTE() that relied on PDE_DATA() but there's only one caller so that change wouldn't be too bad, I guess.