[Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages

Dave Gordon david.s.gordon at intel.com
Tue Dec 8 03:19:28 PST 2015

On 07/12/15 19:13, Johannes Weiner wrote:
> On Mon, Dec 07, 2015 at 06:10:00PM +0000, Dave Gordon wrote:
>> Exporting random uncontrolled variables from the kernel to loaded modules is
>> not really considered best practice. It would be preferable to provide an
>> accessor function - which is just what the declaration says we have; the
>> implementation as a static inline (and/or macro) is what causes the problem
>> here.
> No, what causes the problem is thinking we can't trust in-kernel code.

We 'trust' kernel code not to be malicious, but not to be designed or 
implemented without mistakes. Keeping the impact of the mistakes as 
small and local as possible increases overall system reliability and 
makes debugging easier, which leads to the general principle of only 
exporting the minimum necessary interfaces. If no other module should 
write this data, then let's not export it as a read-write variable.

> If somebody screws up, we can fix it easily enough. Sure, we shouldn't
> be laying traps and create easy-to-misuse interfaces, but that's not
> what's happening here. There is no reason to add function overhead to
> what should be a single 'mov' instruction.

It could still be a macro or local inline within the mm code, but 
provide a read-only function-call interface for external use. That gives 
you maximum efficiency within the owning module, and makes it clear just 
what sort of access is allowed outside that code.


More information about the Intel-gfx mailing list