linux-kernel - Re: [PATCH -v2 -mm] add extra free kbytes tunable

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]

Message-Id: <20110901151650.0a82716b.akpm@linux-foundation.org>
Date:	Thu, 1 Sep 2011 15:16:50 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Rik van Riel <riel@...hat.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	Satoru Moriya <smoriya@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	lwoodman@...hat.com, Seiji Aguchi <saguchi@...hat.com>,
	hughd@...gle.com, hannes@...xchg.org
Subject: Re: [PATCH -v2 -mm] add extra free kbytes tunable

On Thu, 1 Sep 2011 15:08:00 -0700 (PDT)
David Rientjes <rientjes@...gle.com> wrote:

> On Thu, 1 Sep 2011, Andrew Morton wrote:
> 
> > > Add a userspace visible knob
> > 
> > argh.  Fear and hostility at new knobs which need to be maintained for
> > ever, even if the underlying implementation changes.
> > 
> 
> Do we really need to maintain tunables that lose their purpose either 
> because the implementation changes or is patched to fix the issue that the 
> tunable was intended to address without requiring it?
> 
> Are there really userspace tools written to not be able to handle -ENOENT 
> when one of these gets removed?

I don't know, and neither does anyone else.  So we need to be cautious.
Like putting a warning printk in there and waiting several years.

And it's not just a matter of handling ENOENT.  The user modified this
tunable for a *reason*.  They were expecting some behaviour change in
the kernel.  If we remove the tunable, we take that behaviour change
away from them.  So by adding this tunable, we constrain future
implementations by requiring those implementations to automatically do
whatever the user was previously doing manually.  And we don't reliably
know *why* each user altered that tunable.  It's a horrid mess.

--
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/