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

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: <20150817151145.GF10894@dhcp22.suse.cz>
Date:	Mon, 17 Aug 2015 17:11:45 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: Change global memory state symbols to GPL-only

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 participate
> > > in shrinking.
> > 
> > How does the external and !GPL fs does slab reclaim? Those are essential
> > for the proper memory balancing.
> 
> If they know how to do shrinking on Linux then they are probably
> derivative works of Linux.

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.

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.
-- 
Michal Hocko
SUSE Labs
--
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/