Date: Tue, 23 Mar 2010 22:07:05 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Dmitry Krivenok <krivenok.dmitry@gmail.com> Subject: Re: Strange behavior of kernel module (output terminated) Message-ID: <86zl1y4uiu.fsf@ds4.des.no> In-Reply-To: <201003231000.58961.jhb@freebsd.org> (John Baldwin's message of "Tue, 23 Mar 2010 10:00:58 -0400") References: <da48cf211003230218n56794f0bs27eef860efc0da3e@mail.gmail.com> <86ocifcmew.fsf@ds4.des.no> <201003231000.58961.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin <jhb@freebsd.org> writes: > Dag-Erling Sm=C3=B8rgrav <des@des.no> writes: > > I'm not sure it's such a good idea to use uprintf() here. The event > > handler can be called in non-process context. > If you are doing a kldload post-boot it is actually done from some sort o= f=20 > process context. We run module handlers synchronously from the kldload(2= )=20 > syscall. Sure, but not when the module is loaded by the boot loader (note "can", not "will") > > You filled up a buffer somewhere... > Does uprintf() require the caller to flush the output to the tty somehow?= If=20 > so, that seems to be a bug. Nothing in the uprintf(9) manpage suggests t= hat=20 > the output should be manually flushed. I tried to read through the uprinf() code paths (into the tty layer etc). I didn't get very far, but I discovered two things: 1) The printf() code uses uninitialized or partially-initialized variables (grep pca) 2) There may be conditions in which tty_putchar() fails due to a buffer filling up, though I'm not sure they apply in this particular situation. Since uprintf() returns the number of characters actually written, this is easy to test. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86zl1y4uiu.fsf>