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

From: Joel Fernandes
Date: Tue Mar 07 2023 - 00:11:42 EST


On Mon, Mar 6, 2023 at 11:53 PM Joe Perches <joe@xxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxx> 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() */
>

Do you mind sharing which tree you are looking at? I checked both
6.3-rc1 and linux-next.

Your grep returned:

kernel/trace/trace_osnoise.c: kvfree_rcu(inst);
kernel/trace/trace_probe.c: kvfree_rcu(link);
lib/test_vmalloc.c: kvfree_rcu(p);
mm/list_lru.c: * We need kvfree_rcu() here. And the walking of the list
net/core/pktgen.c: /* Don't need rcu_barrier() due to use of kfree_rcu() */
net/core/sysctl_net_core.c:
kvfree_rcu(orig_sock_table);
net/core/sysctl_net_core.c: kfree_rcu(cur);
net/mac802154/scan.c: kfree_rcu(request);
net/mac802154/scan.c: kfree_rcu(request);