Re: GEOM panic in current kernel
* De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2002-09-28 ] [ Subjecte: Re: GEOM panic in current kernel ] > Juli Mallett wrote: > > * De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2002-09-28 ] > > > Poul-Henning Kamp wrote: > > > > + bzero(&mymutex, sizeof mymutex); > > > > mtx_init(&mymutex, "g_up", MTX_DEF, 0); > > > > > > > > > Too bad mtx_init() doesn't really initialize the mutex, or > > > this would not be necessary. 8-(. > > > > That would break some witness checks, Terry, which check for something very > > bad, which shouldn't happen: a mutex actually being initialised twice. > > The ones in this case are on the stack, which means that they > are not going to persist long enough for that to be a problem. > > For persistent mutexes, this implies that bzero()'ing is a bad > thing to do (from a witness perspective), but a good thing to > do otherwise. > > What this all implies to me is that there needs to be a mutex > allocation/deallocation mechanism for keeping witness happy, > by verifying that the mutex is no longer used at the point > that it is freed, so that it's OK to bzero() it on initial > allocation (to differentiate initial allocation from reuse). > > The point comes down to "where do little mutexes come from?". > > Actually, it seems to me that it should be OK to initialize a > mutex multiple times, and only not OK to initialize it if it's > in use. In other words, I don't think that the protection you > are talking about is protecting against what it;s pretending to. A mutex zone or pool, and actual allocation would be interesting. -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM panic in current kernel
Juli Mallett wrote: > * De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2002-09-28 ] > > Poul-Henning Kamp wrote: > > > + bzero(&mymutex, sizeof mymutex); > > > mtx_init(&mymutex, "g_up", MTX_DEF, 0); > > > > > > Too bad mtx_init() doesn't really initialize the mutex, or > > this would not be necessary. 8-(. > > That would break some witness checks, Terry, which check for something very > bad, which shouldn't happen: a mutex actually being initialised twice. The ones in this case are on the stack, which means that they are not going to persist long enough for that to be a problem. For persistent mutexes, this implies that bzero()'ing is a bad thing to do (from a witness perspective), but a good thing to do otherwise. What this all implies to me is that there needs to be a mutex allocation/deallocation mechanism for keeping witness happy, by verifying that the mutex is no longer used at the point that it is freed, so that it's OK to bzero() it on initial allocation (to differentiate initial allocation from reuse). The point comes down to "where do little mutexes come from?". Actually, it seems to me that it should be OK to initialize a mutex multiple times, and only not OK to initialize it if it's in use. In other words, I don't think that the protection you are talking about is protecting against what it;s pretending to. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM panic in current kernel
Poul-Henning Kamp wrote: > + bzero(&mymutex, sizeof mymutex); > mtx_init(&mymutex, "g_up", MTX_DEF, 0); Too bad mtx_init() doesn't really initialize the mutex, or this would not be necessary. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM panic in current kernel
* De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2002-09-28 ] [ Subjecte: Re: GEOM panic in current kernel ] > Poul-Henning Kamp wrote: > > + bzero(&mymutex, sizeof mymutex); > > mtx_init(&mymutex, "g_up", MTX_DEF, 0); > > > Too bad mtx_init() doesn't really initialize the mutex, or > this would not be necessary. 8-(. That would break some witness checks, Terry, which check for something very bad, which shouldn't happen: a mutex actually being initialised twice. -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM panic in current kernel
> >> Uhm, what was the actual panic message ? > >mutex g_up 0xe0499cb8 already initialized > > Can you try this patch ? Works great! Thanks! Marc msg43552/pgp0.pgp Description: PGP signature
Re: GEOM panic in current kernel
In message <[EMAIL PROTECTED]>, Marc Recht writes: >--=./s+MTW'WA?QFc= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit > >> >After the latest geom_* commits I get a panic while booting. The panic occurs >before mounting the disks, so I had to hand-write it down.. >> >panic.. >> >mtx_init(e0499ce8, e0396b85, 0, 0, 748f6273) at mtx_init + 0x5f >> >... g_up_procbody + 0x34 >> >... >Wow! That was a fast reply. :-) > >> Uhm, what was the actual panic message ? >mutex g_up 0xe0499cb8 already initialized > Can you try this patch ? Index: geom_kern.c === RCS file: /home/ncvs/src/sys/geom/geom_kern.c,v retrieving revision 1.7 diff -u -r1.7 geom_kern.c --- geom_kern.c 28 Sep 2002 11:57:20 - 1.7 +++ geom_kern.c 28 Sep 2002 18:37:01 - @@ -83,6 +83,7 @@ struct thread *tp = FIRST_THREAD_IN_PROC(p); struct mtx mymutex; + bzero(&mymutex, sizeof mymutex); mtx_init(&mymutex, "g_up", MTX_DEF, 0); mtx_lock(&mymutex); tp->td_base_pri = PRIBIO; @@ -107,6 +108,7 @@ struct thread *tp = FIRST_THREAD_IN_PROC(p); struct mtx mymutex; + bzero(&mymutex, sizeof mymutex); mtx_init(&mymutex, "g_down", MTX_DEF, 0); mtx_lock(&mymutex); tp->td_base_pri = PRIBIO; -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM panic in current kernel
> >After the latest geom_* commits I get a panic while booting. The panic occurs >before mounting the disks, so I had to hand-write it down.. > >panic.. > >mtx_init(e0499ce8, e0396b85, 0, 0, 748f6273) at mtx_init + 0x5f > >... g_up_procbody + 0x34 > >... Wow! That was a fast reply. :-) > Uhm, what was the actual panic message ? mutex g_up 0xe0499cb8 already initialized Marc msg43549/pgp0.pgp Description: PGP signature
Re: GEOM panic in current kernel
In message <[EMAIL PROTECTED]>, Marc Recht writes: >--=.8yCGZQ.c,FaLiI >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit > >Hi! > >After the latest geom_* commits I get a panic while booting. The panic occurs before >mounting the disks, so I had to hand-write it down.. >panic.. >mtx_init(e0499ce8, e0396b85, 0, 0, 748f6273) at mtx_init + 0x5f >... g_up_procbody + 0x34 >... Uhm, what was the actual panic message ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
GEOM panic in current kernel
Hi! After the latest geom_* commits I get a panic while booting. The panic occurs before mounting the disks, so I had to hand-write it down.. panic.. mtx_init(e0499ce8, e0396b85, 0, 0, 748f6273) at mtx_init + 0x5f ... g_up_procbody + 0x34 ... Please let me know if/how I could provide more info. Marc msg43545/pgp0.pgp Description: PGP signature
