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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7529C433EF for ; Fri, 29 Oct 2021 09:17:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 95BDC60F23 for ; Fri, 29 Oct 2021 09:17:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231602AbhJ2JUO (ORCPT ); Fri, 29 Oct 2021 05:20:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231493AbhJ2JTP (ORCPT ); Fri, 29 Oct 2021 05:19:15 -0400 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30560C061227 for ; Fri, 29 Oct 2021 02:16:47 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id v138so17146836ybb.8 for ; Fri, 29 Oct 2021 02:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ii1VwS4bdocl/9x/wQu5Dr4Dw4xnbfm4TdQdq5Q+Azo=; b=tm8FL5NwJB2u6qrHnZtD84LIMRI/iboApguCXaLUq9SaX/qb19ml1AcKQ5CH/E5h3w S9284fol2t6LhXShzy6SrMbZi0J6usF0oon3W6pWM2clShpwDU9VOz67NU9Cb5OUDXV2 m/wWU94FmxgrtjlewS0P+DH13dd98L+7UgsawCrJQNo+3+Rm+mLWAmCFh+KiX4xwbd5n kFAr/FEBKKvEUJ+v76aHUXx/FLgFjl6axzWrtcSI7kT//aqC4IIz0+4fnT7uhBbsoNHq 7IhyXKurVXnHNSNJ4YpxGWCVkY6iPwQrMXjRT1215vFhwZxrdXCuFYpo4RZUfAEMV2pV BafA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ii1VwS4bdocl/9x/wQu5Dr4Dw4xnbfm4TdQdq5Q+Azo=; b=XweCa9h4F1jszccYvpKbE82ULzNmqQUI3/kNEdv4H+FpszbHlT4kixiHNkUtJSctxq fRlI8DojwQM8emRa8+NAx1/6b/skkpYX5AqXz5bAbh6uCTND3prD8sAyeLh3MPKP0SR0 p198S2OgH1W3jhsHY/5od9XqF8lSe85V7wc3eMmiN1tIlmdr/zSDe6nFXcIjMMnt7bef gf/Qgi1UcVzWdA1BuvxYOl6WYS97B8gv1k7JYRXV1E5q+F8WaIDT26+L3E6ddqi0crss kXU7x7pbbgPHpXjgKN53uEoWmN2L+J3m4BNJ+955WN2Zlu18QHXsokGq5//tQKjmHFnV AZYA== X-Gm-Message-State: AOAM532EJRFtQix/bOpmOw2ZI8T2Wb6kCLrFRcCm1XzQPsVChsXlJEcR CS+ZXVNzCsoV0/KbO3f8Ye/4FB0ZK/esiFPp/Vy4IQ== X-Google-Smtp-Source: ABdhPJwW4nO+fDJURAek2VDCfkH2XNLlc3gfnKCDXjWDPT8d0Z9cEu/hrBUNVInc9gyOaceJ1Hk/R0u7QAnkp0Ry9yc= X-Received: by 2002:a25:ad02:: with SMTP id y2mr10644935ybi.141.1635499006377; Fri, 29 Oct 2021 02:16:46 -0700 (PDT) MIME-Version: 1.0 References: <20211029032638.84884-1-songmuchun@bytedance.com> <20211029082620.jlnauplkyqmaz3ze@wittgenstein> <20211029085041.fhyi2kn3bdmxt6h4@wittgenstein> In-Reply-To: <20211029085041.fhyi2kn3bdmxt6h4@wittgenstein> From: Muchun Song Date: Fri, 29 Oct 2021 17:16:10 +0800 Message-ID: Subject: Re: [PATCH] seq_file: fix passing wrong private data To: Christian Brauner Cc: andriy.shevchenko@linux.intel.com, Andrew Morton , Stephen Rothwell , revest@chromium.org, Alexey Dobriyan , LKML , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Oct 29, 2021 at 4:50 PM Christian Brauner wrote: > > 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. >From my point of view, I think the macro is useful which can simplify the code. However there is only one user of it. I suppose few people know about it. For instance, the following ops can become the user of it. cifs_mount_params_proc_ops nfsd_proc_ops rpc_proc_ops Thanks.