Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2463554pxb; Fri, 29 Oct 2021 01:47:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyX9plYUHMk/FXmXIECOVUJangNI+/iqzsTUJg3XbbwFNlxgl6Ukt4G9+23XqEYaJWxfbxv X-Received: by 2002:a17:903:1111:b0:13f:d1d7:fb5c with SMTP id n17-20020a170903111100b0013fd1d7fb5cmr8530550plh.47.1635497229666; Fri, 29 Oct 2021 01:47:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635497229; cv=none; d=google.com; s=arc-20160816; b=j92H7thWN5UYaaNgqhDXmNmtJ2zDPszGOxX4xYpaLbiPpblZuKi2czg2nDJW347j7a q/NPGxNCbbMhMrLAm99SUHSQzZ6EzyKiOnBnoEM4eH5AQ73bAF5cYNBO06Fb55hvAsUq SHmRFPldPqxfL84D0z6szX4R1olTbkKGB+iKeArdUsCjska2kAbYDxFiNhNCmvLoSGxw Y9Wr9thJf9aJPKxalSE5iT/273FWUG+O9l7/5jL164nCiThrn2L+vaMomiKWRsgFKJNV 8lCXOjwWAlgf+hONDPZVolb0kmemWQm/Z2xZSqh5tt9cAmtWVOEJrz2wTqnSg69zP8gQ rPhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ENq4tjivAFtiLBoYaEjwhbRErXjlHM0kRyDue+qYR8s=; b=h5XytFoPEf/FYD+pPg6OBHrh4h3BHP9ZNGc/pBplYao5gGkxNEktALDqoNZUKCOO6S lvTfIkVLtv6LtDqv/rhpZYW5dBI161VTUeJo6Xg9fviYDr7FkQpiWr1hGA793aww+5Hp QDAfi6vfjSHP7Xxp31DD+sJhY1v6rTANhPie0z7YrhY+cQ5UKEGatBLn+MhqzNBFuEJ9 HFDrIaUXE1nf+B1kCle6HHiMSFit6fec/Cl6aETOi4rr4IbmjU7sUrcfaj/N1tOUvweC huejkf2rYeWXZkfYO7hF8KI+jpSmc6qrehrttT22cloXljjslnnulawakRty5Dg+9gtc o3LA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=wRn5p+8t; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v19si4015124pjg.137.2021.10.29.01.46.56; Fri, 29 Oct 2021 01:47:09 -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; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=wRn5p+8t; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229874AbhJ2Iqt (ORCPT + 99 others); Fri, 29 Oct 2021 04:46:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232492AbhJ2Iqq (ORCPT ); Fri, 29 Oct 2021 04:46:46 -0400 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25785C061714 for ; Fri, 29 Oct 2021 01:44:17 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id 131so10932618ybc.7 for ; Fri, 29 Oct 2021 01:44:17 -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=ENq4tjivAFtiLBoYaEjwhbRErXjlHM0kRyDue+qYR8s=; b=wRn5p+8tRNX5KLoW5FWn6gbyOOsxcJsU6RD5Ia1CYcJmX4QNemi4NBR1v1FhdoFBWN CxzEwVaSfJD7rqFooBD/Xk8DgteDg2OUUabV1EX8aimjdrJa6wA1aCjfKcW7drJbuph9 LpCWC5/xpF1SQ2oZ2hTFijmDbGaaRKaAbbKuEPD5WjY1TlU66NyhY7lV9voUwhJnMK0B VEYBn+ZvcEMzCajC4hlEkqV0gEFFAGHQgIjEsY03dS/B0Hc8vjltNuATxMHLgP5Jy/Qh sJV1y6dl9Y58Bu5jSugY84sgQssseEqzx5/2u+2Crw6wMAsPBg81y0o0xcYh23URjyqC /ykQ== 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=ENq4tjivAFtiLBoYaEjwhbRErXjlHM0kRyDue+qYR8s=; b=V7tZ0d2u66OW3gXpVyA88v2QYcoFIJT+3DxX9lFjYWnHcGP4Ud+OZge8jNusWN5N0m 4lxSxxSgL27YCWhE/tOOY7wTtqMXWSMN7eCZZ9ERStMfSZwWrUhaAHDTC6duV4lJHlAX JB5cvOTDKGcG1LqnWsIdInQCtyjxhbVsJOnLJbPjl/CoxIGXvKF8VFRzLuH4YwilZuoG ltcHF4gToS50whF4imUfb3VAS4J5SWBU4YE4v9e0qsuOZkFnoK0lTCwHJwKl4uQUxgB4 OOWHRNWQcEW95Qm5zkuttm0V3YL3h00zipgzVuL2b35H3zrtb7QY2Y+F2NtarJ59zZIL 41Ig== X-Gm-Message-State: AOAM530JaBRd0KgkIW1lCf2eaI+9dKXvJC3y5KFjfg/Rgb/qSpeDU9Pf W5uoS0JjfsnD0X6Jny6tAkqxOf69rAQ1Tn9M2goMFA== X-Received: by 2002:a25:ad02:: with SMTP id y2mr10484185ybi.141.1635497056643; Fri, 29 Oct 2021 01:44:16 -0700 (PDT) MIME-Version: 1.0 References: <20211029032638.84884-1-songmuchun@bytedance.com> <20211029082620.jlnauplkyqmaz3ze@wittgenstein> In-Reply-To: <20211029082620.jlnauplkyqmaz3ze@wittgenstein> From: Muchun Song Date: Fri, 29 Oct 2021 16:43:40 +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-kernel@vger.kernel.org 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. Thanks. > > #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