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>