linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>,
	linux-mm@kvack.org, intel-gfx@lists.freedesktop.org, "Goel,
	Akash" <akash.goel@intel.com>
Subject: Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages
Date: Tue, 8 Dec 2015 11:19:28 +0000	[thread overview]
Message-ID: <5666BCC0.50507@intel.com> (raw)
In-Reply-To: <20151207191346.GA3872@cmpxchg.org>

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2015-12-08 11:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 15:58 [PATCH v2 1/2] mm: Export nr_swap_pages Chris Wilson
2015-12-04 15:58 ` [PATCH v2 2/2] drm/i915: Disable shrinker for non-swapped backed objects Chris Wilson
2015-12-04 16:11   ` Johannes Weiner
2015-12-10  9:34   ` Daniel Vetter
2015-12-04 16:09 ` [PATCH v2 1/2] mm: Export nr_swap_pages Johannes Weiner
2015-12-10  9:32   ` [Intel-gfx] " Daniel Vetter
2015-12-23 22:04     ` Johannes Weiner
2015-12-23 22:26       ` Andrew Morton
2016-01-05 10:05         ` Daniel Vetter
2015-12-07 13:48 ` Michal Hocko
2015-12-07 16:48   ` Johannes Weiner
2015-12-07 17:04     ` Michal Hocko
2015-12-07 18:02       ` Johannes Weiner
2015-12-07 18:10     ` [Intel-gfx] " Dave Gordon
2015-12-07 19:13       ` Johannes Weiner
2015-12-08 11:19         ` Dave Gordon [this message]
2015-12-08 11:22         ` Michal Hocko
2015-12-17 18:15           ` [PATCH v3] mm: Export {__}get_nr_swap_pages() Dave Gordon
2015-12-17 19:45             ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5666BCC0.50507@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=akash.goel@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).