headers
John Ogness | 10 Jul 2008 20:55

nullfs progress

Hi,

I have finally checked nullfs into the Savannah CVS:

$ cvs -z3 \
  -d:pserver:anonymous <at> cvs.savannah.nongnu.org:/sources/dazuko \
  co dazuko/nullfs

I am now carefully going through the details of nullfs. Particularly,
I want to investigate every VFS hook and document why nullfs is (or is
not) taking the hook. I am also documenting some details about what
nullfs is doing using the kerneldoc format.

It is quite an undertaking, but I think it is important. It is
especially useful for developers to understand what nullfs is doing
(which is really the whole point of nullfs). As an example, I've
already completed the dentry source file:

http://cvs.savannah.gnu.org/viewvc/dazuko/nullfs/dentry.c?revision=1.2&root=dazuko&view=markup

However, dentry.c does have an "XXX" that still needs to be
resolved. This is the kind of stuff I am finding by carefully going
through the code.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 0 comments |
headers
John Ogness | 17 Jul 2008 20:28

2.3.6-pre1 posted

Hi,

I have posted a new pre-release (2.3.6-pre1). The main reason for this
version is to provide support for the new RedirFS 0.3 API. The only
other real change is that Dazuko has gone back to using GFP_KERNEL for
memory allocation on Linux 2.6.

Since this version does not include any changes related to LSM, it is
only available as the kernel module package.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 4 comments |
headers
Frantisek Hrbata | 21 Jul 2008 23:49
Favicon

problem with switch GFP_ATOMIC => GFP_KERNEL

Hi,

I am playing with redirfs + dazuko + avg and I found one problem in the dazuko.
Problem is with the switch you made from GFP_ATOMIC to GFP_KERNEL. 

dazuko_core.c: dazuko_is_selected(...)
        call_xp_read_lock(&(slist->lock_lists));
                        |
                        v
        kfs->aliases = (struct dazuko_file_listnode *)xp_malloc(sizeof(struct dazuko_file_listnode));

Here you are holding spinlock(slist->lock_lists == xp_rwlock ==  rwlock_t) and
you are calling kmalloc with the GFP_KERNEL. Allocation with GFP_KERNEL can
block and you can not block while you are holding a spinlock(possible dead
lock).

Jul 21 15:08:35 humpdell kernel: BUG: sleeping function called from invalid context at mm/slab.c:3054
Jul 21 15:08:35 humpdell kernel: in_atomic():1, irqs_disabled():0
Jul 21 15:08:35 humpdell kernel: INFO: lockdep is turned off.
Jul 21 15:08:35 humpdell kernel: Pid: 5219, comm: avgscan Tainted: GF 2.6.25.4 #26
Jul 21 15:08:35 humpdell kernel:
Jul 21 15:08:35 humpdell kernel: Call Trace:
Jul 21 15:08:35 humpdell kernel:  [<ffffffff8024d631>] ? __debug_show_held_locks+0x1b/0x24
Jul 21 15:08:35 humpdell kernel:  [<ffffffff8022bccd>] __might_sleep+0xd9/0xdb
Jul 21 15:08:35 humpdell kernel:  [<ffffffff80286a72>] __kmalloc+0x60/0xe1
Jul 21 15:08:35 humpdell kernel:  [<ffffffff88039ebb>] :dazuko:xp_malloc+0xe/0x10
Jul 21 15:08:35 humpdell kernel:  [<ffffffff88037d37>] :dazuko:dazuko_handle_request_get_an_access+0x1ce/0x657
Jul 21 15:08:35 humpdell kernel:  [<ffffffff803c13ca>] ? __up_read+0x1a/0x83
Jul 21 15:08:35 humpdell kernel:  [<ffffffff880384eb>] :dazuko:dazuko_handle_request+0x32b/0xe8e
Jul 21 15:08:35 humpdell kernel:  [<ffffffff8061fb7b>] ? _spin_unlock_irqrestore+0x4c/0x68
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tikka, Sami | 22 Jul 2008 08:53
Favicon

RE: 2.3.6-pre1 posted

The reason I asked about the flags used in memory allocation was we had a
problem on a customer machine where xp_malloc was returning NULL in the reply
message buffer allocation. We also tried GFP_KERNEL and kernel complained
about holding locks while calling kmalloc. Eventually we fixed it with: 

--- orig/dazuko_core.c
+++ mod/dazuko_core.c
 <at>  <at>  -3231,7 +3231,7  <at>  <at> 
        if (request->reply_buffer_size > 0)
        {
                /* allocate reply text buffer */
-               request->reply_buffer = (char
*)call_xp_malloc(request->reply_buffer_size + 1);
+               request->reply_buffer = (char
*)call_xp_bigmalloc(request->reply_buffer_size + 1);
                if (request->reply_buffer == NULL)
                {
                        error = XP_ERROR_FAULT;
 <at>  <at>  -3313,7 +3313,7  <at>  <at> 
                        call_xp_free(request->buffer);

                if (request->reply_buffer != NULL)
-                       call_xp_free(request->reply_buffer);
+                       call_xp_bigfree(request->reply_buffer);

                call_xp_free(request);
        }

Where xp_bigmalloc was defined with
(Continue reading)

Permalink | Reply | 3 comments |
headers
Frantisek Hrbata | 22 Jul 2008 16:30
Favicon

Re: 2.3.6-pre1 posted

On Tue, 22 Jul 2008 09:53:16 +0300
"Tikka, Sami" <sami.tikka <at> f-secure.com> wrote:

> The reason I asked about the flags used in memory allocation was we had a
> problem on a customer machine where xp_malloc was returning NULL in the reply
> message buffer allocation. We also tried GFP_KERNEL and kernel complained
> about holding locks while calling kmalloc. Eventually we fixed it with: 
> 
> --- orig/dazuko_core.c
> +++ mod/dazuko_core.c
>  <at>  <at>  -3231,7 +3231,7  <at>  <at> 
>         if (request->reply_buffer_size > 0)
>         {
>                 /* allocate reply text buffer */
> -               request->reply_buffer = (char
> *)call_xp_malloc(request->reply_buffer_size + 1);
> +               request->reply_buffer = (char
> *)call_xp_bigmalloc(request->reply_buffer_size + 1);
>                 if (request->reply_buffer == NULL)
>                 {
>                         error = XP_ERROR_FAULT;
>  <at>  <at>  -3313,7 +3313,7  <at>  <at> 
>                         call_xp_free(request->buffer);
>  
>                 if (request->reply_buffer != NULL)
> -                       call_xp_free(request->reply_buffer);
> +                       call_xp_bigfree(request->reply_buffer);
>  
>                 call_xp_free(request);
>         }
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Ogness | 28 Jul 2008 20:05

Re: 2.3.6-pre1 posted

On 2008-07-22, Frantisek Hrbata <frantisek.hrbata <at> avg.com> wrote:
> generally it is a bad idea to use GFP_ATOMIC for all allocations
> like dazuko did.  GFP_ATOMIC should be used only when it is really
> necessary, like in the irq where you can not block. With GFP_ATOMIC
> kernel has limited possibilities how to get memory(pages) for your
> allocation. So there is much bigger possibility that the allocation
> fails.

I've been reworking the locking to avoid mallocs while having a
lock. In many places, this is not proving to be easy.

But quite frankly, I was not aware that spinlocks were being used for
SMP. There is no reason that spinlocks are needed in *any* portion of
the Dazuko code. Dazuko uses locking primarily for inter-process
communication and very rarely for protecting critical sections.

I need to see what kinds of locks I am *supposed* to be using. Any
tips would be greatly appreciated. (ie. what types of locks may be
held while performing GFP_KERNEL memory allocation?)

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 1 comment |
headers
Frantisek Hrbata | 29 Jul 2008 03:54
Favicon

Re: 2.3.6-pre1 posted

On Mon, 28 Jul 2008 20:05:14 +0200
John Ogness <dazukolist <at> ogness.net> wrote:

> On 2008-07-22, Frantisek Hrbata <frantisek.hrbata <at> avg.com> wrote:
> > generally it is a bad idea to use GFP_ATOMIC for all allocations
> > like dazuko did.  GFP_ATOMIC should be used only when it is really
> > necessary, like in the irq where you can not block. With GFP_ATOMIC
> > kernel has limited possibilities how to get memory(pages) for your
> > allocation. So there is much bigger possibility that the allocation
> > fails.
> 
> I've been reworking the locking to avoid mallocs while having a
> lock. In many places, this is not proving to be easy.
> 
> But quite frankly, I was not aware that spinlocks were being used for
> SMP. There is no reason that spinlocks are needed in *any* portion of
> the Dazuko code. Dazuko uses locking primarily for inter-process
> communication and very rarely for protecting critical sections.
> 
> I need to see what kinds of locks I am *supposed* to be using. Any
> tips would be greatly appreciated. (ie. what types of locks may be
> held while performing GFP_KERNEL memory allocation?)

Hi,

you can use mutex(semaphore). It is safe to sleep while holding a mutex, 
because if other process can not acquire the mutex it is put to sleep and
rescheduled in contrast to spinlock. 

-FH
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ogness | 30 Jul 2008 23:34

2.3.6-pre2 posted

Hi,

I have gone through and relocated most of the memory allocation to be
outside of critical sections. The only remaining allocation in a
critical section is done behind a semaphore (which is not implemented
as a spinlock for now).

I also noticed that the trusted application code was doing
read_lock()'s in places where it should have been doing
write_lock()'s. If you are using the trusted application framework,
this is a significant bug fix. Previous versions may have experienced
crashes when adding/removing trusted applications.

2.3.6-pre2 is now available for download.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 0 comments |
headers
Ann Davis | 31 Jul 2008 00:49
Picon
Favicon

Problem in test w/ dazuko 2.3.6-pre1 and redirfs-0.3-pre3

Hello,

I have run into a problem testing on openSUSE-factory (kernel 2.6.26) 
with dazuko-2.6.3-pre1 and redifs-0.3-pre3.  I'm using the example_c 
user-space test that comes w/ dazuko.  Here are the details:

- To address the unknown symbols issue, I used a top-level Kbuild.
- I modified dazuko_core.c in accordance with 
http://lists.gnu.org/archive/html/dazuko-devel/2008-07/msg00002.html
- redirfs.ko and dazuko.ko load fine.
- /dev/dazuko exists.
- "example /home/test" gives the following output then seg faults:

DazukoIO version 2.3.6-pre1 (2.3.6.1)
registered with Dazuko successfully
Dazuko version 2.3.6-pre1 (2.3.6.1)
set access mask successfully
Segmentation fault

And after awhile I get a hard hang.  dmesg output is attached.  Any 
ideas? Maybe I just missed a config step...  Also, I know that 
openSUSE-factory is a development release, so I'll try it on 
openSUSE-11.0 as well.

Thanks,

Ann


(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane