[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191102155536.GA10251@avx2>
Date: Sat, 2 Nov 2019 18:55:36 +0300
From: Alexey Dobriyan <adobriyan@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Chris Down <chris@...isdown.name>,
Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH] kernel: sysctl: make drop_caches write-only
On Fri, Nov 01, 2019 at 12:35:44PM -0700, Andrew Morton wrote:
> On Fri, 1 Nov 2019 12:29:20 -0700 Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> > > Either change is an upgrade from the current situation, at least. I prefer
> > > towards whatever makes the API the least confusing, which appears to be
> > > Johannes' original change, but I'd support a patch which always set it to
> > > 0 instead if it was deemed safer.
> >
> > On the other hand.. As I mentioned earlier, if someone's code is
> > failing because of the permissions change, they can chmod
> > /proc/sys/vm/drop_caches at boot time and be happy. They have no such
> > workaround if their software misbehaves due to a read always returning
> > "0".
>
> I lied. I can chmod things in /proc but I can't chmod things in
> /proc/sys/vm. Huh, why did we do that?
To conserve memory! It was in 2007.
For the record I support 0200 on vm.drop_caches.
commit 77b14db502cb85a031fe8fde6c85d52f3e0acb63
[PATCH] sysctl: reimplement the sysctl proc support
+static int proc_sys_setattr(struct dentry *dentry, struct iattr *attr)
+{
+ struct inode *inode = dentry->d_inode;
+ int error;
+
+ if (attr->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID))
+ return -EPERM;
Powered by blists - more mailing lists