From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4378956D.8040706@domain.hid> Date: Mon, 14 Nov 2005 14:47:25 +0100 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-help] printk References: <43788F9B.4070007@domain.hid> In-Reply-To: <43788F9B.4070007@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: xenomai@xenomai.org Philippe Gerum wrote: > Dmitry Adamushko wrote: > >> Philippe Gerum wrote on 14.11.2005 12:26:08: >> >> > >> >> > >>Although, here is, well, a tiny race because of the fact that the >> virq >> > >>handler doesn't lock a buffer-related data (like >> __ipipe_printk_fill) >> > >>so a loss of data may occur under some circumstances. >> > >> >> > >> > Nope. __ipipe_printk_fill and friends are manipulated under hw irq >> > spinlocking >> > in printk(), and under Linux domain stalling protection in >> > __ipipe_flush_printk >> > since it's a virq handler, >> >> So what prevents some activity from the primary domain from preempting >> __ipipe_flush_printk() and calling printk() when _only_ the Linux >> domain is stalled? > > > This cannot happen in async mode, since the output would be buffered and > printk() never called on behalf of the preempted handler. > >> >> let's say at the (*) point >> >> void __ipipe_flush_printk (unsigned virq) >> { >> char *p = __ipipe_printk_buf; >> int out = 0, len; >> >> clear_bit(IPIPE_PPRINTK_FLAG,&ipipe_root_domain->flags); >> >> while (out < __ipipe_printk_fill) { >> len = strlen(p) + 1; >> printk("%s",p); >> p += len; >> out += len; >> } >> (*) <---------------------------- preempted >> __ipipe_printk_fill = 0; >> } >> >> When linux gets controll back the virq continues its execution and >> sets __ipipe_printk_fill up to 0. >> >> This cannot happen only if virqs are manipulated with the primary >> domain being stalled as well. But you told "and under __Linux >> domain___ stalling protection in __ipipe_flush_printk since it's a >> virq handler". >> >> >> > and finally, printk() cannot preempt >> > __ipipe_flush_printk under normal operation mode (i.e. async mode). >> AFAICS, >> > there's no race here. Mea culpa, Dmitry is right, in the above situation he depicted, we could drop a portion of the output buffer. A way to fix this would be to hw lock a test and decrement section of __ipipe_printk_fill in the flush handler. -- Philippe.