linux-kernel - Re: [PATCH] checkpatch: Error out if deprecated RCU API used

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <497c07579fb51ed6f0b8a72471017b4dec258e9e.camel@perches.com>
Date:   Mon, 06 Mar 2023 20:53:20 -0800
From:   Joe Perches <joe@...ches.com>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     linux-kernel@...r.kernel.org, Andy Whitcroft <apw@...onical.com>,
        Dwaipayan Ray <dwaipayanray1@...il.com>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        "Paul E. McKenney" <paulmck@...nel.org>, RCU <rcu@...r.kernel.org>,
        Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>,
        Jens Axboe <axboe@...nel.dk>,
        Philipp Reisner <philipp.reisner@...bit.com>,
        Bryan Tan <bryantan@...are.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Bob Pearson <rpearsonhpe@...il.com>,
        Ariel Levkovich <lariel@...dia.com>,
        Theodore Ts'o <tytso@....edu>, Julian Anastasov <ja@....bg>,
        Uladzislau Rezki <urezki@...il.com>
Subject: Re: [PATCH] checkpatch: Error out if deprecated RCU API used

On Tue, 2023-03-07 at 04:41 +0000, Joel Fernandes wrote:
> On Mon, Mar 06, 2023 at 07:23:23PM -0800, Joe Perches wrote:
> > On Mon, 2023-03-06 at 22:10 -0500, Joel Fernandes wrote:
> > > On Mon, Mar 6, 2023 at 10:08 PM Joe Perches <joe@...ches.com> wrote:
> > > > 
> > > > On Tue, 2023-03-07 at 03:04 +0000, Joel Fernandes (Google) wrote:
> > > > > Single-argument kvfree_rcu() usage is being deprecated [1] [2] as it is
> > > > > error-prone. However, till all users are converted, we would like to introduce
> > > > > checkpatch errors for new patches submitted.
> > > > > 
> > > > > This patch adds support for the same. Tested with a trial patch.
> > > > > 
> > > > > For now, we are only considering usages that don't have compound
> > > > > nesting, for example ignore: kvfree_rcu( (rcu_head_obj), rcu_head_name).
> > > > > This is sufficient as such usages are unlikely.
> > > > > 
> > > > > Once all users are converted and we remove the old API, we can also revert this
> > > > > checkpatch patch then.
> > > > 
> > > > I think this should be added to the deprecated_apis hash instead
> > > > 
> > > > our %deprecated_apis = (
> > > >         "synchronize_rcu_bh"                    => "synchronize_rcu",
> > > >         "synchronize_rcu_bh_expedited"          => "synchronize_rcu_expedited",
> > > >         "call_rcu_bh"                           => "call_rcu",
> > > >         "rcu_barrier_bh"                        => "rcu_barrier",
> > > >         "synchronize_sched"                     => "synchronize_rcu",
> > > >         "synchronize_sched_expedited"           => "synchronize_rcu_expedited",
> > > >         "call_rcu_sched"                        => "call_rcu",
> > > >         "rcu_barrier_sched"                     => "rcu_barrier",
> > > >         "get_state_synchronize_sched"           => "get_state_synchronize_rcu",
> > > >         "cond_synchronize_sched"                => "cond_synchronize_rcu",
> > > >         "kmap"                                  => "kmap_local_page",
> > > >         "kunmap"                                => "kunmap_local",
> > > >         "kmap_atomic"                           => "kmap_local_page",
> > > >         "kunmap_atomic"                         => "kunmap_local",
> > > > );
> > > 
> > > This is not an API name change though, it is a "number of arguments"
> > > or argument list change. Is there a different way to do it?
> > 
> > Ah, no, not really.
> > 
> > btw: I don't see a single use of this call without a comma in the tree.
> 
> Did you look for kvfree_rcu? It is either kvfree_rcu() or kfree_rcu().

$ git grep -P '\bkv?free_rcu\s*\(' -- '*.[ch]' | grep -v -P 'kv?free_rcu\s*\([^,]+,.*\)'
drivers/infiniband/core/device.c:		kfree_rcu(container_of(dev->port_data, struct ib_port_data_rcu,
drivers/infiniband/core/rdma_core.c:	 * kfree_rcu(). However the object may still have been released and
drivers/target/target_core_configfs.c:			 * callbacks to complete post kfree_rcu(), before allowing
include/linux/rcupdate.h: *     kvfree_rcu(ptr);
include/linux/rcupdate.h:#define kvfree_rcu(...) KVFREE_GET_MACRO(__VA_ARGS__,		\
include/linux/rcutiny.h:	// kvfree_rcu(one_arg) call.
include/rdma/ib_verbs.h:	struct rcu_head		rcu;		/* kfree_rcu() overhead */
include/scsi/scsi_device.h: * @rcu: For kfree_rcu().
kernel/rcu/rcuscale.c:		pr_alert("CONFIG_RCU_LAZY is disabled, falling back to kfree_rcu() for delayed RCU kfree'ing\n");
kernel/rcu/tree.c: * struct kvfree_rcu_bulk_data - single block to store kvfree_rcu() pointers
kernel/rcu/tree.c: * @records: Array of the kvfree_rcu() pointers
kernel/rcu/tree.c: * struct kfree_rcu_cpu_work - single batch of kfree_rcu() requests
kernel/rcu/tree.c: * @head_free: List of kfree_rcu() objects waiting for a grace period
kernel/rcu/tree.c: * @bulk_head_free: Bulk-List of kvfree_rcu() objects waiting for a grace period
kernel/rcu/tree.c: * struct kfree_rcu_cpu - batch up kfree_rcu() requests for RCU grace period
kernel/rcu/tree.c: * @head: List of kfree_rcu() objects not yet waiting for a grace period
kernel/rcu/tree.c: * @bulk_head: Bulk-List of kvfree_rcu() objects not yet waiting for a grace period
kernel/rcu/tree.c: * @krw_arr: Array of batches of kfree_rcu() objects waiting for a grace period
kernel/rcu/tree.c:	 * double-argument of kvfree_rcu().  This happens when the
kernel/rcu/tree.c: * reduce the number of grace periods during heavy kfree_rcu()/kvfree_rcu() load.
kernel/rcu/tree.c:		// Probable double kfree_rcu(), just leak.
net/core/pktgen.c:	/* Don't need rcu_barrier() due to use of kfree_rcu() */