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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

.Dave.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]