In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
It seems that standard kernel list API does not have singly-linked list
manipulation.
I'm considering the following list manipulation API.
Tstsuo, please name it slist, which is
On Wed, 3 Oct 2007, YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote:
In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
It seems that standard kernel list API does not have singly-linked list
manipulation.
I'm considering the following list
In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 22:04:11 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is initialized with NULL.
(2) Later,
James Morris wrote:
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is
On Wed, 2007-10-03 at 22:04 +0900, Tetsuo Handa wrote:
James Morris wrote:
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids
Tetsuo Handa wrote:
James Morris wrote:
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1)
On Wed, 2007-10-03 at 22:59 +0900, Tetsuo Handa wrote:
Hello.
KaiGai Kohei wrote:
If so, you can apply RCU instead to avoid read lock
when scanning the list, like:
rcu_read_lock();
list_for_each_entry(...) {
}
rcu_read_unlock();
Can I sleep between
Hello.
Thank you for pointing out.
Peter Zijlstra wrote:
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is initialized with NULL.
(2) Later, ptr-next is assigned non-NULL address.
(3) Assigning to ptr-next is done atomically.
(4) wmb after asigning
Hello.
KaiGai Kohei wrote:
If so, you can apply RCU instead to avoid read lock
when scanning the list, like:
rcu_read_lock();
list_for_each_entry(...) {
}
rcu_read_unlock();
Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
As far as I saw, rcu_read_lock() makes
In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
Peter Zijlstra wrote:
Also, how do you avoid referencing dead data with your sll? I haven't
actually looked at your patches, but the simple scheme you outlined
didn't handle the
On Wed, 2007-10-03 at 23:19 +0900, Tetsuo Handa wrote:
Hello.
Thank you for pointing out.
Peter Zijlstra wrote:
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is initialized with NULL.
(2) Later, ptr-next is assigned non-NULL address.
(3)
On Wed, 3 Oct 2007, Tetsuo Handa wrote:
Regarding my singly-linked list, no entries are removed from the list.
It's append only (like CD-R media). I set is_deleted flag of a entry
instead of removing the entry from the list.
Why so?
This smells like a horrible leaking of memory. How fast
On Wed, 3 Oct 2007, YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote:
In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
Peter Zijlstra wrote:
Also, how do you avoid referencing dead data with your sll? I haven't
actually looked at your patches,
Hello.
YOSHIFUJI Hideaki wrote:
It is not a good practice. Please free such objects.
BTW, how many objects do you have in the list?
It varies from 0 to some thousands,
depending on the policy supplied by the administrator and/or the policy
appended by learning mode.
Peter Zijlstra wrote:
--- Al Viro [EMAIL PROTECTED] wrote:
On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote:
From: Casey Schaufler [EMAIL PROTECTED]
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels
attached to tasks
On Wed, Oct 03, 2007 at 07:17:35PM +0100, Alan Cox wrote:
Absolute paths in that kind of thing are _wrong_. You know where the things
are on your fs. You don't know if anything else will be visible, let alone
whether it will be at the same place in all chroots or namespaces. And no,
you
--- Al Viro [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote:
what
happens if we want it in two chroot jails with different layouts?
As you can only have /smack mounted once, this isn't an issue,
but it does present an interesting use case
--- Alan Cox [EMAIL PROTECTED] wrote:
Absolute paths in that kind of thing are _wrong_. You know where the
things
are on your fs. You don't know if anything else will be visible, let alone
whether it will be at the same place in all chroots or namespaces. And no,
you _can't_ make
An embedded system that does not have user logins but that does
have applications that require separation, perhaps a moble communication
device with application download capability, is just one example
where the smack symlink implementation provides the required
function without requiring
--- Alan Cox [EMAIL PROTECTED] wrote:
An embedded system that does not have user logins but that does
have applications that require separation, perhaps a moble communication
device with application download capability, is just one example
where the smack symlink implementation provides
--- Al Viro [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote:
Because you throw simple out the window when you require userland
assistance to perform this function.
Any more than having /tmp replaced with a symlink?
Yes. By the way,
From 54c70ca7671750fe8986451fae91d42107d0ca90 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Fri, 28 Sep 2007 10:33:33 -0500
Subject: [PATCH 1/2 -mm] capabilities: define CONFIG_COMMONCAP
currently the compilation of commoncap.c is determined
through Makefile logic. So
From d93ecb90d82f9e2b7f48c74f5e6ed97cac3683c7 Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Fri, 28 Sep 2007 10:33:56 -0500
Subject: [PATCH 2/2 -mm] capabilities: introduce per-process capability
bounding set (v4)
The capability bounding set is a set beyond which
On Wed, 3 Oct 2007, Serge E. Hallyn wrote:
From 54c70ca7671750fe8986451fae91d42107d0ca90 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Fri, 28 Sep 2007 10:33:33 -0500
Subject: [PATCH 1/2 -mm] capabilities: define CONFIG_COMMONCAP
currently the compilation of
On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote:
1. Create /moldy at _
2. For each label you care about
2a. Create /moldy/label
2b. Set the label of /moldy/label to label
3. ln -s /smack/tmp /tmp
1. Create /moldy at _
2. For each label you care about
2a. Create
25 matches
Mail list logo
