mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kyle Moffett <mrmacman_g4@mac.com>
To: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [RFC] [PATCH] make add_taint() inline
Date: Sun, 11 Sep 2005 19:10:44 -0400	[thread overview]
Message-ID: <B341E46B-1987-4284-8521-B9A177EC4A46@mac.com> (raw)
In-Reply-To: <20050911155637.3839db5c.rdunlap@xenotime.net>

On Sep 11, 2005, at 18:56:37, Randy.Dunlap wrote:
> On Sun, 11 Sep 2005 14:22:08 -0400 Kyle Moffett wrote:
>
>> On Sep 11, 2005, at 13:44:37, donate wrote:
>>
>>> From: Randy Dunlap <rdunlap@xenotime.net>
>>>
>>> add_taint() is a trivial function.
>>> No need to call it out-of-line, just make it inline and
>>> remove its export.
>>
>> Actually, in this case it might be better to leave add_taint
>> exported, add and export a new function get_taint(), and then
>> remove all export of the variable "tainted".  I've actually
>> seen one case where some module removed taint bits.  I don't
>
> some in-tree module?

No, it was a BSD out-of-tree module, I don't even remember what
it was anymore, it's probably not significant, but if "tainted"
is exported, it seems like some binary module writers might get
the brilliant idea to twiddle it by hand.  How about something
like this to enforce the idea that taintedness is add-only:

void add_taint(unsigned int flags);
unsigned int get_taint(void);

static unsigned int tainted;

Then use atomic bit operations on platforms which have them and
a spinlock on those that don't.  My guess where the lack of
locking might cause issues is if we hit an MCE and bad_page at
the same time on SMP or something.  It seems like it would be
really rare in practice, but I guess that appropriately timed
badness in multiple drivers (perhaps one triggered by the other?)
could cause it to occur.

> Maybe Dave Jones's modprobe/insmod killer test on a big
> multiprocessor system could do that one day.

Or that :-D.  The only way I can see this dying or accidentally
untainting is if two processors try to add different types of
taint simultaneously.

Cheers,
Kyle Moffett

--
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best  
answer:

"Why do musicians compose symphonies and poets write poems? They do  
it because
life wouldn't have any meaning for them if they didn't. That's why I  
draw
cartoons. It's my life."
   -- Charles Shultz



  reply	other threads:[~2005-09-11 23:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050911103757.7cc1f50f.rdunlap@xenotime.net>
2005-09-11 17:44 ` donate
2005-09-11 18:22   ` Kyle Moffett
2005-09-11 22:56     ` Randy.Dunlap
2005-09-11 23:10       ` Kyle Moffett [this message]
2005-09-11 19:44   ` Andrew Morton
2005-09-11 22:52     ` Randy.Dunlap

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=B341E46B-1987-4284-8521-B9A177EC4A46@mac.com \
    --to=mrmacman_g4@mac.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    /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

all inboxes | Powered by JetHome®