From owner-freebsd-current  Sun May 14 05:52:01 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id FAA10046
          for current-outgoing; Sun, 14 May 1995 05:52:01 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA10039
          for <current@freebsd.org>; Sun, 14 May 1995 05:51:46 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA26068; Sun, 14 May 1995 22:48:40 +1000
Date: Sun, 14 May 1995 22:48:40 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199505141248.WAA26068@godzilla.zeta.org.au>
To: wpaul@ctr.columbia.edu
Subject: Re: kern/400: fade_saver loadable kernel module crashes system
Cc: current@FreeBSD.org
Sender: current-owner@FreeBSD.org
Precedence: bulk

>>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