[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/55154 (Running sysctl test on macppc in qemu triggers panic)
The following reply was made to PR kern/55154; it has been noted by GNATS.
From: Martin Husemann <martin%duskware.de@localhost>
To: Paul Goyette <paul%whooppee.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, joerg%NetBSD.org@localhost, pgoyette%netbsd.org@localhost
Subject: Re: kern/55154 (Running sysctl test on macppc in qemu triggers panic)
Date: Thu, 9 Apr 2020 16:46:18 +0200
On Thu, Apr 09, 2020 at 05:38:18AM -0700, Paul Goyette wrote:
> > 2) fix the kernel modload support to reject any attempts of module loading
> > when the symbol table is empty
> This could be done, but would not solve the problem we ran into in
> this PR.
We still should do it, I'll look into it.
> The PR was triggered because the previous changes _always_ executed
> the sysctl_setup code. Prior to the change, it was executed only
> when the opencrypto init code was run. And, for built-in opencrypto,
> the init code only ran when a "client" attached.
> As a result, the sysctl nodes were created, with helper functions
> that referenced unallocated data structures.
Ok, I misunderstood that part.
> > 3) fix the opencrypto code to properly deal with module load failure (or
> > non-availability of modules) - maybe this is what Paul did and I
> > misunderstood
> I didn't fix it, I just avoided the bug by returning to the previous
> ``call sysctl_setup only when a "client" attaches'' mechanism.
> Note that the module load was _not_ triggered by opencrypto, but by
> something else in /etc/rc.d stuff.
Can you find out what? We need to fix it, GENERIC must work w/o any module
Main Index |
Thread Index |