Date: Sun, 14 May 1995 22:48:40 +1000 From: Bruce Evans <bde@zeta.org.au> To: wpaul@ctr.columbia.edu Cc: current@FreeBSD.org Subject: Re: kern/400: fade_saver loadable kernel module crashes system Message-ID: <199505141248.WAA26068@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>Number: 400 >>Category: kern >>Synopsis: fade_saver loadable kernel module crashes system > The fade_saver loadable screen saver module causes a fatal > kernel trap when it activates. It can be modload'ed just fine, > but as soon as syscons activates it, the system panics. I'll fix this in a few minutes. <saver.h> declares `palette' as char *, but it is actually char []. The first 4 bytes happen of palette[] happen to be 0's, so a null pointer is dereferenced. The declaration has apparently been wrong ever since the savers were lkm'ed so I don't see how the fade saver could have worked recently. > Also note that 'make load' does not seem to work for > for any of the syscons screen saver modules. It should. Is this just because the entry point is wrong? I noticed some other problems (as someone who knows very little about lkms): - bsd.subdir.mk doesn't support the `load' target. This may be a feature. - the output file is in the object directory so writing it fails when the object dir is nfs mounted and `make load' is run by root. modload has to be run by root :-). - the PR reports more than one bug so it is hard to close :-). > I don't suppose it's occured to anyone what could happen if > a clueless user tries to load a syscons saver module into > a kernel that doesn't have the syscons driver in it? It might I think the load will often fail because the entry point is wrong. Another bug that may be a feature! Perhaps entry points should be named DriverName_LkmEntry_RoutineName[_VersionCookie] to exploit this. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505141248.WAA26068>