Hi Hans,
Possibly the new named fifo interface in rtai-1.4 may solve your
problem. If you're on RTLinux, you could port the rtai fifo module to
make it work on both (or add the code to the RTL module).
Regards, Stuart
Hans de Goede wrote:
>
> Hi all,
>
> I'm busy designing an realtime linux app using rtlinux and I encountered
> the following problem causing an oops, or if a module is loaded at the
> address of a previously loaded one even worse things. I have managed to
> reproduce it using something as simple as frank-app.
>
> I'll first describe my thought pattern that let me to the problem, to
> show that there is a deeper problem which is the cause of this. Then
> I'll describe the real problem, followed by an (ugly?!) solution to fix
> both.
>
> Problem:
> rtf_destroy is usually used from cleanup_module, cleanup_module is void,
> yet rtf_destroy can fail (when userspace progs still have the fifo
> open).
>
> This is usually fixed by just destroying all fifo's you use before
> creating them in init_module. I didn't want todo this since in our
> application multiple persons can write rttasks and I want to have the
> protection of rtf_create failing if multiple tasks accidentily try to
> use the same fifo.
>
> The fix for this is ofcourse to have a well defined list of fifo's so
> that people won't try to use the same fifo.
>
> But I still thought that having todo rtf_destroy in init_module is not
> clean, and that there really should be a way to INC_MOD_USE_COUNT of
> your module/task when the user opens an rtfifo you've created, so that
> cleanup_module won't be called with the fifo is open by a userspace
> program.
>
> While searching for a workaround since I didn't want to change the
> rt_fifo.c code I encountered the following scenario:
>
> rt_task.c:
>
> init_module
> {
> rtf_create(1, whatever)
> rtf_create_handler(1, my_handler)
> }
>
> cleanup_module
> {
> rtf_destroy(1)
> }
>
> now do the following:
> -insmod rt_task.o -> fifo is created successfully
> -have a task open /dev/rtf1
> -rmmod rt_task.o -> fifo is not destroyed because it is open
> -have the task write to /dev/rtf1 -> my_handler (which is no longer) is
> called -> oops (or worse if a new / other module was loaded at that
> address
>
> IMHO the only correct fix is to INC_MOD_USE_COUNT of rt_task.o when
> /dev/rtf1 is opened, and DEC it again when it is closed. This would
> require a callback function argument to rtf_create, since you can only
> use INC_MOD_USE_COUNT from the actual module itself. This seems to be
> the correct thing todo always, and is a must have when using handlers
> since in essence the rt_fifo module has a reference to the rt_task
> module, and hence the rt_task module is in use.
>
> For the unbelievers this can easiliy be recreated with the frank
> example,
>
> insmod frank_module.o
> ./frank_app&
> rmmod frank_module
>
> Now just wait for all the selects in frank_app to time out (about 100
> seconds) then it will try to write to /dev/rtf3 which has a handler to
> stop the tasks -> oops.
>
> Regards,
>
> Hans
>
> p.s.
>
> I'm working on a fix and I'll mail it as a patch to the list when I'm
> ready.
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
