Date: Wed, 9 Oct 2002 16:17:32 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.ORG> Cc: "Vladimir B. "@FreeBSD.ORG, <Grebenschikov@FreeBSD.ORG>, <" <vova@sw.ru>"@server.baldwin.cx>, <freebsd-current@FreeBSD.ORG>, Maxime Henrion <mux@FreeBSD.ORG> Subject: Re: DDB sysctl function Message-ID: <20021009160129.P4010-100000@gamplex.bde.org> In-Reply-To: <XFMail.20021008173357.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Oct 2002, John Baldwin wrote: > On 08-Oct-2002 Vladimir B. " Grebenschikov wrote: > > =F7 Tue, 08.10.2002, =D7 22:25, Maxime Henrion =CE=C1=D0=C9=D3=C1=CC: > >> - I'm not sure if using the context of the init process to do sysctl > >> calls is the right way to go. However, it is not very clear what yo= u > >> should use to do this, at least to me. > > > > kernel_sysctl need thread pointer, it may be used in sysctl handlers. > > Use curthread perhaps. In -current you always have a thread context, > even when idle. Not in ddb you don't. ddb may be invoked at any point, including in the middle of a thread switch. ddb also use any normal lock, since doing so may deadlock or worse. I don't see how ddb can safely use any of the general sysctl code, especially for writing. There are almost no locks for sysctl now, but that will change when Giant is pushed down and/or removed. Reading can work in the same way as db_ps() now, provided the code doesn't go near any locks: when a data struct is invalid, following garbage pointers cause traps if you are unlucky (endless loops if you are unlucky) and ddb's trap handler longjmp()s back to the main loop. Going near locks causes at least the following problems: - deadlock - not releasing locks in the trap handler before longjmp()'ing. The trap handler cannot reasonably know which locks to release if they were aquired by general code. - traps in the middle of aquiring and releasing locks may leave the locks in a half-initialized state, and the trap handler cannot even unreasonably klnow how to fix this. Similarly for any other global data structures that are modified by general code called from ddb. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021009160129.P4010-100000>