mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kurt Garloff <kurt@garloff.de>
To: James Morris <jmorris@redhat.com>
Cc: Linux kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] [LSM] Rework LSM hooks
Date: Thu, 12 Aug 2004 04:03:52 +0200	[thread overview]
Message-ID: <20040812020352.GI14744@tpkurt.garloff.de> (raw)
In-Reply-To: <Xine.LNX.4.44.0408112110030.15343-100000@dhcp83-76.boston.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Hi James,

On Wed, Aug 11, 2004 at 09:20:22PM -0400, James Morris wrote:
> Also, we still have the option of making COND_SECURITY ia64-specific.

We could do that. The patch sets security_ops to
capabilities_security_ops if no LSM is loaded, so it would be OK to
call into it unconditionally on archs that have a higher penalty for
a branch than for an indirect call.

You could just redefine the macro, depending on the arch, indeed.

We could also drop the unlikely. For the hot paths, the branch
prediction of the CPU can do its job. So, I'm not religious about
it; in practice it should make little difference either way. 

My patch was aiming for a zerocost possibility to turn CONFIG_SECURITY
on. With the unlikely(), I should have gotten as close as one ~1 or 2 
CPU cycles (compare plus correctly predicted branch). That's why I
put the unlikely.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>             [Koeln, DE]
Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL]
Linux: SUSE Labs (Head)        <garloff@suse.de>    [SUSE Nuernberg, DE]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2004-08-12  2:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-10  8:57 Kurt Garloff
2004-08-10 13:29 ` James Morris
2004-08-10 20:23   ` Chris Wright
2004-08-10 20:27     ` James Morris
2004-08-10 20:43       ` Chris Wright
2004-08-11  1:55         ` James Morris
2004-08-10 14:16 ` James Morris
2004-08-10 15:02   ` Alan Cox
2004-08-10 19:22     ` James Morris
2004-08-10 20:00       ` Chris Wright
2004-08-10 20:07         ` James Morris
2004-08-10 20:12           ` Chris Wright
2004-08-10 20:31             ` James Morris
2004-08-11  8:47               ` David Mosberger
2004-08-11 15:25                 ` Chris Wright
2004-08-11 18:12                   ` David Mosberger
2004-08-11 18:16                     ` Chris Wright
2004-08-11 22:22             ` Kurt Garloff
2004-08-12  1:23               ` James Morris
2004-08-12  3:58                 ` Greg KH
2004-08-12 18:15                   ` Chris Wright
2004-08-12 18:17                 ` Chris Wright
2004-08-16 14:19               ` Takashi Iwai
2004-08-11 22:19   ` Kurt Garloff
2004-08-12  1:20     ` James Morris
2004-08-12  2:03       ` Kurt Garloff [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=20040812020352.GI14744@tpkurt.garloff.de \
    --to=kurt@garloff.de \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.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

all inboxes | Powered by JetHome®