From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: linux-kernel@vger.kernel.org
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
Paul Moore <paul.moore@hp.com>,
selinux@tycho.nsa.gov, Yuichi Nakamura <ynakam@hitachisoft.jp>,
James Morris <jmorris@namei.org>,
Eric Paris <eparis@parisplace.org>
Subject: Wrappers to load bitmaps (Re: [PATCH] Improve ebitmap scanning)
Date: Fri, 14 Sep 2007 10:02:57 +0900 [thread overview]
Message-ID: <46E9DDC1.2060401@ak.jp.nec.com> (raw)
In-Reply-To: <1189683270.13723.5.camel@moss-spartans.epoch.ncsc.mil>
Now I'm improving the performance to scan bitmap in SELinux,
with replacing its original bitmap implementation (ebitmap)
by common bitops like find_next_bit().
I posted a patch to replace them, however, it got a bit complex
bacause we had to translate u64 <--> unsigned long by myself
to adjust between the format of security policy and common bitops.
http://marc.info/?l=selinux&m=118956715414494&w=2
I have an idea to provide several wrapper functions to copy u64/u32
to/from unsigned long for each architecture.
Maybe, it will be defined as follows:
int arraycpy_u64_to_ulong(u64 *src, unsigned long *dest, size_t len);
int arraycpy_ulong_to_u64(unsigned long *src, u64 *dest, size_t len);
I believe this feature will help getting code simpler and reducing bugs
for any other subsystem, not only SELinux, which loads bitmaps from/to
userspace and handle them using common bitops.
Any comment please.
Stephen Smalley wrote:
> On Thu, 2007-09-13 at 10:37 +0900, KaiGai Kohei wrote:
>> Paul Moore wrote:
>>> On Tuesday, September 11 2007 11:08:44 pm KaiGai Kohei wrote:
>>>> The attached patch applies the standard bitmap operations
>>>> for the iteration macro of ebitmap, and enables to improve
>>>> the performance in AVC-misses case.
<...snip...>
>> BTW, is there any wrapper to copy an array of u64 to/from architecture specific
>> unsigned long? If so, it will help implement ebitmap_netlbl_{import|export}()
>> and ebitmap_read() more simply.
>
> Might want to ask on linux-kernel. More generally, it might be a good
> idea to cc linux-kernel on your next posting of the patch to get wider
> review of how you are using the native linux bitmap support.
>
> The patch looks very promising, although a detailed review and testing
> might take a little bit.
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
WARNING: multiple messages have this Message-ID (diff)
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: linux-kernel@vger.kernel.org
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
Paul Moore <paul.moore@hp.com>,
selinux@tycho.nsa.gov, Yuichi Nakamura <ynakam@hitachisoft.jp>,
James Morris <jmorris@namei.org>,
Eric Paris <eparis@parisplace.org>
Subject: Wrappers to load bitmaps (Re: [PATCH] Improve ebitmap scanning)
Date: Fri, 14 Sep 2007 10:02:57 +0900 [thread overview]
Message-ID: <46E9DDC1.2060401@ak.jp.nec.com> (raw)
In-Reply-To: <1189683270.13723.5.camel@moss-spartans.epoch.ncsc.mil>
Now I'm improving the performance to scan bitmap in SELinux,
with replacing its original bitmap implementation (ebitmap)
by common bitops like find_next_bit().
I posted a patch to replace them, however, it got a bit complex
bacause we had to translate u64 <--> unsigned long by myself
to adjust between the format of security policy and common bitops.
http://marc.info/?l=selinux&m=118956715414494&w=2
I have an idea to provide several wrapper functions to copy u64/u32
to/from unsigned long for each architecture.
Maybe, it will be defined as follows:
int arraycpy_u64_to_ulong(u64 *src, unsigned long *dest, size_t len);
int arraycpy_ulong_to_u64(unsigned long *src, u64 *dest, size_t len);
I believe this feature will help getting code simpler and reducing bugs
for any other subsystem, not only SELinux, which loads bitmaps from/to
userspace and handle them using common bitops.
Any comment please.
Stephen Smalley wrote:
> On Thu, 2007-09-13 at 10:37 +0900, KaiGai Kohei wrote:
>> Paul Moore wrote:
>>> On Tuesday, September 11 2007 11:08:44 pm KaiGai Kohei wrote:
>>>> The attached patch applies the standard bitmap operations
>>>> for the iteration macro of ebitmap, and enables to improve
>>>> the performance in AVC-misses case.
<...snip...>
>> BTW, is there any wrapper to copy an array of u64 to/from architecture specific
>> unsigned long? If so, it will help implement ebitmap_netlbl_{import|export}()
>> and ebitmap_read() more simply.
>
> Might want to ask on linux-kernel. More generally, it might be a good
> idea to cc linux-kernel on your next posting of the patch to get wider
> review of how you are using the native linux bitmap support.
>
> The patch looks very promising, although a detailed review and testing
> might take a little bit.
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
next prev parent reply other threads:[~2007-09-14 1:02 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-21 4:29 [patch] Tuning avtab to reduce memory usage Yuichi Nakamura
2007-08-21 13:47 ` Stephen Smalley
2007-08-21 14:19 ` Yuichi Nakamura
2007-08-21 15:11 ` Paul Moore
2007-08-21 16:37 ` Stephen Smalley
2007-08-21 16:55 ` Paul Moore
2007-08-22 9:25 ` KaiGai Kohei
2007-09-12 3:08 ` KaiGai Kohei
2007-09-12 19:54 ` Paul Moore
2007-09-13 1:37 ` [PATCH] Improve ebitmap scanning (Re: [patch] Tuning avtab to reduce memory usage) KaiGai Kohei
2007-09-13 11:34 ` Stephen Smalley
2007-09-14 1:02 ` KaiGai Kohei [this message]
2007-09-14 1:02 ` Wrappers to load bitmaps (Re: [PATCH] Improve ebitmap scanning) KaiGai Kohei
2007-09-13 20:47 ` [PATCH] Improve ebitmap scanning (Re: [patch] Tuning avtab to reduce memory usage) Paul Moore
2007-09-18 17:21 ` [patch] Tuning avtab to reduce memory usage Stephen Smalley
2007-09-18 22:11 ` Paul Moore
2007-09-20 8:14 ` KaiGai Kohei
2007-09-21 19:21 ` Stephen Smalley
2007-09-25 5:06 ` KaiGai Kohei
2007-09-25 12:04 ` Paul Moore
2007-09-25 13:53 ` Stephen Smalley
2007-09-26 5:49 ` [PATCH] Improve SELinux performance when AVC misses KaiGai Kohei
2007-09-27 2:22 ` KaiGai Kohei
2007-09-27 2:43 ` KaiGai Kohei
2007-09-27 20:47 ` James Morris
2007-09-28 10:56 ` KaiGai Kohei
2007-09-28 14:47 ` Stephen Smalley
2007-09-28 17:20 ` KaiGai Kohei
2007-09-28 18:40 ` Stephen Smalley
2007-09-28 21:09 ` James Morris
2007-10-02 15:12 ` KaiGai Kohei
2007-10-02 15:28 ` Stephen Smalley
2007-10-03 13:41 ` KaiGai Kohei
2007-10-03 14:42 ` KaiGai Kohei
2007-10-04 0:37 ` James Morris
2007-08-21 14:00 ` [patch] Tuning avtab to reduce memory usage James Morris
2007-08-22 2:55 ` Yuichi Nakamura
2007-08-22 3:42 ` KaiGai Kohei
2007-08-22 13:44 ` James Morris
2007-08-23 0:57 ` Yuichi Nakamura
2007-08-23 13:15 ` Stephen Smalley
2007-08-24 2:55 ` Yuichi Nakamura
2007-08-27 13:39 ` Stephen Smalley
2007-08-27 16:55 ` James Morris
2008-01-31 21:00 ` Stephen Smalley
2008-01-31 21:44 ` Stephen Smalley
2008-02-01 4:59 ` Yuichi Nakamura
2007-08-23 14:46 ` James Morris
2007-08-24 2:33 ` Yuichi Nakamura
2007-08-22 16:05 ` James Morris
2007-08-21 19:43 ` J. Tang
2007-08-22 3:11 ` Yuichi Nakamura
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=46E9DDC1.2060401@ak.jp.nec.com \
--to=kaigai@ak.jp.nec.com \
--cc=eparis@parisplace.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.moore@hp.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=ynakam@hitachisoft.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.