Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp5134323imw; Tue, 19 Jul 2022 22:30:47 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t/EqckiawdZk2Fzhq3TpfWztYpQgssM1MS3gUlyzg2B1D+IH6EQAJTE4jgFF0ok90/n3Ha X-Received: by 2002:a17:907:728c:b0:72b:995f:78d with SMTP id dt12-20020a170907728c00b0072b995f078dmr33893081ejc.348.1658295047105; Tue, 19 Jul 2022 22:30:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658295047; cv=none; d=google.com; s=arc-20160816; b=X1kLfuV56hrEdUzHSszz3Tc7OcsCdwdQIcyuuP/Yr+fGIG8N32jgO5yzg1HBqglQMu Cz7D/JPCORHq6bkcjEY2Jh5W+CIt3fcse0rDwmRIU7xx3IpqCJAEcgbfnjraeB496KHg Rrs0bQ7aVpdxBSOX+ugB2ibB1HLauqWpYg3U8WtDfydQqcb21j/QITxYCOT4VEuiCKve 7hbDBVVoDqfpuzC0GN3jVrH4opLjn4Y9tazyMBho6m4fhLOqBT3Id1TYErFuUyFSKzXT SMC8h8UcK0uYmkwEgV7Ut3ju96IUE7ZqnmigammE5TyEOMjTXkMI37fBfx0HT3OzjRt3 OMgQ== 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=stifYgjPiXX5R5s0ZOM3DpqxQIeJzktWgHSqB2KhGqM=; b=tK+5FRH4tVuXtOGAGUGZnJ8tBnEVKqqlfTkUH9XYdbBy6nE0oLlPgDYr2bJ1L1uxlI uPbMVubKJ501UfxRHRHzixtYg2cDTucaoQgzDQ5DFNcUwnHkG7I4FwQfOjPBNsB5XHxo euxIx9koHhDhb6vYf4KekdRMAp7yeSLErkmSFFk3yzVlMbNBXZoxtpIUsOZ+wfsSbwxg ACLr8cgjpHiHgLF7lveWlmnoFtLy6kxmszgkSTbk4jH6D63NdJllvLVEC5OEIZ7H3vyT 9XLVOSyl67O4pcn6PF4v3P9y6PP8BR5ZpnHbDDstW/vEos0a+zsB7lWd7uwXVTgPtJkQ uILg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Dv8loitx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s2-20020a056402520200b0043aa4fc7b9fsi29007edd.17.2022.07.19.22.30.22; Tue, 19 Jul 2022 22:30:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Dv8loitx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232597AbiGTE6i (ORCPT + 99 others); Wed, 20 Jul 2022 00:58:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229470AbiGTE6h (ORCPT ); Wed, 20 Jul 2022 00:58:37 -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 0399622B03 for ; Tue, 19 Jul 2022 21:58:36 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id f73so30008655yba.10 for ; Tue, 19 Jul 2022 21:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=stifYgjPiXX5R5s0ZOM3DpqxQIeJzktWgHSqB2KhGqM=; b=Dv8loitxSXzMABsjf/4tvOhHU6ejHC+jmnTlMvQLZBBPhzBML7pgy/r6N7WmPUKidp qn/3hr7s/ggW+ZW3aKblO/WjUMkTxGMIO0QycEkjU6b9WHb1LCpkia/qRQK0An88ZplM uYdTE3eJYqGBrlKLJYkYK1CEsmZQocNYEm9M/oyTAfFN9NZZgxx9yCH2MTmW6CUcQ7h7 s1T+4sAnJdJk+DsI6xtpJreuwmL3v79oqN+u3mDYVQh9+tpmFTTASzmaDJb23H8P4lpS ZXyRwf4aLKNHAb0BZQQ/T+qXE27x80SesXSTdz3PfbSyRUpL1T/Q13TDVSCpXaPOKoqL YdQQ== 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=stifYgjPiXX5R5s0ZOM3DpqxQIeJzktWgHSqB2KhGqM=; b=XjNBtbHqWzv8JPrDwyjRvYmshUV/PBkFm8bQW/qwHWOyo1QXchoeVX37+KxOCulqcG CmGt0El1CVsWB7qOkjrp+DC9/yKbtBYVJF5oTPckRYgJTeJEnAsVE1dMF7uj3fY+hIC2 JRhvu8P4tEYGBf7U4SsYBu/t7rVSzyw3OiURCIxGj8QwL7TzBHldGkwM1scnH06ERCbc igcsLelhNJApXzRJ5L85nj/eETq9el4IQOy+2w8PeLIfrlG247VFcl3AcVxN5DgMfm4P NL6qYXhHmskn90dqC46K0vbqTF7VPmpvxAZh0lhG0xVzJ7s2ceCTwQ/1yUTWSAcLJVtc hq0Q== X-Gm-Message-State: AJIora8FcKs3B9WMvLxy32K+46keN2VuYYvHEGfOgT3VHio56bQ33uh1 f7iOaMqp8CaWfc0uwOD/hBDa1XKbPdWzSG0voUI= X-Received: by 2002:a05:6902:728:b0:66e:8f7b:a252 with SMTP id l8-20020a056902072800b0066e8f7ba252mr33553859ybt.584.1658293115034; Tue, 19 Jul 2022 21:58:35 -0700 (PDT) MIME-Version: 1.0 References: <20220718120149.GD2338@kadam> <20220719055047.322355-3-ztong0001@gmail.com> In-Reply-To: From: Tong Zhang Date: Tue, 19 Jul 2022 21:58:24 -0700 Message-ID: Subject: Re: [PATCH v2 2/3] staging: rtl8192u: move debug files to debugfs To: Greg Kroah-Hartman Cc: Jakub Kicinski , Colin Ian King , Saurav Girepunje , Nathan Chancellor , Johan Hovold , open list , linux-staging@lists.linux.dev, Dan Carpenter Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 19, 2022 at 5:53 AM Greg Kroah-Hartman wrote: > > On Mon, Jul 18, 2022 at 10:50:37PM -0700, Tong Zhang wrote: > > There are 4 debug files created under /proc/net/[Devname]. Devname could > > Due to this is purely for debuging as files are created read only, > > move this to debugfs like other NIC drivers do instead of using procfs. > > This is also to prepare for address rmmod warn issue. > > Minor comments based on good debugfs usage: > > > --- a/drivers/staging/rtl8192u/r8192U.h > > +++ b/drivers/staging/rtl8192u/r8192U.h > > @@ -1061,6 +1061,9 @@ typedef struct r8192_priv { > > struct delayed_work gpio_change_rf_wq; > > struct delayed_work initialgain_operate_wq; > > struct workqueue_struct *priv_wq; > > + > > + /* debugfs */ > > + struct dentry *debugfs_dir; > > Why do you need to save this dentry? Can't you just look it up when you > want to remove the files? > Hi Greg, Thanks for the comments. I am thinking whether it is possible to rename the device and run rmmod to remove something it shouldn't. If we are using debugfs_lookup(dev->name, NULL), say, the existing directories/files are /sys/kernel/debug/DIRA /sys/kernel/debug/wlan0 I then rename device wlan0 to DIRA, after that I remove the module by doing rmmod. Apparently either the wlan0 directory will not be renamed successfully due to collision or DIRA directory might be overwritten? (this part I haven't checked yet) Either Way, later on if we do rmmod, the driver will try to do debugfs_lookup("fileA", NULL) and remove /sys/kernel/debug/DIRA which it shouldn't. Or if it is possible to rename the device to some wacky string containing wildcard or .. to launch an attack. Maybe I am being naive but please correct me if I am wrong. Or maybe we should put those debug files under the module's own directory and do lookup from there instead. like the following dir structure /sys/kernel/debug/r8192u_usb/wlan0/stats-rx /sys/kernel/debug/r8192u_usb/wlan0/stats-rx /sys/kernel/debug/r8192u_usb/wlan0/stats-ap /sys/kernel/debug/r8192u_usb/wlan0/registers > > +void rtl8192_debugfs_init(struct net_device *dev) > > { > > - struct proc_dir_entry *dir; > > + struct dentry *dir; > > + struct r8192_priv *priv = (struct r8192_priv *)ieee80211_priv(dev); > > No need to cast this. Same for later on in this file. > agreed, will remove those redundant checks. > > - if (!rtl8192_proc) > > + dir = debugfs_create_dir(dev->name, NULL); > > + if (IS_ERR(dir)) > > return; > > No need to check, just keep moving on. > > > > > - dir = proc_mkdir_data(dev->name, 0, rtl8192_proc, dev); > > - if (!dir) > > - return; > > + debugfs_create_file("stats-rx", 0444, dir, dev, &rtl8192_usb_stats_rx_fops); > > + debugfs_create_file("stats-tx", 0444, dir, dev, &rtl8192_usb_stats_tx_fops); > > + debugfs_create_file("stats-ap", 0444, dir, dev, &rtl8192_usb_stats_ap_fops); > > + debugfs_create_file("registers", 0444, dir, dev, &rtl8192_usb_registers_fops); > > > > - proc_create_single("stats-rx", S_IFREG | 0444, dir, > > - proc_get_stats_rx); > > - proc_create_single("stats-tx", S_IFREG | 0444, dir, > > - proc_get_stats_tx); > > - proc_create_single("stats-ap", S_IFREG | 0444, dir, > > - proc_get_stats_ap); > > - proc_create_single("registers", S_IFREG | 0444, dir, > > - proc_get_registers); > > + priv->debugfs_dir = dir; > > Again, no need to save this, just look it up when removing the > directory. > > thanks, > > greg k-h Thanks and have a good one! - Tong