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 AP
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
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 list)
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
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 add
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 fas
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 ad
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:
> Regardi
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 th
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
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 aft
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 be
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() mak
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) First,
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 Linu
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) Late
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 init
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 followin
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 we
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 k
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
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
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 ,
> b
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
> + do
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 task_struct->security
27 matches
Mail list logo
