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]
Date:   Wed, 24 Nov 2021 15:12:21 -0800
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Xiaoming Ni <nixiaoming@...wei.com>, akpm@...ux-foundation.org,
        keescook@...omium.org, yzaikin@...gle.com, peterz@...radead.org,
        gregkh@...uxfoundation.org, pjt@...gle.com,
        liu.hailong6@....com.cn, andriy.shevchenko@...ux.intel.com,
        sre@...nel.org, penguin-kernel@...ove.sakura.ne.jp,
        pmladek@...e.com, senozhatsky@...omium.org, wangqing@...o.com,
        bcrl@...ck.org, viro@...iv.linux.org.uk, jack@...e.cz,
        amir73il@...il.com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/9] sysctl: Move some boundary constants from
 sysctl.c to sysctl_vals

On Wed, Nov 24, 2021 at 11:38:19AM -0600, Eric W. Biederman wrote:
> Looking a little more.  I think it makes sense to do something like:
> 
> diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
> index 1fa2b69c6fc3..c299009421ea 100644
> --- a/include/linux/sysctl.h
> +++ b/include/linux/sysctl.h
> @@ -121,8 +121,8 @@ struct ctl_table {
>         struct ctl_table *child;        /* Deprecated */
>         proc_handler *proc_handler;     /* Callback for text formatting */
>         struct ctl_table_poll *poll;
> -       void *extra1;
> -       void *extra2;
> +       long min;
> +       long max;
>  } __randomize_layout;
> 
> Any chance we can do that for a cleanup instead of extending sysctl_vals?

Essentially the change is *big*. We either do that *not yet implemented*
change *now, and then have to rebase all the non-upstream work to adapt
to that, or we do that after the cleanup.

Both I think are going to cause some suffering. I'd prefer to do it
after though. Would you be OK with that?

  Luis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ