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
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
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
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
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
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
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
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
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
On Wed, 2007-10-03 at 23:26 +0900, Tetsuo Handa wrote:
> 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 iteration + concurrent removal scenario:
>
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
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 iteration + concurrent removal scenario:
Regarding my singly-linked list, no entries are removed from the list.
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
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
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()
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: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
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)
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, 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
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
Hello.
YOSHIFUJI Hideaki wrote:
> Introducing your own list is not good.
> Please use hlist or introduce new "slist".
James Morris wrote:
> You're introducing a custom API, which is open-coded repeatedly throughout
> your module.
>
> All linked lists (at least, new ones) must use the standard
Hello.
YOSHIFUJI Hideaki wrote:
Introducing your own list is not good.
Please use hlist or introduce new slist.
James Morris wrote:
You're introducing a custom API, which is open-coded repeatedly throughout
your module.
All linked lists (at least, new ones) must use the standard kernel
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
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 iteration + concurrent removal scenario:
Regarding my singly-linked list, no entries are removed from the list. It's
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:26 +0900, Tetsuo Handa wrote:
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 iteration + concurrent removal scenario:
Regarding my
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,
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)
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:
James Morris <[EMAIL PROTECTED]> writes:
>
> All linked lists (at least, new ones) must use the standard kernel list
> API.
Really? Why? That rule is new to me.
Would also seem very limiting especially since the standard kernel lists
do not allow to express important patterns (like single
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
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 ,
>
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
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
> +
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 ' /sbin/init /etc/init.d/rc'.
Domain information is stored in
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.
James Morris [EMAIL PROTECTED] writes:
All linked lists (at least, new ones) must use the standard kernel list
API.
Really? Why? That rule is new to me.
Would also seem very limiting especially since the standard kernel lists
do not allow to express important patterns (like single linked
54 matches
Mail list logo
