lkml.org 
[lkml]   [2023]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH 1/1] rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscale
    Date
    > From: Joel Fernandes <joel@joelfernandes.org>
    > [...]
    > > > kernel/rcu/rcuscale.c | 7 +++++++
    > > > 1 file changed, 7 insertions(+)
    > > >
    > > > diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c index
    > > > 91fb5905a008..5e580cd08c58 100644
    > > > --- a/kernel/rcu/rcuscale.c
    > > > +++ b/kernel/rcu/rcuscale.c
    > > > @@ -522,6 +522,8 @@ rcu_scale_print_module_parms(struct
    > rcu_scale_ops *cur_ops, const char *tag)
    > > > scale_type, tag, nrealreaders, nrealwriters, verbose,
    > > > shutdown); }
    > > >
    > > > +static void kfree_scale_cleanup(void);
    > > > +
    > >
    > > I do applaud minmimizing the size of the patch, but in this case could
    > > you please pull the kfree_scale_cleanup() function ahead of its first use?
    >
    > The only trouble with moving the function like that is, the file is mostly split
    > across kfree and non-kfree functions. So moving a kfree function to be
    > among the non-kfree ones would look a bit weird.

    Yes, this would look a bit weird ...

    Please see the reply to Paul in another e-mail:
    "Pull the rcu_scale_cleanup() function after kfree_scale_cleanup().
    This groups kfree_* functions and groups rcu_scale_* functions.
    Then the code would look cleaner."

    > Perhaps a better place for the function declaration could be a new
    > "rcuscale.h". But I am really Ok with Paul's suggestion as well.
    >
    > Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>

    Thanks for the review. :-)

    > thanks,
    >
    > - Joel



    \
     
     \ /
      Last update: 2023-03-27 01:01    [W:2.210 / U:0.376 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site