linux-kernel - Re: [PATCH] ksm: Expose configuration via sysctl

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPXgP10dB6a9BkgZNjPwHSRChfXfSAjhkpzjWwqYwGa+8JwgaQ@mail.gmail.com>
Date:	Wed, 26 Feb 2014 00:50:24 +0100
From:	Kay Sievers <kay@...y.org>
To:	Alexander Graf <agraf@...e.de>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Johannes Weiner <hannes@...xchg.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Hugh Dickins <hughd@...gle.com>,
	Izik Eidus <izik.eidus@...ellosystems.com>,
	Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: [PATCH] ksm: Expose configuration via sysctl

On Wed, Feb 26, 2014 at 12:16 AM, Alexander Graf <agraf@...e.de> wrote:
>
>
>>> Am 26.02.2014 um 01:19 schrieb Peter Zijlstra <peterz@...radead.org>:
>>>
>>>> On Tue, Feb 25, 2014 at 12:15:28PM -0500, Johannes Weiner wrote:
>>>> On Tue, Feb 25, 2014 at 12:28:04AM +0100, Alexander Graf wrote:
>>>> Configuration of tunables and Linux virtual memory settings has traditionally
>>>> happened via sysctl. Thanks to that there are well established ways to make
>>>> sysctl configuration bits persistent (sysctl.conf).
>>>>
>>>> KSM introduced a sysfs based configuration path which is not covered by user
>>>> space persistent configuration frameworks.
>>>>
>>>> In order to make life easy for sysadmins, this patch adds all access to all
>>>> KSM tunables via sysctl as well. That way sysctl.conf works for KSM as well,
>>>> giving us a streamlined way to make KSM configuration persistent.
>>>>
>>>> Reported-by: Sasche Peilicke <speilicke@...e.com>
>>>> Signed-off-by: Alexander Graf <agraf@...e.de>
>>>> ---
>>>> kernel/sysctl.c |   10 +++++++
>>>> mm/ksm.c        |   78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 88 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>>>> index 332cefc..2169a00 100644
>>>> --- a/kernel/sysctl.c
>>>> +++ b/kernel/sysctl.c
>>>> @@ -217,6 +217,9 @@ extern struct ctl_table random_table[];
>>>> #ifdef CONFIG_EPOLL
>>>> extern struct ctl_table epoll_table[];
>>>> #endif
>>>> +#ifdef CONFIG_KSM
>>>> +extern struct ctl_table ksm_table[];
>>>> +#endif
>>>>
>>>> #ifdef HAVE_ARCH_PICK_MMAP_LAYOUT
>>>> int sysctl_legacy_va_layout;
>>>> @@ -1279,6 +1282,13 @@ static struct ctl_table vm_table[] = {
>>>>   },
>>>>
>>>> #endif /* CONFIG_COMPACTION */
>>>> +#ifdef CONFIG_KSM
>>>> +    {
>>>> +        .procname    = "ksm",
>>>> +        .mode        = 0555,
>>>> +        .child        = ksm_table,
>>>> +    },
>>>> +#endif
>>>
>>> ksm can be a module, so this won't work.
>>>
>>> Can we make those controls proper module parameters instead?
>>
>> You can do dynamic sysctl registration and removal. Its its own little
>> filesystem of sorts.
>
> Hm. Doesn't this open another big can of worms? If we have ksm as a module and our sysctl helpers try to enable ksm on boot, they may not be able to because the module hasn't been loaded yet.
>
> So in that case, we want to always register the sysctl and dynamically load the ksm module when the sysctl gets accessed - similar to how we can do stub devices that load modiles, no?

The files sysctl tries to write to at bootup need to be all there
right from the start, otherwise there can't be anything to access, and
no way to trigger any module load.

The auto-load stuff in /dev works by userspace creating dead device
nodes with the proper dev_t before the device exists, which is a very
different model.

sysctl is not suitable for any instantiated or conditional data like
loadable module, devices, ... Things need to be there right from the
start, later registered facilities will not be noticed by sysctl in
userspace and are therefore not hooked into system management. If any
values should be applied from userspace, this will not really work
out.

There a network devices configs doing that today, and they don't
really work that well; it's a gigantic stupid hack in userspace to
fiddle with /proc/sys/ when a netdev shows up, no model to copy to any
new facility.

Usually, loadable module parameter need to live in /sys/module/ or
/sys/bus/, where uevents are generated and udev can pick up the event
and apply system configuration.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/