Hello.
Peter Zijlstra wrote:
append_function() {
down(semaphore_for_write_protect);
...
ptr = head;
while (ptr-next) ptr = ptr-next;
ptr-next = new_entry;
...
up(semaphore_for_write_protect);
}
If at all possible, use struct mutex.
Fixed in the fourth
Hello.
James Morris wrote:
It seems that standard kernel list API does not have singly-linked list
manipulation.
I'm considering the following list manipulation API.
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
OK. I
About use of singly-linked list:
What my SLL (singly-linked list) holds is bit different from other lists.
Almost all lists hold list of elements (e.g. buffer) that are used
*temporarily*.
Thus, adding to the list and removing from the list are essential.
My SLL holds ACL (access control
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:
Domain transition functions for TOMOYO Linux.
Every process belongs to a domain in TOMOYO Linux.
Domain transition occurs when execve(2) is called
and the domain is expressed as 'process invocation history',
such as 'kernel /sbin/init /etc/init.d/rc'.
Domain information is stored in
On Tue, 2 Oct 2007, Kentaro Takeda wrote:
+
+ mb(); /* Instead of using spinlock. */
+ ptr = domain_initializer_list;
+ if (ptr) {
+ while (ptr-next)
+ ptr = ptr-next;
+ ptr-next = new_entry;
+ } else
+
Hello.
Thank you for your comment.
James Morris wrote:
Why do you need to avoid spinlocks for these manipulations?
I don't need to use spinlocks here.
What I need to do here is avoid read/write reordering,
so mb() will be appropriate here.
struct something {
struct something *next;
void
In article [EMAIL PROTECTED] (at Tue, 2 Oct 2007 21:44:57 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
If I use struct hlist_node which has two pointers,
it needs more memory than struct something which has one pointer.
It is possible to use API defined in include/linux/list.h ,
but to
On Tue, 2 Oct 2007, Tetsuo Handa wrote:
Hello.
Thank you for your comment.
James Morris wrote:
Why do you need to avoid spinlocks for these manipulations?
I don't need to use spinlocks here.
What I need to do here is avoid read/write reordering,
so mb() will be appropriate here.
22 matches
Mail list logo
