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: <CAEXW_YQt976k6tRJBoYy=S-CpacgB+MpMr-H=TEtZBaP=CPwnQ@mail.gmail.com>
Date:   Tue, 7 Mar 2023 00:11:20 -0500
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Joe Perches <joe@...ches.com>
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 Mon, Mar 6, 2023 at 11:53 PM Joe Perches <joe@...ches.com> 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@...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() */
>

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);

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ