public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] Unexport do_machine_check() and machine_check_poll()
Date: Mon, 14 Mar 2016 19:56:34 +0100	[thread overview]
Message-ID: <20160314185634.GK15800@pd.tnic> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F3A008EDD@ORSMSX114.amr.corp.intel.com>

On Mon, Mar 14, 2016 at 06:24:23PM +0000, Luck, Tony wrote:
> > But the sentiment is: I want to unexport do_machine_check() and
> > machine_check_poll() and not let external modules call into them
> > directly. Why, you ask? Because they have no business doing that.
> 
> EXPORT is a big hammer ... we either let every module have access to
> a function, or none.  It sounds like you want a way to just export to a
> few trusted friendly areas that have a real need to access, and make this
> invisible to everyone else.
> 
> I can't imagine a way to absolutely enforce that ... whatever mechanism
> you choose could be abused by someone willing to have their module lie
> and say "sure, I'm a KVM user that is allowed to use that".
> 
> Perhaps there's a way to implement an advisory scheme ... which would
> make it blatantly obvious when modules are hooking into things that
> they shouldn't. The only similar thing we have now is EXPORT_GPL which doesn't
> look scalable to lots of uses.

Yap. Exactly.

Right, so the optimal thing to do IMHO is make those two users solve
their needs differently, so that there's no requirement for exports at
all. And the fact that both are modules - and they need to be modules
for obvious reasons - doesn't make it any easier.

I can't think of something useful right now though... I'll need to
ponder on it a while longer.

Thanks for listening!

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

      reply	other threads:[~2016-03-14 18:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14 16:38 [RFC PATCH] Unexport do_machine_check() and machine_check_poll() Borislav Petkov
2016-03-14 16:52 ` Borislav Petkov
2016-03-14 16:55 ` Luck, Tony
2016-03-14 18:08   ` Borislav Petkov
2016-03-14 18:24     ` Luck, Tony
2016-03-14 18:56       ` Borislav Petkov [this message]

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=20160314185634.GK15800@pd.tnic \
    --to=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@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