Re: [PATCH] mm: Change global memory state symbols to GPL-only

[Richard Yao <ryao@gentoo.org>]

On Mon, 2015-08-17 09:56:55 -0700, Ben Hutchings wrote:
> On Mon, 2015-08-17 at 17:11 +0200, Michal Hocko wrote:
> > On Mon 17-08-15 16:56:32, Ben Hutchings wrote:
> > > On Mon, 2015-08-17 at 15:54 +0200, Michal Hocko wrote:
> > > > On Sun 16-08-15 01:42:27, Ben Hutchings wrote:
> > > > > Proprietary modules should not be able to touch vm_stat or particip=
> ate
> > > > > in shrinking.
> > > >=20
> > > > How does the external and !GPL fs does slab reclaim? Those are essent=
> ial
> > > > for the proper memory balancing.
> > >=20
> > > If they know how to do shrinking on Linux then they are probably
> > > derivative works of Linux.
> >=20
> > I am not sure I understand. They are shrinking their internal cached
> > objects and that is hardly a derivative work. The shrinker API is only
> > meant to let them know _when_ this should happen and the interface is
> > a pretty much simple callback API.
> 
> It is a Linux-specific API and I don't think other kernels provide
> something similar to loadable modules.  It enables a module to turn a
> large part of the system RAM into a cache and have the MM effectively
> tell it the correct size of that cache, thus tightly integrating with
> global memory management.

The idea of providing third party drivers with the hooks that they need to
respond to memory pressure is by no means Linux-specific. In OpenSolaris, there
are counters for drivers to keep track of memory usage and try to stay ahead of
it, which works because there is no direct reclaim. There are also callbacks
for the SLAB code to defragment the caches used by the drivers. Giving non-GPL
drivers to respond to memory pressure seems reasonable. Given how long this has
been the csae, it seems strange to change it now.

Every lawyer with whom I have spoken about ports of drivers from other
platforms has informed me tht they are not derived works of Linux. I cannot
imagine a simple callback to free memory on demand would change that.

> It seemed to me that this met the test for 'should this be
> EXPORT_SYMBOL_GPL'.
> 
> > I do not want to defend a proprietary code here but this sounds like an
> > obstruction for those modules which will lead into a worse code in the
> > end because they should somehow manage the cache and it is much better
> > when the core (MM) tells them when it makes sense rather than external
> > heuristics.
> 
> Yes, that's the idea, proprietary code should not be helped in this
> way.

The ZFSOnLinux kernel driver uses these symbols. It is fully open source and
not proprietary. If this is merged, it will break the driver and it will be
incredibly difficult to deal with it while maintaing the ability to respond to
system memory pressure. The kernel just does not provide any other hooks to my
knowledge.