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".
