On Tue, 2004-07-27 at 13:02, Marc Kleine-Budde wrote: > On Tue, Jul 27, 2004 at 12:50:34PM +0200, Gilles Chanteperdrix wrote: > > Marc Kleine-Budde wrote: > > > Hi Philippe! > > > > > > I'm using linux-2.6.7 with Adeos 2.6r6c4/x86, gcc version 3.3.4 (Debian > > > 1:3.3.4-3) and the latest fusion CVS co. > > > > > > On one console I was running 'watch -n 1 cat /proc/rtai/system' and on > > > another unloading the core modules (rtai_nucleus and rtai_hal). I got a > > nice > > > Linux-Kerneloops, system kept running. Further 'cat /proc/rtai/system' > > > got killed due to segfaults. > > > In order not to have too much performance impact, the xnpod_read_proc > > function does not hold the big lock for too long sections. So, it may > > happen that the nkpod pointer become NULL between the time it is read > > and the time it is used. > > As Jan said to me yesterday - proc is only a debug interface, so it > should not harm the rt. performance. >
You may need to mask the interrupts out when accessing some internal information from your RTOS so as to dump them (just consider that a RT task can wake up in the middle of your printing and may alter the scheduling queues you are currently scanning...), and as such, you incur jitter. I agree that this is only a debug interface, but things being what they are, you have just yourself illustrated that it can be used during a latency test (in loop), so the proper fix must be applied here. > I havn't coded any proc stuff at all....but this problem occoured during > unloading of the module. Not the runtime....Every cat /proc/rtai/system > after that fist, that segfaulted, got killed by segfault, too. > > > If you want to avoid that, I suppose you should check that nkpod is not > > NULL in several other places. > > Perhaps one should keep in mind that nkpod could be NULL during in the > proc routined, this should not harm realtime performance. > Fixing readproc by locking the kernel during execution should be enough, this way, module unloading would have to wait for readproc to have completed, and nkpod would never be used unsafely. > But I think the overall performace problem is more important.... > Well, sure, but I still see none ;o) > marc -- Philippe.
