[Xenomai-help] Proper module_cleanup procedure

[Xenomai-help] Proper module_cleanup procedure

[Randy Smith]

Hello,

I am running the 2.4 kernel with Xenomai-2.1.0 native skin and I have a 
kernel module that creates 2 shared memory heaps and then creates a a 
periodic realtime task to do some interesting things.  This periodic 
realtime task communicates with a linux user mode task through the 
shared memory that gains access to it through rt_heap_bind/rt_heap_alloc 
calls.  Things go along swimmingly.

I now want to be able to do an "rmmod" on the module and in its cleanup 
routine, right now I just have rt_heap_delete calls for the two shared 
memory heaps.  This completes successfully, but if I then try to install 
another version (debug for instance) of the module with "insmod", I get 
a memory error. 

Is this is due to the fact that I didn't suspend the periodic realtime 
task and then delete it before deleting the heaps?  Is this necessary?  
Are there any use counts or other signs that I could check to ensure 
that everyone was finished with the heaps so that I can delete them?

Is there any consequence to the user mode task due to jerking the rug 
out from under it?

Thanks,

Randy Smith
Software Engineer
ImageMap, Inc.

[Xenomai-help] Re: Proper module_cleanup procedure

[Randy Smith]

Anyone?...Is this mike on?

Randy Smith wrote:
> Hello,
>
> I am running the 2.4 kernel with Xenomai-2.1.0 native skin and I have 
> a kernel module that creates 2 shared memory heaps and then creates a 
> a periodic realtime task to do some interesting things.  This periodic 
> realtime task communicates with a linux user mode task through the 
> shared memory that gains access to it through 
> rt_heap_bind/rt_heap_alloc calls.  Things go along swimmingly.
>
> I now want to be able to do an "rmmod" on the module and in its 
> cleanup routine, right now I just have rt_heap_delete calls for the 
> two shared memory heaps.  This completes successfully, but if I then 
> try to install another version (debug for instance) of the module with 
> "insmod", I get a memory error.
> Is this is due to the fact that I didn't suspend the periodic realtime 
> task and then delete it before deleting the heaps?  Is this 
> necessary?  Are there any use counts or other signs that I could check 
> to ensure that everyone was finished with the heaps so that I can 
> delete them?
>
> Is there any consequence to the user mode task due to jerking the rug 
> out from under it?
>
> Thanks,
>
> Randy Smith
> Software Engineer
> ImageMap, Inc.
>

Re: [Xenomai-help] Re: Proper module_cleanup procedure

[Gilles Chanteperdrix]

Randy Smith wrote:
 > Anyone?...Is this mike on?
 > 
 > Randy Smith wrote:
 > > Hello,
 > >
 > > I am running the 2.4 kernel with Xenomai-2.1.0 native skin and I have 
 > > a kernel module that creates 2 shared memory heaps and then creates a 
 > > a periodic realtime task to do some interesting things.  This periodic 
 > > realtime task communicates with a linux user mode task through the 
 > > shared memory that gains access to it through 
 > > rt_heap_bind/rt_heap_alloc calls.  Things go along swimmingly.
 > >
 > > I now want to be able to do an "rmmod" on the module and in its 
 > > cleanup routine, right now I just have rt_heap_delete calls for the 
 > > two shared memory heaps.  This completes successfully, but if I then 
 > > try to install another version (debug for instance) of the module with 
 > > "insmod", I get a memory error.
 > > Is this is due to the fact that I didn't suspend the periodic realtime 
 > > task and then delete it before deleting the heaps?  Is this 
 > > necessary?  Are there any use counts or other signs that I could check 
 > > to ensure that everyone was finished with the heaps so that I can 
 > > delete them?
 > >
 > > Is there any consequence to the user mode task due to jerking the rug 
 > > out from under it?

You should probably delete the task using the heaps before deleting the
heaps. But I am not sure of the kind of error you would get when
failing to do it. In order to know if the error you encounter is due to
this or a bug, we need a concrete (and preferably minimal) excerpt of
code.

For the general issue of the cleanup of a mixt (kernel-space/user-space)
application, I would lock the module with try_module_get when it is
currently used by a user-space application. Actually, I have done it for
the xeno_switchtest module, opening the RTDM device locks the module and
closing the device unlocks it.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Re: Proper module_cleanup procedure

[Randy Smith]

Thanks for all of your help and just a quick follow up on this.

I added a call to rt_task_delete() in my module cleanup routine and this 
cleared the memory error I was getting whenever I tried to unload the 
module and then load it again.

I am still trying to discover some mechanism by which the kernel module 
can determine if a particular heap is in use by a user-mode app without 
having coordinating code in the user app. Don't want to jerk the rug out 
from under the user app by deleting the heap before the user app is 
finished with it.

-Randy Smith
Software Engineer,
ImageMap, Inc.


Gilles Chanteperdrix wrote:
> Randy Smith wrote:
>  > Anyone?...Is this mike on?
>  > 
>  > Randy Smith wrote:
>  > > Hello,
>  > >
>  > > I am running the 2.4 kernel with Xenomai-2.1.0 native skin and I have 
>  > > a kernel module that creates 2 shared memory heaps and then creates a 
>  > > a periodic realtime task to do some interesting things.  This periodic 
>  > > realtime task communicates with a linux user mode task through the 
>  > > shared memory that gains access to it through 
>  > > rt_heap_bind/rt_heap_alloc calls.  Things go along swimmingly.
>  > >
>  > > I now want to be able to do an "rmmod" on the module and in its 
>  > > cleanup routine, right now I just have rt_heap_delete calls for the 
>  > > two shared memory heaps.  This completes successfully, but if I then 
>  > > try to install another version (debug for instance) of the module with 
>  > > "insmod", I get a memory error.
>  > > Is this is due to the fact that I didn't suspend the periodic realtime 
>  > > task and then delete it before deleting the heaps?  Is this 
>  > > necessary?  Are there any use counts or other signs that I could check 
>  > > to ensure that everyone was finished with the heaps so that I can 
>  > > delete them?
>  > >
>  > > Is there any consequence to the user mode task due to jerking the rug 
>  > > out from under it?
>
> You should probably delete the task using the heaps before deleting the
> heaps. But I am not sure of the kind of error you would get when
> failing to do it. In order to know if the error you encounter is due to
> this or a bug, we need a concrete (and preferably minimal) excerpt of
> code.
>
> For the general issue of the cleanup of a mixt (kernel-space/user-space)
> application, I would lock the module with try_module_get when it is
> currently used by a user-space application. Actually, I have done it for
> the xeno_switchtest module, opening the RTDM device locks the module and
> closing the device unlocks it.
>
>   

Re: [Xenomai-help] Re: Proper module_cleanup procedure

[gilles.chanteperdrix]

---------- Debut du message initial -----------

De     : xenomai-help-bounces@domain.hid
A      : xenomai@xenomai.org
Copies :
Date   : Thu, 28 Sep 2006 09:09:36 -0400
Objet  : Re: [Xenomai-help] Re: Proper module_cleanup procedure

> Thanks for all of your help and just a quick follow up on this.
>
> I added a call to rt_task_delete() in my module cleanup
routine and this
> cleared the memory error I was getting whenever I tried to
unload the
> module and then load it again.
>
> I am still trying to discover some mechanism by which the
kernel module
> can determine if a particular heap is in use by a user-mode
app without
> having coordinating code in the user app. Don't want to jerk
the rug out
> from under the user app by deleting the heap before the user
app is
> finished with it.

If you are already in the module cleanup function, what are
you going
to do if you detect that a user-mode application is using the
module ?
You can not have the module cleanup function fail, it is too
late. So,
my advice is to lock the module with try_module_get as long as
the heap
are being used by user-space. Of course, this require calling
some ioctl
in user-space, but it looks like a small price to pay.

--
                 Gilles Chanteperdrix


Accédez au courrier électronique de La Poste
sur www.laposte.net ou sur 3615 LAPOSTENET (0,34€ TTC /mn)
1 Giga de stockage gratuit – Antispam et antivirus intégrés