From: Andrew Morton <akpm@linux-foundation.org>
To: Waiman Long <longman@redhat.com>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Al Viro <viro@zeniv.linux.org.uk>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range
Date: Thu, 1 Mar 2018 13:38:07 -0800 [thread overview]
Message-ID: <20180301133807.f5beb1bf1d1391f23e95ce63@linux-foundation.org> (raw)
In-Reply-To: <1519926220-7453-5-git-send-email-longman@redhat.com>
On Thu, 1 Mar 2018 12:43:38 -0500 Waiman Long <longman@redhat.com> wrote:
> Even with clamped sysctl parameters, it is still not that straight
> forward to figure out the exact range of those parameters. One may
> try to write extreme parameter values to see if they get clamped.
> To make it easier, a warning with the expected range will now be
> printed in the kernel ring buffer when a clamped sysctl parameter
> receives an out of range value.
>
> ...
>
> + if (clamped && param->name &&
> + !(*param->flags & CTL_FLAGS_OOR_WARNED)) {
> + proc_ctl_warn(d, param->name,
> + param->min ? *param->min : -INT_MAX,
> + param->max ? *param->max : INT_MAX, val);
> + *param->flags |= CTL_FLAGS_OOR_WARNED;
> + }
The handling of ctl_table.flags looks racy on SMP or preemptible.
That's not at all a serious problem in this usage, but such handling of
ctl_table.flags may be a problem in the future. Which means that if
some future user of this field *is* sensitive to races then people are
going to have to come back to this code and add the needed locking.
So we should at least think about what that locking is to be, and
document it in some fashion. Do we already hold an appropriate lock at
this time? If so, what is it?
If some such future user of ctl_table.flags has to add a new lock to
the ctl_table for this purpose then we just eliminated your use-16-bit
space saving trick and we may as well use a ulong and operate on it
with bitops.
next prev parent reply other threads:[~2018-03-01 21:38 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 17:43 [PATCH v3 0/6] ipc: Clamp *mni to the real IPCMNI limit Waiman Long
2018-03-01 17:43 ` [PATCH v3 1/6] proc/sysctl: Fix typo in sysctl_check_table_array() Waiman Long
2018-03-08 17:51 ` Luis R. Rodriguez
2018-03-01 17:43 ` [PATCH v3 2/6] sysctl: Add kdoc comments to do_proc_do{u}intvec_minmax_conv_param Waiman Long
2018-03-08 17:52 ` Luis R. Rodriguez
2018-03-01 17:43 ` [PATCH v3 3/6] sysctl: Add flags to support min/max range clamping Waiman Long
2018-03-01 21:31 ` Andrew Morton
2018-03-01 21:54 ` Waiman Long
2018-03-08 17:51 ` Luis R. Rodriguez
2018-03-08 17:57 ` Luis R. Rodriguez
2018-03-08 19:35 ` Waiman Long
2018-03-08 20:45 ` Luis R. Rodriguez
2018-03-08 21:41 ` Waiman Long
2018-03-08 19:30 ` Waiman Long
2018-03-01 17:43 ` [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range Waiman Long
2018-03-01 21:38 ` Andrew Morton [this message]
2018-03-01 22:22 ` Waiman Long
2018-03-08 18:11 ` Luis R. Rodriguez
2018-03-08 19:37 ` Waiman Long
2018-03-08 18:31 ` Luis R. Rodriguez
2018-03-08 19:57 ` Waiman Long
2018-03-08 20:49 ` Luis R. Rodriguez
2018-03-08 21:40 ` Waiman Long
2018-03-08 22:06 ` Luis R. Rodriguez
2018-03-01 17:43 ` [PATCH v3 5/6] ipc: Clamp msgmni and shmmni to the real IPCMNI limit Waiman Long
2018-03-08 18:14 ` Luis R. Rodriguez
2018-03-01 17:43 ` [PATCH v3 6/6] ipc: Clamp semmni " Waiman Long
2018-03-08 18:15 ` Luis R. Rodriguez
2018-03-08 20:02 ` Waiman Long
2018-03-08 18:23 ` [PATCH v3 0/6] ipc: Clamp *mni " Luis R. Rodriguez
2018-03-08 18:38 ` Luis R. Rodriguez
2018-03-08 19:22 ` Waiman Long
2018-03-08 19:02 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180301133807.f5beb1bf1d1391f23e95ce63@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mcgrof@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox