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-next>] [day] [month] [year] [list]
Message-Id: <20230310225236.3939443-1-mcgrof@kernel.org>
Date:   Fri, 10 Mar 2023 14:52:31 -0800
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     chuck.lever@...cle.com, jlayton@...nel.org,
        trond.myklebust@...merspace.com, anna@...nel.org,
        davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
        kuba@...nel.org, linux-nfs@...r.kernel.org
Cc:     ebiederm@...ssion.com, keescook@...omium.org, yzaikin@...gle.com,
        j.granados@...sung.com, patches@...ts.linux.dev,
        linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Luis Chamberlain <mcgrof@...nel.org>
Subject: [PATCH 0/5] sunrpc: simplfy sysctl registrations

We're trying to deprecate the APIs for sysctl that try to do
registration and but are exposed to recursion. Those paths are
only needed in complex cases and even those can be simplified
with time.

Sunrpc uses has simple requirements: just to have their parent
directory created. The new sysctl APIs can be used for this. If
you are curious about new requirements just review the new patch
for documentation I just posted:

https://lore.kernel.org/all/20230310223947.3917711-1-mcgrof@kernel.org/T/#u     

So just simplify all this.

I haven't even build tested this, this is all being compile tested
now through sysctl-testing [0] along with the other rest of the
changes.

Posting this early in the development cycle so it gets proper testing
and review.

Feel free to take these patches or let me know and I'm happy to also
take these in through sysctl-next. Typically I use sysctl-next for
core sysctl changes or for kernel/sysctl.c cleanup to avoid conflicts.
All these syctls however are well contained to sunrpc so they can also
go in separately. Let me know how you'd like to go about these patches.

For those curious -- yes most of this is based on Coccinelle grammar,
you can see the SmPL patch I first wrote years ago for some other use
cases here:

https://lore.kernel.org/all/20211123202422.819032-6-mcgrof@kernel.org/

This is just an evolution of that with more complex cases, however
always writing the SmPL patch to each commit eats my time away and
I really cannot be bothered by that. Small modifications to the above
can be used however to do things which are similar.

Luis Chamberlain (5):
  sunrpc: simplify two-level sysctl registration for tsvcrdma_parm_table
  sunrpc: simplify one-level sysctl registration for xr_tunables_table
  sunrpc: simplify one-level sysctl registration for xs_tunables_table
  sunrpc: move sunrpc_table above
  sunrpc: simplify one-level sysctl registration for debug_table

 net/sunrpc/sysctl.c             | 90 ++++++++++++++-------------------
 net/sunrpc/xprtrdma/svc_rdma.c  | 21 +-------
 net/sunrpc/xprtrdma/transport.c | 11 +---
 net/sunrpc/xprtsock.c           | 13 +----
 4 files changed, 44 insertions(+), 91 deletions(-)

-- 
2.39.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ