Re: [PATCH] kernel: sysctl: make drop_caches write-only

[Andrew Morton]

On Fri, 1 Nov 2019 19:24:05 +0000 Chris Down <chris@xxxxxxxxxxxxxx> wrote:

> Andrew Morton writes:
> >> > The only scenario I can construct in my head is that someone has built
> >> > something to watch drop_caches for modification, but we already have the
> >> > kmsg output for that.
> >
> >The scenario is that something opens /proc/sys/vm/drop_caches for
> >reading, gets unexpected EPERM and blows up?
> 
> Right, but...
> 
> >OK.  What if we make reads always return "0"?  That will fix the
> >misleading output and is more backwards-compatible?
> 
> ...I'm not convinced that if an application has no error boundary for that 
> EPERM that it can tolerate a change in behaviour, either. I mean, if it's 
> opening it at all, presumably it intends to do *something* based on the value 
> (regardless of import or lack thereof). It may do nothing, but it's not 
> possible to know whether that's better or worse than blowing up.
> 
> I have mixed feelings on this one. Pragmatically, as someone who programs in 
> userspace, I'd like failures based on changes in infrastructure to be loud, not 
> silent. If I'm doing something which doesn't work, I'd like to know about it. 
> Of course, one can make the argument that as a user of such an application, 
> sometimes you don't have that luxury.
> 
> 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".