From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 05:54:58 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 631F337B401 for ; Sun, 17 Aug 2003 05:54:58 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFC2543FB1 for ; Sun, 17 Aug 2003 05:54:57 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7HCsuuN005462; Sun, 17 Aug 2003 08:54:56 -0400 (EDT) Date: Sun, 17 Aug 2003 08:54:56 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030817004956.GA52247@dhcp42.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 12:54:58 -0000 On Sat, 16 Aug 2003, Marcel Moolenaar wrote: > On Sat, Aug 16, 2003 at 07:29:12PM -0400, Daniel Eischen wrote: > > On Sat, 16 Aug 2003, Marcel Moolenaar wrote: > > > > > On Sat, Aug 16, 2003 at 06:13:36AM -0400, Daniel Eischen wrote: > > > > > > There's at least a problem with the mutex_d test, so I suspect that > > > we still have some lingering issues. This does not look to be > > > related to thread pointers. I don't know to what extend it will affect > > > ACE. > > > > One question. When you call (the syscall) setcontext() from > > _ia64_break_setcontext(), do you ignore the signal mask (uc.uc_sigmask)? > > Good point. I don't think so. OK, this will cause signal handling problems. You can use another flag, but that would dirty up MI setcontext(). Perhaps a separate ia64-specific system call? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 09:12:56 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8C5D37B401; Sun, 17 Aug 2003 09:12:56 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2E6643F75; Sun, 17 Aug 2003 09:12:55 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp42.pn.xcllnt.net (dhcp42.pn.xcllnt.net [192.168.4.242]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HGCtwO097084; Sun, 17 Aug 2003 09:12:55 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp42.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HGCtR6000643; Sun, 17 Aug 2003 09:12:55 -0700 (PDT) (envelope-from marcel@dhcp42.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h7HGCtc9000642; Sun, 17 Aug 2003 09:12:55 -0700 (PDT) (envelope-from marcel) Date: Sun, 17 Aug 2003 09:12:55 -0700 From: Marcel Moolenaar To: deischen@freebsd.org Message-ID: <20030817161255.GA567@dhcp42.pn.xcllnt.net> References: <20030817004956.GA52247@dhcp42.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 16:12:57 -0000 On Sun, Aug 17, 2003 at 08:54:56AM -0400, Daniel Eischen wrote: > > > > > > One question. When you call (the syscall) setcontext() from > > > _ia64_break_setcontext(), do you ignore the signal mask (uc.uc_sigmask)? > > > > Good point. I don't think so. > > OK, this will cause signal handling problems. You can > use another flag, but that would dirty up MI setcontext(). > Perhaps a separate ia64-specific system call? I actually have been thinking about using a flag. One that simply indicates that the sigmask field is valid or not. The advantage of such flag is that it makes the general interaction with user land versions of getcontext() much more predictable and increases the overall applicability of the *context syscalls. For example: libthr uses getcontext(2) but is not interested in the sigmask. It simply uses the syscall as an initialization for new threads. The context is passed to thr_create where we only use the mcontext part to setup the registers. libkse tries to avoid the syscalls. The userland versions don't save or restore signal masks. There too we use contexts without actually being interested in sigmasks. Also in libkse we see that the contexts created in the kernel and given to userland are not contexts that contains sigmasks. We simply copyout the mcontext part of the ucontext. So, it appears that most of our uses of contexts are such that we don't need to save and/or restore sigmasks. I think an UCF_SIGMASK flag to indicate that the context has a valid sigmask is a logical or natural way to have setcontext(2) operate well with getcontext(2), which always defines contexts with sigmasks and userland versions of getcontext() or other more specific uses of contexts that may or may not have a need to save the sigmask. Reasoning differently: if we were to introduce a new syscall, then the syscall would in effect be a clone of setcontext(2) with the difference that we don't restore a part of the context. This is duplication to avoid variation. Also, with a new syscall we introduce the notion of having 2 seperate contexts. This not only begs for a getcontext() clone that does not save the sigmask, but also begs for a flag to differentiate between those 2 contexts. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 10:19:38 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E39B37B404 for ; Sun, 17 Aug 2003 10:19:38 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 517B343FBF for ; Sun, 17 Aug 2003 10:19:37 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7HHJauN013035; Sun, 17 Aug 2003 13:19:36 -0400 (EDT) Date: Sun, 17 Aug 2003 13:19:36 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030817161255.GA567@dhcp42.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 17:19:38 -0000 On Sun, 17 Aug 2003, Marcel Moolenaar wrote: > On Sun, Aug 17, 2003 at 08:54:56AM -0400, Daniel Eischen wrote: > > > > > > > > One question. When you call (the syscall) setcontext() from > > > > _ia64_break_setcontext(), do you ignore the signal mask (uc.uc_sigmask)? > > > > > > Good point. I don't think so. > > > > OK, this will cause signal handling problems. You can > > use another flag, but that would dirty up MI setcontext(). > > Perhaps a separate ia64-specific system call? > > I actually have been thinking about using a flag. One that simply > indicates that the sigmask field is valid or not. The advantage > of such flag is that it makes the general interaction with user > land versions of getcontext() much more predictable and increases > the overall applicability of the *context syscalls. > > For example: libthr uses getcontext(2) but is not interested in > the sigmask. It simply uses the syscall as an initialization for > new threads. The context is passed to thr_create where we only > use the mcontext part to setup the registers. libkse tries to > avoid the syscalls. The userland versions don't save or restore > signal masks. There too we use contexts without actually being > interested in sigmasks. Also in libkse we see that the contexts > created in the kernel and given to userland are not contexts that > contains sigmasks. We simply copyout the mcontext part of the > ucontext. So, it appears that most of our uses of contexts are > such that we don't need to save and/or restore sigmasks. > > I think an UCF_SIGMASK flag to indicate that the context has a > valid sigmask is a logical or natural way to have setcontext(2) > operate well with getcontext(2), which always defines contexts > with sigmasks and userland versions of getcontext() or other > more specific uses of contexts that may or may not have a need > to save the sigmask. > > Reasoning differently: if we were to introduce a new syscall, > then the syscall would in effect be a clone of setcontext(2) > with the difference that we don't restore a part of the context. > This is duplication to avoid variation. Also, with a new syscall > we introduce the notion of having 2 seperate contexts. This not > only begs for a getcontext() clone that does not save the sigmask, > but also begs for a flag to differentiate between those 2 contexts. OK. I mostly wanted to avoid #if defined(ia64) in kern_context.c thinking the flag would have been in mc_flags. Please get rid of UCF_SWAPPED while you're at it; it's no longer used. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 10:52:04 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B930337B401; Sun, 17 Aug 2003 10:52:04 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEDAB43FAF; Sun, 17 Aug 2003 10:52:03 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp42.pn.xcllnt.net (dhcp42.pn.xcllnt.net [192.168.4.242]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HHq3wO097493; Sun, 17 Aug 2003 10:52:03 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp42.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HHpsR6000949; Sun, 17 Aug 2003 10:51:54 -0700 (PDT) (envelope-from marcel@dhcp42.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h7HHpsW8000948; Sun, 17 Aug 2003 10:51:54 -0700 (PDT) (envelope-from marcel) Date: Sun, 17 Aug 2003 10:51:54 -0700 From: Marcel Moolenaar To: deischen@freebsd.org Message-ID: <20030817175154.GA928@dhcp42.pn.xcllnt.net> References: <20030817161255.GA567@dhcp42.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 17:52:05 -0000 On Sun, Aug 17, 2003 at 01:19:36PM -0400, Daniel Eischen wrote: > > OK. I mostly wanted to avoid #if defined(ia64) in kern_context.c > thinking the flag would have been in mc_flags. Ah, ok. No :-) > Please get rid of UCF_SWAPPED while you're at it; it's no longer > used. Will do. Is it save to define UCF_SIGMASK as 1 or shall I steer clear from that bit? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 11:50:17 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 233C637B401 for ; Sun, 17 Aug 2003 11:50:17 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28D2B43F3F for ; Sun, 17 Aug 2003 11:50:16 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp42.pn.xcllnt.net (dhcp42.pn.xcllnt.net [192.168.4.242]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HIoFwO097756 for ; Sun, 17 Aug 2003 11:50:15 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp42.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HIoFR6001242 for ; Sun, 17 Aug 2003 11:50:15 -0700 (PDT) (envelope-from marcel@dhcp42.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h7HIoFRB001241 for threads@FreeBSD.org; Sun, 17 Aug 2003 11:50:15 -0700 (PDT) (envelope-from marcel) Date: Sun, 17 Aug 2003 11:50:15 -0700 From: Marcel Moolenaar To: threads@FreeBSD.org Message-ID: <20030817185015.GB928@dhcp42.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 18:50:17 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Gang, Please review the attached patch and let me know to what extend it introduces breakages. It is the result of "aggressive engineering" to provoke comments and further fuel discussion. The reason for this approach is that we currently do not initialize any fields other than the mcontext and sigmask and only partially copyin() and copyout() the contexts (typically only the mcontext and sigmask fields). This generally is very sensitive to breakages, especially when we intro- duce flags or need to use any of the spare fields. getcontext(3): the whole ucontext is zeroed before (partially) filled and we copyout() all of it. This means that uc_link can only be set/defined after calling setcontext(). setcontext(3): we copyin() the whole ucontext but partially restore its fields. The sigmask is restored conditionally based upon the UCF_SIGMASK flag. swapcontext(3): we preserve uc_link by doing a partial copyin(). The context is otherwise zeroed and partially filled. we copyout() the whole context. The patch has only been compile-tested. Shoot... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="context.diff" Index: kern/kern_context.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_context.c,v retrieving revision 1.6 diff -u -r1.6 kern_context.c --- kern/kern_context.c 11 Jun 2003 00:56:55 -0000 1.6 +++ kern/kern_context.c 17 Aug 2003 18:34:51 -0000 @@ -38,13 +38,6 @@ #include #include -/* - * The first two fields of a ucontext_t are the signal mask and - * the machine context. The next field is uc_link; we want to - * avoid destroying the link when copying out contexts. - */ -#define UC_COPY_SIZE offsetof(ucontext_t, uc_link) - #ifndef _SYS_SYSPROTO_H_ struct getcontext_args { struct __ucontext *ucp; @@ -65,18 +58,17 @@ getcontext(struct thread *td, struct getcontext_args *uap) { ucontext_t uc; - int ret; if (uap->ucp == NULL) - ret = EINVAL; - else { - get_mcontext(td, &uc.uc_mcontext, 1); - PROC_LOCK(td->td_proc); - uc.uc_sigmask = td->td_sigmask; - PROC_UNLOCK(td->td_proc); - ret = copyout(&uc, uap->ucp, UC_COPY_SIZE); - } - return (ret); + return (EINVAL); + + bzero(&uc, sizeof(uc)); + get_mcontext(td, &uc.uc_mcontext, 1); + PROC_LOCK(td->td_proc); + uc.uc_sigmask = td->td_sigmask; + PROC_UNLOCK(td->td_proc); + uc.uc_flags |= UCF_SIGMASK; + return (copyout(&uc, uap->ucp, sizeof(uc))); } /* @@ -86,51 +78,59 @@ setcontext(struct thread *td, struct setcontext_args *uap) { ucontext_t uc; - int ret; + int error; if (uap->ucp == NULL) - ret = EINVAL; - else { - ret = copyin(uap->ucp, &uc, UC_COPY_SIZE); - if (ret == 0) { - ret = set_mcontext(td, &uc.uc_mcontext); - if (ret == 0) { - SIG_CANTMASK(uc.uc_sigmask); - PROC_LOCK(td->td_proc); - td->td_sigmask = uc.uc_sigmask; - PROC_UNLOCK(td->td_proc); - } - } + return (EINVAL); + + error = copyin(uap->ucp, &uc, sizeof(uc)); + if (error) + return (error); + error = set_mcontext(td, &uc.uc_mcontext); + if (error) + return (error); + if (uc.uc_flags & UCF_SIGMASK) { + SIG_CANTMASK(uc.uc_sigmask); + PROC_LOCK(td->td_proc); + td->td_sigmask = uc.uc_sigmask; + PROC_UNLOCK(td->td_proc); } - return (ret == 0 ? EJUSTRETURN : ret); + return (EJUSTRETURN); } int swapcontext(struct thread *td, struct swapcontext_args *uap) { ucontext_t uc; - int ret; + int error; if (uap->oucp == NULL || uap->ucp == NULL) - ret = EINVAL; - else { - get_mcontext(td, &uc.uc_mcontext, 1); + return (EINVAL); + + bzero(&uc, sizeof(uc)); + error = copyin(uap->oucp + offsetof(ucontext_t, uc_link), &uc.uc_link, + sizeof(uc.uc_link)); + if (error) + return (error); + get_mcontext(td, &uc.uc_mcontext, 1); + PROC_LOCK(td->td_proc); + uc.uc_sigmask = td->td_sigmask; + PROC_UNLOCK(td->td_proc); + uc.uc_flags |= UCF_SIGMASK; + error = copyout(&uc, uap->oucp, sizeof(uc)); + if (error) + return (error); + error = copyin(uap->ucp, &uc, sizeof(uc)); + if (error) + return (error); + error = set_mcontext(td, &uc.uc_mcontext); + if (error) + return (error); + if (uc.uc_flags & UCF_SIGMASK) { + SIG_CANTMASK(uc.uc_sigmask); PROC_LOCK(td->td_proc); - uc.uc_sigmask = td->td_sigmask; + td->td_sigmask = uc.uc_sigmask; PROC_UNLOCK(td->td_proc); - ret = copyout(&uc, uap->oucp, UC_COPY_SIZE); - if (ret == 0) { - ret = copyin(uap->ucp, &uc, UC_COPY_SIZE); - if (ret == 0) { - ret = set_mcontext(td, &uc.uc_mcontext); - if (ret == 0) { - SIG_CANTMASK(uc.uc_sigmask); - PROC_LOCK(td->td_proc); - td->td_sigmask = uc.uc_sigmask; - PROC_UNLOCK(td->td_proc); - } - } - } } - return (ret == 0 ? EJUSTRETURN : ret); + return (EJUSTRETURN); } Index: sys/ucontext.h =================================================================== RCS file: /home/ncvs/src/sys/sys/ucontext.h,v retrieving revision 1.10 diff -u -r1.10 ucontext.h --- sys/ucontext.h 25 Apr 2003 01:50:30 -0000 1.10 +++ sys/ucontext.h 17 Aug 2003 18:13:49 -0000 @@ -34,6 +34,18 @@ #include #include +/* + * A note about UCF_SIGMASK: Contexts are defined in ucontext(3) to include + * the signal mask (ie blocked signals). By default getcontext(3) creates + * contexts according to that definition and setcontext(3) will restore it. + * Our 1:1 and M:N threading libraries use the ucontext structure without + * taking the signal mask into account. They either not restore it, not + * define it or both. Since contexts in the M:N library are shared between + * the kernel and the threaded application, there's a need to mark contexts + * that do have a valid signal mask so that setcontext(3) knows when to + * restore it. + */ + typedef struct __ucontext { /* * Keep the order of the first two fields. Also, @@ -49,7 +61,7 @@ struct __ucontext *uc_link; stack_t uc_stack; int uc_flags; -#define UCF_SWAPPED 0x00000001 /* Used by swapcontext(3). */ +#define UCF_SIGMASK 0x00000001 /* Context has valid signal mask. */ int __spare__[4]; } ucontext_t; --sm4nu43k4a2Rpi4c-- From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 13:48:56 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A2CC37B401 for ; Sun, 17 Aug 2003 13:48:56 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89A6943FBF for ; Sun, 17 Aug 2003 13:48:55 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7HKmsuN011273; Sun, 17 Aug 2003 16:48:54 -0400 (EDT) Date: Sun, 17 Aug 2003 16:48:54 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030817175154.GA928@dhcp42.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 20:48:56 -0000 On Sun, 17 Aug 2003, Marcel Moolenaar wrote: > On Sun, Aug 17, 2003 at 01:19:36PM -0400, Daniel Eischen wrote: > > > > OK. I mostly wanted to avoid #if defined(ia64) in kern_context.c > > thinking the flag would have been in mc_flags. > > Ah, ok. No :-) > > > Please get rid of UCF_SWAPPED while you're at it; it's no longer > > used. > > Will do. Is it save to define UCF_SIGMASK as 1 or shall I steer > clear from that bit? 1 should be safe to use. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 14:12:31 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0036537B404 for ; Sun, 17 Aug 2003 14:12:30 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47EB943F85 for ; Sun, 17 Aug 2003 14:12:30 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7HLCTuN014611; Sun, 17 Aug 2003 17:12:29 -0400 (EDT) Date: Sun, 17 Aug 2003 17:12:29 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030817185015.GB928@dhcp42.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 21:12:31 -0000 On Sun, 17 Aug 2003, Marcel Moolenaar wrote: > Gang, > > Please review the attached patch and let me know to what extend it > introduces breakages. It is the result of "aggressive engineering" > to provoke comments and further fuel discussion. The reason for this > approach is that we currently do not initialize any fields other than > the mcontext and sigmask and only partially copyin() and copyout() > the contexts (typically only the mcontext and sigmask fields). This > generally is very sensitive to breakages, especially when we intro- > duce flags or need to use any of the spare fields. > > getcontext(3): the whole ucontext is zeroed before (partially) filled > and we copyout() all of it. This means that uc_link can only > be set/defined after calling setcontext(). This prevents reuse of the same context without resetting uc_link after every usage. I don't see any requirement by POSIX that uc_link be left intact after getcontext(), but it might be worth preserving... It's up to you. Other than that, the patch looks good. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 15:06:26 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C87237B408 for ; Sun, 17 Aug 2003 15:06:26 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FE4643F3F for ; Sun, 17 Aug 2003 15:06:24 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp42.pn.xcllnt.net (dhcp42.pn.xcllnt.net [192.168.4.242]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HM6OwO098742; Sun, 17 Aug 2003 15:06:24 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp42.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HM6OR6001818; Sun, 17 Aug 2003 15:06:24 -0700 (PDT) (envelope-from marcel@dhcp42.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h7HM6O0n001817; Sun, 17 Aug 2003 15:06:24 -0700 (PDT) (envelope-from marcel) Date: Sun, 17 Aug 2003 15:06:23 -0700 From: Marcel Moolenaar To: Daniel Eischen Message-ID: <20030817220623.GA1661@dhcp42.pn.xcllnt.net> References: <20030817185015.GB928@dhcp42.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 22:06:26 -0000 On Sun, Aug 17, 2003 at 05:12:29PM -0400, Daniel Eischen wrote: > On Sun, 17 Aug 2003, Marcel Moolenaar wrote: > > > Please review the attached patch and let me know to what extend it > > introduces breakages. It is the result of "aggressive engineering" > > to provoke comments and further fuel discussion. The reason for this > > approach is that we currently do not initialize any fields other than > > the mcontext and sigmask and only partially copyin() and copyout() > > the contexts (typically only the mcontext and sigmask fields). This > > generally is very sensitive to breakages, especially when we intro- > > duce flags or need to use any of the spare fields. > > > > getcontext(3): the whole ucontext is zeroed before (partially) filled > > and we copyout() all of it. This means that uc_link can only > > be set/defined after calling setcontext(). > > This prevents reuse of the same context without resetting > uc_link after every usage. I don't see any requirement > by POSIX that uc_link be left intact after getcontext(), > but it might be worth preserving... It's up to you. Yes, it's a tricky issue. I'll begin runtime testing and think about it some more. I don't want to rush it... BTW: I think we need to preserve uc_stack as well. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 15:44:52 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87FBF37B401; Sun, 17 Aug 2003 15:44:52 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 277D543F3F; Sun, 17 Aug 2003 15:44:52 -0700 (PDT) (envelope-from davidxu@FreeBSD.org) Received: from localhost (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7HMioUp016844; Sun, 17 Aug 2003 15:44:51 -0700 (PDT) (envelope-from davidxu@FreeBSD.org) From: David Xu To: Marcel Moolenaar , threads@FreeBSD.org Date: Mon, 18 Aug 2003 06:47:52 +0800 User-Agent: KMail/1.5.2 References: <20030817185015.GB928@dhcp42.pn.xcllnt.net> In-Reply-To: <20030817185015.GB928@dhcp42.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308180647.52744.davidxu@FreeBSD.org> Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: davidxu@FreeBSD.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 22:44:52 -0000 On Monday 18 August 2003 02:50, Marcel Moolenaar wrote: > Gang, > > Please review the attached patch and let me know to what extend it > introduces breakages. It is the result of "aggressive engineering" > to provoke comments and further fuel discussion. The reason for this > approach is that we currently do not initialize any fields other than > the mcontext and sigmask and only partially copyin() and copyout() > the contexts (typically only the mcontext and sigmask fields). This > generally is very sensitive to breakages, especially when we intro- > duce flags or need to use any of the spare fields. > > getcontext(3): the whole ucontext is zeroed before (partially) filled > and we copyout() all of it. This means that uc_link can only > be set/defined after calling setcontext(). > setcontext(3): we copyin() the whole ucontext but partially restore > its fields. The sigmask is restored conditionally based upon > the UCF_SIGMASK flag. > swapcontext(3): we preserve uc_link by doing a partial copyin(). The > context is otherwise zeroed and partially filled. we copyout() > the whole context. > > The patch has only been compile-tested. > > Shoot... Then doesn't signal context in signal handler have a UCF_SIGMASK ? void (*__sa_sigaction)(int, struct __siginfo *, ucontext_t *ucp); the context *ucp should have UCF_SIGMASK now. I think it should be UCF_NOSIGMASK. But for libkse, we really needn't this kind of hack, because M:N thread in kernel always masks all signals, you can always SIGFILLSET(&uc.uc_sigmask) before call set_context. -- David Xu From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 16:12:48 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 373F437B401; Sun, 17 Aug 2003 16:12:48 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3CF443F3F; Sun, 17 Aug 2003 16:12:46 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp42.pn.xcllnt.net (dhcp42.pn.xcllnt.net [192.168.4.242]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HNCkwO099046; Sun, 17 Aug 2003 16:12:46 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp42.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7HNCkR6019455; Sun, 17 Aug 2003 16:12:46 -0700 (PDT) (envelope-from marcel@dhcp42.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h7HNCkIx019454; Sun, 17 Aug 2003 16:12:46 -0700 (PDT) (envelope-from marcel) Date: Sun, 17 Aug 2003 16:12:46 -0700 From: Marcel Moolenaar To: David Xu Message-ID: <20030817231246.GA17207@dhcp42.pn.xcllnt.net> References: <20030817185015.GB928@dhcp42.pn.xcllnt.net> <200308180647.52744.davidxu@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200308180647.52744.davidxu@FreeBSD.org> User-Agent: Mutt/1.5.4i cc: threads@FreeBSD.org Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 23:12:48 -0000 On Mon, Aug 18, 2003 at 06:47:52AM +0800, David Xu wrote: > > Then doesn't signal context in signal handler have a UCF_SIGMASK ? Yes. > void (*__sa_sigaction)(int, struct __siginfo *, ucontext_t *ucp); > the context *ucp should have UCF_SIGMASK now. We never define uc_flags currently. We only copyout() uc_sigmask and uc_mcontext. Hence, the uc_flags field is garbage. As is the uc_stack field. > I think it should be UCF_NOSIGMASK. But for libkse, we really needn't > this kind of hack, because M:N thread in kernel always masks all signals, > you can always SIGFILLSET(&uc.uc_sigmask) before call set_context. I tried this, but it didn't fix mutex_d. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 16:31:21 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 161E037B401; Sun, 17 Aug 2003 16:31:21 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A699743F3F; Sun, 17 Aug 2003 16:31:20 -0700 (PDT) (envelope-from davidxu@FreeBSD.org) Received: from localhost (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7HNVIUp022617; Sun, 17 Aug 2003 16:31:19 -0700 (PDT) (envelope-from davidxu@FreeBSD.org) From: David Xu To: Marcel Moolenaar Date: Mon, 18 Aug 2003 07:34:21 +0800 User-Agent: KMail/1.5.2 References: <20030817185015.GB928@dhcp42.pn.xcllnt.net> <200308180647.52744.davidxu@FreeBSD.org> <20030817231246.GA17207@dhcp42.pn.xcllnt.net> In-Reply-To: <20030817231246.GA17207@dhcp42.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308180734.21128.davidxu@FreeBSD.org> cc: threads@FreeBSD.org Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: davidxu@FreeBSD.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 23:31:21 -0000 On Monday 18 August 2003 07:12, Marcel Moolenaar wrote: > On Mon, Aug 18, 2003 at 06:47:52AM +0800, David Xu wrote: > > Then doesn't signal context in signal handler have a UCF_SIGMASK ? > > Yes. > > > void (*__sa_sigaction)(int, struct __siginfo *, ucontext_t *ucp); > > the context *ucp should have UCF_SIGMASK now. > > We never define uc_flags currently. We only copyout() uc_sigmask and > uc_mcontext. Hence, the uc_flags field is garbage. As is the uc_stack > field. > > > I think it should be UCF_NOSIGMASK. But for libkse, we really needn't > > this kind of hack, because M:N thread in kernel always masks all signals, > > you can always SIGFILLSET(&uc.uc_sigmask) before call set_context. > > I tried this, but it didn't fix mutex_d. I can pass mutex_d if gettimeofday does not return -1, but it is strange that gettimeofday can return -1 and errno is EFAULT. so line 414 of mutex_d.c is asserted: assert (gettimeofday (&tv2, NULL) == 0); David Xu From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 17:35:47 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6C1F37B401; Sun, 17 Aug 2003 17:35:47 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E10143FB1; Sun, 17 Aug 2003 17:35:47 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp42.pn.xcllnt.net (dhcp42.pn.xcllnt.net [192.168.4.242]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7I0ZkwO099402; Sun, 17 Aug 2003 17:35:46 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp42.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7I0ZkR6048433; Sun, 17 Aug 2003 17:35:46 -0700 (PDT) (envelope-from marcel@dhcp42.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h7I0Zkth048432; Sun, 17 Aug 2003 17:35:46 -0700 (PDT) (envelope-from marcel) Date: Sun, 17 Aug 2003 17:35:46 -0700 From: Marcel Moolenaar To: David Xu Message-ID: <20030818003546.GA44401@dhcp42.pn.xcllnt.net> References: <20030817185015.GB928@dhcp42.pn.xcllnt.net> <200308180647.52744.davidxu@FreeBSD.org> <20030817231246.GA17207@dhcp42.pn.xcllnt.net> <200308180734.21128.davidxu@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200308180734.21128.davidxu@FreeBSD.org> User-Agent: Mutt/1.5.4i cc: threads@FreeBSD.org Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 00:35:48 -0000 On Mon, Aug 18, 2003 at 07:34:21AM +0800, David Xu wrote: > > > > > I think it should be UCF_NOSIGMASK. But for libkse, we really needn't > > > this kind of hack, because M:N thread in kernel always masks all signals, > > > you can always SIGFILLSET(&uc.uc_sigmask) before call set_context. > > > > I tried this, but it didn't fix mutex_d. > > I can pass mutex_d if gettimeofday does not return -1, but it is strange > that gettimeofday can return -1 and errno is EFAULT. The copyout() is probably failing or we're not restoring the return registers properly. > so line 414 of mutex_d.c is asserted: > assert (gettimeofday (&tv2, NULL) == 0); Yup. That's what I'm seeing too. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 20:04:32 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADDEC37B401 for ; Sun, 17 Aug 2003 20:04:32 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D227143F75 for ; Sun, 17 Aug 2003 20:04:31 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7I34UuN000116; Sun, 17 Aug 2003 23:04:31 -0400 (EDT) Date: Sun, 17 Aug 2003 23:04:30 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030817220623.GA1661@dhcp42.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 03:04:33 -0000 On Sun, 17 Aug 2003, Marcel Moolenaar wrote: > On Sun, Aug 17, 2003 at 05:12:29PM -0400, Daniel Eischen wrote: > > On Sun, 17 Aug 2003, Marcel Moolenaar wrote: > > > > > Please review the attached patch and let me know to what extend it > > > introduces breakages. It is the result of "aggressive engineering" > > > to provoke comments and further fuel discussion. The reason for this > > > approach is that we currently do not initialize any fields other than > > > the mcontext and sigmask and only partially copyin() and copyout() > > > the contexts (typically only the mcontext and sigmask fields). This > > > generally is very sensitive to breakages, especially when we intro- > > > duce flags or need to use any of the spare fields. > > > > > > getcontext(3): the whole ucontext is zeroed before (partially) filled > > > and we copyout() all of it. This means that uc_link can only > > > be set/defined after calling setcontext(). > > > > This prevents reuse of the same context without resetting > > uc_link after every usage. I don't see any requirement > > by POSIX that uc_link be left intact after getcontext(), > > but it might be worth preserving... It's up to you. > > Yes, it's a tricky issue. I'll begin runtime testing and think about > it some more. I don't want to rush it... > > BTW: I think we need to preserve uc_stack as well. Yes, I think that's a good idea. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 20:12:35 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DD9E37B401; Sun, 17 Aug 2003 20:12:35 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7A7B43F75; Sun, 17 Aug 2003 20:12:34 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7I3CYuN001342; Sun, 17 Aug 2003 23:12:34 -0400 (EDT) Date: Sun, 17 Aug 2003 23:12:34 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <200308180647.52744.davidxu@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Marcel Moolenaar Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 03:12:35 -0000 yOn Mon, 18 Aug 2003, David Xu wrote: > On Monday 18 August 2003 02:50, Marcel Moolenaar wrote: > > Gang, > > > > Please review the attached patch and let me know to what extend it > > introduces breakages. It is the result of "aggressive engineering" > > to provoke comments and further fuel discussion. The reason for this > > approach is that we currently do not initialize any fields other than > > the mcontext and sigmask and only partially copyin() and copyout() > > the contexts (typically only the mcontext and sigmask fields). This > > generally is very sensitive to breakages, especially when we intro- > > duce flags or need to use any of the spare fields. > > > > getcontext(3): the whole ucontext is zeroed before (partially) filled > > and we copyout() all of it. This means that uc_link can only > > be set/defined after calling setcontext(). > > setcontext(3): we copyin() the whole ucontext but partially restore > > its fields. The sigmask is restored conditionally based upon > > the UCF_SIGMASK flag. > > swapcontext(3): we preserve uc_link by doing a partial copyin(). The > > context is otherwise zeroed and partially filled. we copyout() > > the whole context. > > > > The patch has only been compile-tested. > > > > Shoot... > > Then doesn't signal context in signal handler have a UCF_SIGMASK ? > > void (*__sa_sigaction)(int, struct __siginfo *, ucontext_t *ucp); > the context *ucp should have UCF_SIGMASK now. > I think it should be UCF_NOSIGMASK. But for libkse, we really needn't I think so too. > this kind of hack, because M:N thread in kernel always masks all signals, > you can always SIGFILLSET(&uc.uc_sigmask) before call set_context. That works for M:N, but not when THR_GETCONTEXT() (and perhaps someday THR_SETCONTEXT()) is used for a scope system thread. Hmm, this wouldn't seem to result in a context that needs to be restored by the syscall though. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 20:16:23 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C282C37B401; Sun, 17 Aug 2003 20:16:23 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EFA243FA3; Sun, 17 Aug 2003 20:16:23 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7I3GMuN001821; Sun, 17 Aug 2003 23:16:22 -0400 (EDT) Date: Sun, 17 Aug 2003 23:16:22 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030817231246.GA17207@dhcp42.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: David Xu Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 03:16:24 -0000 On Sun, 17 Aug 2003, Marcel Moolenaar wrote: > On Mon, Aug 18, 2003 at 06:47:52AM +0800, David Xu wrote: > > > > Then doesn't signal context in signal handler have a UCF_SIGMASK ? > > Yes. > > > void (*__sa_sigaction)(int, struct __siginfo *, ucontext_t *ucp); > > the context *ucp should have UCF_SIGMASK now. > > We never define uc_flags currently. We only copyout() uc_sigmask and > uc_mcontext. Hence, the uc_flags field is garbage. As is the uc_stack > field. > > > I think it should be UCF_NOSIGMASK. But for libkse, we really needn't > > this kind of hack, because M:N thread in kernel always masks all signals, > > you can always SIGFILLSET(&uc.uc_sigmask) before call set_context. > > I tried this, but it didn't fix mutex_d. I don't think the signal mask problem is the cause of mutex_d failing, but I did notice it when trying to kill the test. The mutex_d problem seems to be that either _ia64_restore_context() or _ia64_break_setcontext() are not working. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 20:18:53 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 379A937B401; Sun, 17 Aug 2003 20:18:53 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7701443FAF; Sun, 17 Aug 2003 20:18:52 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7I3IpuN002098; Sun, 17 Aug 2003 23:18:51 -0400 (EDT) Date: Sun, 17 Aug 2003 23:18:51 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030818003546.GA44401@dhcp42.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: David Xu Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 03:18:53 -0000 On Sun, 17 Aug 2003, Marcel Moolenaar wrote: > On Mon, Aug 18, 2003 at 07:34:21AM +0800, David Xu wrote: > > > > > > > I think it should be UCF_NOSIGMASK. But for libkse, we really needn't > > > > this kind of hack, because M:N thread in kernel always masks all signals, > > > > you can always SIGFILLSET(&uc.uc_sigmask) before call set_context. > > > > > > I tried this, but it didn't fix mutex_d. > > > > I can pass mutex_d if gettimeofday does not return -1, but it is strange > > that gettimeofday can return -1 and errno is EFAULT. > > The copyout() is probably failing or we're not restoring the > return registers properly. > > > so line 414 of mutex_d.c is asserted: > > assert (gettimeofday (&tv2, NULL) == 0); > > Yup. That's what I'm seeing too. Hmm, that's not what I see. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 20:30:23 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9362D37B401; Sun, 17 Aug 2003 20:30:23 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD86843F75; Sun, 17 Aug 2003 20:30:22 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7I3UMuN003405; Sun, 17 Aug 2003 23:30:22 -0400 (EDT) Date: Sun, 17 Aug 2003 23:30:22 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: David Xu Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 03:30:23 -0000 On Sun, 17 Aug 2003, Daniel Eischen wrote: > On Sun, 17 Aug 2003, Marcel Moolenaar wrote: > > > On Mon, Aug 18, 2003 at 07:34:21AM +0800, David Xu wrote: > > > > > > > > > I think it should be UCF_NOSIGMASK. But for libkse, we really needn't > > > > > this kind of hack, because M:N thread in kernel always masks all signals, > > > > > you can always SIGFILLSET(&uc.uc_sigmask) before call set_context. > > > > > > > > I tried this, but it didn't fix mutex_d. > > > > > > I can pass mutex_d if gettimeofday does not return -1, but it is strange > > > that gettimeofday can return -1 and errno is EFAULT. > > > > The copyout() is probably failing or we're not restoring the > > return registers properly. > > > > > so line 414 of mutex_d.c is asserted: > > > assert (gettimeofday (&tv2, NULL) == 0); > > > > Yup. That's what I'm seeing too. > > Hmm, that's not what I see. Actually, I do see that also now. I also see: Assertion failed: (pthread_mutex_destroy (&m[i]) == 0), function mutex_prioinherit_test, file mutex_d.c, line 1425. and Fatal error 'Thread has returned from _thread_switch' at line 1150 in file /freefall/d/home/deischen/current/src/lib/libpthread/thread/thr_kern.c (errno = 0) I also think I killed pluto1 again (just by running mutex_d). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 20:31:16 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9090937B401; Sun, 17 Aug 2003 20:31:16 -0700 (PDT) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DAC043F3F; Sun, 17 Aug 2003 20:31:07 -0700 (PDT) (envelope-from davidxu@viatech.com.cn) Received: from davidwnt (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Q9ZTY8ZL; Mon, 18 Aug 2003 11:13:18 +0800 Message-ID: <001a01c36539$b1a6dd70$f001a8c0@davidwnt> From: "David Xu" To: , "David Xu" References: Date: Mon, 18 Aug 2003 11:34:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 cc: threads@freebsd.org cc: Marcel Moolenaar Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 03:31:16 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhbmllbCBFaXNjaGVuIiA8 ZWlzY2hlbkB2aWdyaWQuY29tPg0KVG86ICJEYXZpZCBYdSIgPGRhdmlkeHVAZnJlZWJzZC5vcmc+ DQpDYzogPHRocmVhZHNAZnJlZWJzZC5vcmc+OyAiTWFyY2VsIE1vb2xlbmFhciIgPG1hcmNlbEB4 Y2xsbnQubmV0Pg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTgsIDIwMDMgMTE6MTIgQU0NClN1Ympl Y3Q6IFJlOiBGaXJzdCBkcmFmdDogcmV3cml0ZSBvZiB7Z2V0fHNldHxzd2FwfWNvbnRleHQoMykN Cj4gPiANCj4gPiBUaGVuIGRvZXNuJ3Qgc2lnbmFsIGNvbnRleHQgaW4gc2lnbmFsIGhhbmRsZXIg aGF2ZSBhIFVDRl9TSUdNQVNLID8NCj4gPiANCj4gPiB2b2lkICAgICgqX19zYV9zaWdhY3Rpb24p KGludCwgc3RydWN0IF9fc2lnaW5mbyAqLCB1Y29udGV4dF90ICp1Y3ApOw0KPiA+IHRoZSBjb250 ZXh0ICp1Y3Agc2hvdWxkIGhhdmUgVUNGX1NJR01BU0sgbm93Lg0KPiA+IEkgdGhpbmsgaXQgc2hv dWxkIGJlIFVDRl9OT1NJR01BU0suIEJ1dCBmb3IgbGlia3NlLCB3ZSByZWFsbHkgbmVlZG4ndA0K PiANCj4gSSB0aGluayBzbyB0b28uDQo+IA0KPiA+IHRoaXMga2luZCBvZiBoYWNrLCBiZWNhdXNl IE06TiB0aHJlYWQgaW4ga2VybmVsIGFsd2F5cyBtYXNrcyBhbGwgc2lnbmFscywNCj4gPiB5b3Ug Y2FuIGFsd2F5cyBTSUdGSUxMU0VUKCZ1Yy51Y19zaWdtYXNrKSBiZWZvcmUgY2FsbCBzZXRfY29u dGV4dC4NCj4gDQo+IFRoYXQgd29ya3MgZm9yIE06TiwgYnV0IG5vdCB3aGVuIFRIUl9HRVRDT05U RVhUKCkgKGFuZCBwZXJoYXBzDQo+IHNvbWVkYXkgVEhSX1NFVENPTlRFWFQoKSkgaXMgdXNlZCBm b3IgYSBzY29wZSBzeXN0ZW0gdGhyZWFkLg0KPiBIbW0sIHRoaXMgd291bGRuJ3Qgc2VlbSB0byBy ZXN1bHQgaW4gYSBjb250ZXh0IHRoYXQgbmVlZHMgdG8NCj4gYmUgcmVzdG9yZWQgYnkgdGhlIHN5 c2NhbGwgdGhvdWdoLg0KPiANCg0KSSBqdXN0IHRoaW5rIFVDRl9TSUdNQVNLIGlzIG5vdCBhc2tl ZCBieSBQT1NJWCwgIGFsc28gd2UgY2FuIGFsd2F5cw0Kc2V0IGEgcmlnaHQgc2lnbmFsIG1hc2sg Zm9yIHNjb3BlIHN5c3RlbSB0aHJlYWQsICBJIGFtIG5vdCBvYmplY3RpbmcgdGhlIGZsYWcsDQpi dXQgaXQgaXMgbm90IGEgbXVzdC1oYXZlIHRoaW5nIGZvciBjdXJyZW50IGxpYmtzZS4NCg0KPiAt LSANCj4gRGFuIEVpc2NoZW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IGZyZWVic2QtdGhyZWFkc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxp c3QNCj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC10 aHJlYWRzDQo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLXRocmVh ZHMtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmci From owner-freebsd-threads@FreeBSD.ORG Sun Aug 17 21:14:40 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 857AA37B401; Sun, 17 Aug 2003 21:14:40 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F41143FB1; Sun, 17 Aug 2003 21:14:39 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7I4EdwO000652; Sun, 17 Aug 2003 21:14:39 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7I4EcLx002018; Sun, 17 Aug 2003 21:14:38 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h7I4EcZB002017; Sun, 17 Aug 2003 21:14:38 -0700 (PDT) (envelope-from marcel) Date: Sun, 17 Aug 2003 21:14:38 -0700 From: Marcel Moolenaar To: deischen@freebsd.org Message-ID: <20030818041438.GA1974@athlon.pn.xcllnt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org cc: David Xu Subject: Re: First draft: rewrite of {get|set|swap}context(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 04:14:40 -0000 On Sun, Aug 17, 2003 at 11:30:22PM -0400, Daniel Eischen wrote: > On Sun, 17 Aug 2003, Daniel Eischen wrote: > > > I also think I killed pluto1 again (just by running mutex_d). Possible... fatal kernel trap (cpu 0): trap vector = 0x18 (General Exception) cr.iip = 0xe0000000009d3330 cr.ipsr = 0x1210080a2018 (ac,mfl,ic,dt,dfh,rt,cpl=0,it,ri=1,bn) cr.isr = 0x20000000030 (code=48,vector=0,ei=1) cr.ifa = 0xe00000002f9f4800 curthread = 0xe000000024f5d980 pid = 28312, comm = gmake Stopped at ia32_restorectx+0x61: mov.m ar.fsr=r14 db> trace ia32_restorectx() at ia32_restorectx+0x60 cpu_switch(0xe00000003e2f56b8, 0xe000000024f5d980, 0xa00000002317b780, 0xa00000001e3d5fb8) at cpu_switch+0xa0 mi_switch(0xe00000003e2f5540, 0x0, 0xe00000000074cbe0, 0x814) at mi_switch+0x420 msleep(0xe000000000b5aa90, 0x0, 0x4c, 0xe000000000a188b8, 0xa) at msleep+0x8d0 g_event_procbody(0xe000000000b259a8, 0xe000000000b7b0bc, 0xe000000000b5aa90, 0xe000000000715050) at g_event_procbody+0x120 fork_exit(0xe000000000a63780, 0x0, 0xa00000001e3d5550) at fork_exit+0x180 enter_userland() at enter_userland db> -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Mon Aug 18 11:02:13 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2604337B401 for ; Mon, 18 Aug 2003 11:02:13 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9703043F85 for ; Mon, 18 Aug 2003 11:02:12 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7II2CUp068845 for ; Mon, 18 Aug 2003 11:02:12 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7II2Cbj068840 for freebsd-threads@freebsd.org; Mon, 18 Aug 2003 11:02:12 -0700 (PDT) Date: Mon, 18 Aug 2003 11:02:12 -0700 (PDT) Message-Id: <200308181802.h7II2Cbj068840@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 18:02:13 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2002/01/16] kern/33951 threads pthread_cancel is ignored 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/01/19] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/04/02] bin/26307 threads libc_r aborts when using the KDE media pl o [2001/10/31] bin/31661 threads pthread_kill signal handler doesn't get s o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/03/07] bin/35622 threads sigaltstack is missing in libc_r o [2002/06/27] bin/39922 threads [PATCH?] Threaded applications executed w o [2003/03/02] bin/48856 threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] bin/49087 threads Signals lost in programs linked with libc a [2003/04/08] bin/50733 threads buildworld won't build, because of linkin o [2003/05/07] bin/51949 threads thread in accept cannot be cancelled o [2002/02/01] i386/34536 threads accept() blocks other threads o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/10/10] kern/43887 threads abnormal CPU useage when use pthread_mute o [2003/05/30] kern/52817 threads top(1) shows garbage for threaded process o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag 19 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/09/09] bin/30464 threads pthread mutex attributes -- pshared o [2002/05/02] bin/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwri o [2000/05/25] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Aug 19 14:24:36 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9EDA16A4BF for ; Tue, 19 Aug 2003 14:24:36 -0700 (PDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C67B43F93 for ; Tue, 19 Aug 2003 14:24:36 -0700 (PDT) (envelope-from krishna@cs.ucsb.edu) Received: from ella (ella [128.111.43.201]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.6) with ESMTP id h7JLOXS28300 for ; Tue, 19 Aug 2003 14:24:35 -0700 (PDT) Date: Tue, 19 Aug 2003 14:24:33 -0700 (PDT) From: "Krishna N. Ramachandran" X-Sender: krishna@ella To: freebsd-threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: lthr details X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 21:24:37 -0000 Hi, I tried searching for details about the lthr implementation on FreeBSD 5.x, but haven't found a lot of information online. I understand that its 1:1 based and relies on some common KSE code. It would be really great if someone could point me to some resource I can look up for more information. Thank you, Krishna From owner-freebsd-threads@FreeBSD.ORG Wed Aug 20 06:17:51 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30F7716A4BF; Wed, 20 Aug 2003 06:17:51 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5438943F85; Wed, 20 Aug 2003 06:17:50 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7KDHluN006964; Wed, 20 Aug 2003 09:17:49 -0400 (EDT) Date: Wed, 20 Aug 2003 09:17:47 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sheldon Hearn In-Reply-To: <20030820065729.GL736@starjuice.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: freebsd-java@freebsd.org Subject: Re: vmark hangs with libthr and libkse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 13:17:51 -0000 On Wed, 20 Aug 2003, Sheldon Hearn wrote: > On (2003/08/19 23:51), Alex Boisvert wrote: > > > I'd like to report that the VolanoMark Benchmark hangs with both libthr > > and libkse when run under 5-CURRENT (as of yesterday) and the latest JDK > > 1.4.1 patchset (experimental). > > That's nothing. JBoss panics my system when I use libkse, and "locks it > up" when I use libthr. :-) Any messages on the console or break-to-debugger info? Are you using SCHED_4BSD or SCHED_ULE? > > I just do what my old man told me when I complained that banging my head > against the wall hurt... "Don't do that, then". :-) No, please do that and give us some more info. We claim there are no bugs in libkse, so it's up to you to prove us wrong :-) -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Aug 20 07:11:33 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 528A416A4BF; Wed, 20 Aug 2003 07:11:33 -0700 (PDT) Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B497743FA3; Wed, 20 Aug 2003 07:11:31 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 4.21) id 19pTgO-0000el-P2; Wed, 20 Aug 2003 16:11:28 +0200 Date: Wed, 20 Aug 2003 16:11:28 +0200 From: Sheldon Hearn To: deischen@freebsd.org Message-ID: <20030820141128.GG736@starjuice.net> Mail-Followup-To: deischen@freebsd.org, freebsd-java@freebsd.org, threads@freebsd.org References: <20030820065729.GL736@starjuice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: Sheldon Hearn cc: threads@freebsd.org cc: freebsd-java@freebsd.org Subject: Re: vmark hangs with libthr and libkse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 14:11:33 -0000 On (2003/08/20 09:17), Daniel Eischen wrote: > Any messages on the console or break-to-debugger info? Are you using > SCHED_4BSD or SCHED_ULE? I think it was SCHED_4BSD. I scribbled the panic down on a piece of paper, but can't find it now. *sigh* > > I just do what my old man told me when I complained that banging my head > > against the wall hurt... "Don't do that, then". :-) > > No, please do that and give us some more info. We claim there > are no bugs in libkse, so it's up to you to prove us wrong :-) Okay, let me finish my work, sync my disks and give it another whirl this afternoon. :-) Ciao, Sheldon. From owner-freebsd-threads@FreeBSD.ORG Wed Aug 20 09:24:26 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5847B16A4C0 for ; Wed, 20 Aug 2003 09:24:26 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id E196443FEA for ; Wed, 20 Aug 2003 09:24:23 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 20126 invoked by uid 1000); 20 Aug 2003 16:24:24 -0000 Date: Wed, 20 Aug 2003 09:24:24 -0700 (PDT) From: Nate Lawson To: freebsd-threads@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20030820092347.G20029@root.org> MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=Message-Boundary-2321 Content-ID: <20030820092347.W20029@root.org> Subject: (Fwd) Lost data on FreeBSD tape (fwd) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 16:24:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --Message-Boundary-2321 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20030820092347.I20029@root.org> Content-Description: Mail message body This appears to be a pthreads problem, not scsi. Anyone care to look at it? ---------- Forwarded message ---------- Date: Wed, 20 Aug 2003 11:24:42 -0400 From: Dan Langille To: freebsd-scsi@freebsd.org Cc: Kern Sibbald Subject: (Fwd) Lost data on FreeBSD tape I've been working with Kern Sibbald, author of Bacula (http://www.bacula.org/) to iron out a few nits on the FreeBSD port of the software. Below you'll find his latest attempts to isolate the problem. Attached is a small test program and how to produce the problem. Could someone else please try to reproduce the error? Thanks ------- Forwarded message follows ------- Subject: Lost data on FreeBSD tape From: Kern Sibbald To: Dan Langille Organization: Date sent: 20 Aug 2003 11:01:23 +0200 Hello Dan, I've finally found how to create the problem and how to eliminate it. I think you or some FreeBSD guy will have to look at the source code. My testing confirms what I previously wrote that Bacula fails as well as btape doing either Bacula style writes or raw write() calls. There is only one strange twist to this: the demo program that I sent you works. If you recompile the demo program and add -pthread to both the compile and the link, data is lost -- and once you remove the -pthread on the compile and link, the program works again. The interesting thing is that when the program works, it gets a 0 status on a write, which indicates that the tape is at the end of the Logical EOF marker (or in other words, the tape is almost full): Write failed. Last block written=17294. stat=0 ERR=Unknown error: 0 When the program is compiled/linked with the -pthread option, it does not receive the 0 status from a write(), but rather gets a -1, which means the tape is full and you cannot write any more: Write failed. Last block written=17926. stat=-1 ERR=No space left on device There are two things to note: 1. When the program fails, it gets a -1 status with no previous 0 status. 2. When the program fails, it has written about 700 more blocks on the tape compared to the working program. One can easily understand why data is lost. So, bottom line: the pthread libraries somehow seem to lose the logical end of tape marker (i.e. return status of 0 from write()). I attach a copy of the program with documentation at the top on how to produce the problem and the output that one gets. Best regards, Kern PS: feel free to pass this email on. ------- End of forwarded message ------- -- Dan Langille : http://www.langille.org/ --Message-Boundary-2321 Content-Type: APPLICATION/OCTET-STREAM; NAME=-; TYPE=Plain Content-Transfer-Encoding: BASE64 Content-ID: <20030820092347.N20029@root.org> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=- SGVsbG8gRGFuLA0KDQpJJ3ZlIGZpbmFsbHkgZm91bmQgaG93IHRvIGNyZWF0ZSB0aGUgcHJv YmxlbQ0KYW5kIGhvdyB0byBlbGltaW5hdGUgaXQuIEkgdGhpbmsgeW91IG9yIHNvbWUNCkZy ZWVCU0QgZ3V5IHdpbGwgaGF2ZSB0byBsb29rIGF0IHRoZSBzb3VyY2UNCmNvZGUuDQoNCk15 IHRlc3RpbmcgY29uZmlybXMgd2hhdCBJIHByZXZpb3VzbHkgd3JvdGUgdGhhdA0KQmFjdWxh IGZhaWxzIGFzIHdlbGwgYXMgYnRhcGUgZG9pbmcgZWl0aGVyIEJhY3VsYQ0Kc3R5bGUgd3Jp dGVzIG9yIHJhdyB3cml0ZSgpIGNhbGxzLiAgVGhlcmUgaXMgb25seQ0Kb25lIHN0cmFuZ2Ug dHdpc3QgdG8gdGhpczogdGhlIGRlbW8gcHJvZ3JhbSB0aGF0DQpJIHNlbnQgeW91IHdvcmtz LiANCg0KSWYgeW91IHJlY29tcGlsZSB0aGUgZGVtbyBwcm9ncmFtIGFuZCBhZGQNCi1wdGhy ZWFkIHRvIGJvdGggdGhlIGNvbXBpbGUgYW5kIHRoZSBsaW5rLCBkYXRhDQppcyBsb3N0IC0t IGFuZCBvbmNlIHlvdSByZW1vdmUgdGhlIC1wdGhyZWFkDQpvbiB0aGUgY29tcGlsZSBhbmQg bGluaywgdGhlIHByb2dyYW0gd29ya3MgYWdhaW4uDQoNClRoZSBpbnRlcmVzdGluZyB0aGlu ZyBpcyB0aGF0IHdoZW4gdGhlIHByb2dyYW0NCndvcmtzLCBpdCBnZXRzIGEgMCBzdGF0dXMg b24gYSB3cml0ZSwgd2hpY2gNCmluZGljYXRlcyB0aGF0IHRoZSB0YXBlIGlzIGF0IHRoZSBl bmQgb2YgdGhlDQpMb2dpY2FsIEVPRiBtYXJrZXIgKG9yIGluIG90aGVyIHdvcmRzLCB0aGUN CnRhcGUgaXMgYWxtb3N0IGZ1bGwpOg0KDQogV3JpdGUgZmFpbGVkLiAgTGFzdCBibG9jayB3 cml0dGVuPTE3Mjk0LiBzdGF0PTAgRVJSPVVua25vd24gZXJyb3I6IDANCg0KV2hlbiB0aGUg cHJvZ3JhbSBpcyBjb21waWxlZC9saW5rZWQgd2l0aCB0aGUNCi1wdGhyZWFkIG9wdGlvbiwg aXQgZG9lcyBub3QgcmVjZWl2ZSB0aGUgMA0Kc3RhdHVzIGZyb20gYSB3cml0ZSgpLCBidXQg cmF0aGVyIGdldHMNCmEgLTEsIHdoaWNoIG1lYW5zIHRoZSB0YXBlIGlzIGZ1bGwgYW5kDQp5 b3UgY2Fubm90IHdyaXRlIGFueSBtb3JlOg0KDQpXcml0ZSBmYWlsZWQuICBMYXN0IGJsb2Nr IHdyaXR0ZW49MTc5MjYuIHN0YXQ9LTEgRVJSPU5vIHNwYWNlIGxlZnQgb24NCmRldmljZQ0K DQpUaGVyZSBhcmUgdHdvIHRoaW5ncyB0byBub3RlOiAxLiBXaGVuIHRoZSBwcm9ncmFtIGZh aWxzLA0KaXQgZ2V0cyBhIC0xIHN0YXR1cyB3aXRoIG5vIHByZXZpb3VzIDAgc3RhdHVzLiAg Mi4gV2hlbg0KdGhlIHByb2dyYW0gZmFpbHMsIGl0IGhhcyB3cml0dGVuIGFib3V0IDcwMCBt b3JlIGJsb2Nrcw0Kb24gdGhlIHRhcGUgY29tcGFyZWQgdG8gdGhlIHdvcmtpbmcgcHJvZ3Jh bS4gT25lIGNhbg0KZWFzaWx5IHVuZGVyc3RhbmQgd2h5IGRhdGEgaXMgbG9zdC4gIA0KDQpT bywgYm90dG9tIGxpbmU6IHRoZSBwdGhyZWFkIGxpYnJhcmllcyBzb21laG93DQpzZWVtIHRv IGxvc2UgdGhlIGxvZ2ljYWwgZW5kIG9mIHRhcGUgbWFya2VyDQooaS5lLiByZXR1cm4gc3Rh dHVzIG9mIDAgZnJvbSB3cml0ZSgpKS4gDQoNCkkgYXR0YWNoIGEgY29weSBvZiB0aGUgcHJv Z3JhbSB3aXRoIGRvY3VtZW50YXRpb24NCmF0IHRoZSB0b3Agb24gaG93IHRvIHByb2R1Y2Ug dGhlIHByb2JsZW0gYW5kDQp0aGUgb3V0cHV0IHRoYXQgb25lIGdldHMuDQoNCkJlc3QgcmVn YXJkcywNCg0KS2Vybg0KDQpQUzogZmVlbCBmcmVlIHRvIHBhc3MgdGhpcyBlbWFpbCBvbi4N Cg0K --Message-Boundary-2321 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20030820092347.L20029@root.org> Content-Description: Text from file 'tapetest.c' /* * * Program to test loss of data at EOM on * FreeBSD systems. * * Kern Sibbald, August 2003 * * If you build this program with: * * c++ -g -O2 -Wall -c tapetest.c * c++ -g -O2 -Wall tapetest.o -o tapetest * * Procedure for testing tape * ./tapetest /dev/your-tape-device * rewind * rawfill * rewind * scan * * The output will be: * * ======== * Rewound /dev/nsa0 * *Begin writing blocks of 64512 bytes. * ++++++++++++++++++++ ... * Write failed. Last block written=17294. stat=0 ERR=Unknown error: 0 * weof_dev * Wrote EOF to /dev/nsa0 * *Rewound /dev/nsa0 * *Starting scan at file 0 * 17294 blocks of 64512 bytes in file 0 * End of File mark. * End of File mark. * End of tape * Total files=1, blocks=17294, bytes = 1115670528 * ======== * * which is correct. Notice that the return status is * 0, while in the example below, which fails, the return * status is -1. * * If you build this program with: * * c++ -g -O2 -Wall -pthread -c tapetest.c * c++ -g -O2 -Wall -pthread tapetest.o -o tapetest * Note, we simply added -pthread compared to the * previous example. * * Procedure for testing tape * ./tapetest /dev/your-tape-device * rewind * rawfill * rewind * scan * * The output will be: * * ======== * Rewound /dev/nsa0 * *Begin writing blocks of 64512 bytes. * +++++++++++++++++++++++++++++ ... * Write failed. Last block written=17926. stat=-1 ERR=No space left on device * weof_dev * Wrote EOF to /dev/nsa0 * *Rewound /dev/nsa0 * *Starting scan at file 0 * 17913 blocks of 64512 bytes in file 0 * End of File mark. * End of File mark. * End of tape * Total files=1, blocks=17913, bytes = 1155603456 * ======== * * which is incroorect because it wrote 17,926 blocks but read * back only 17,913 blocks. * * */ #include #include #include #include #include #include #include #include #include #include #include #include #include #define FALSE 0 #define TRUE 1 #define dev_state(dev, state) ((dev)->state & (state)) /* Device state bits */ #define ST_OPENED (1<<0) /* set when device opened */ #define ST_TAPE (1<<1) /* is a tape device */ #define ST_FILE (1<<2) /* is a file device */ #define ST_FIFO (1<<3) /* is a fifo device */ #define ST_PROG (1<<4) /* is a program device */ #define ST_LABEL (1<<5) /* label found */ #define ST_MALLOC (1<<6) /* dev packet malloc'ed in init_dev() */ #define ST_APPEND (1<<7) /* ready for Bacula append */ #define ST_READ (1<<8) /* ready for Bacula read */ #define ST_EOT (1<<9) /* at end of tape */ #define ST_WEOT (1<<10) /* Got EOT on write */ #define ST_EOF (1<<11) /* Read EOF i.e. zero bytes */ #define ST_NEXTVOL (1<<12) /* Start writing on next volume */ #define ST_SHORT (1<<13) /* Short block read */ #define BLOCK_SIZE (512 * 126) /* Exported variables */ int quit = 0; char buf[100000]; int verbose = 0; int debug_level = 0; int fd = 0; struct DEVICE { int fd; int dev_errno; int file; int block_num; int state; char *buf; int buf_len; char *dev_name; int file_addr; }; DEVICE *dev; #define uint32_t unsigned long #define uint64_t unsigned long long /* Forward referenced subroutines */ static void do_tape_cmds(); static void helpcmd(); static void scancmd(); static void rewindcmd(); static void rawfill_cmd(); /* Static variables */ static char cmd[1000]; static void usage(); int get_cmd(char *prompt); /********************************************************************* * * Main Bacula Pool Creation Program * */ int main(int argc, char *argv[]) { int ch; while ((ch = getopt(argc, argv, "d:v?")) != -1) { switch (ch) { case 'd': /* set debug level */ debug_level = atoi(optarg); if (debug_level <= 0) { debug_level = 1; } break; case 'v': verbose++; break; case '?': default: helpcmd(); exit(0); } } argc -= optind; argv += optind; /* See if we can open a device */ if (argc == 0) { printf("No archive name specified.\n"); usage(); exit(1); } else if (argc != 1) { printf("Improper number of arguments specified.\n"); usage(); exit(1); } fd = open(argv[0], O_RDWR); if (fd < 0) { printf("Error opening %s ERR=%s\n", argv[0], strerror(errno)); exit(1); } dev = (DEVICE *)malloc(sizeof(DEVICE)); memset(dev, 0, sizeof(DEVICE)); dev->fd = fd; dev->dev_name = strdup(argv[0]); dev->buf_len = BLOCK_SIZE; dev->buf = (char *)malloc(BLOCK_SIZE); do_tape_cmds(); return 0; } int rewind_dev(DEVICE *dev) { struct mtop mt_com; if (dev->fd < 0) { dev->dev_errno = EBADF; printf("Bad call to rewind_dev. Device %s not open\n", dev->dev_name); return 0; } dev->state &= ~(ST_APPEND|ST_READ|ST_EOT|ST_EOF|ST_WEOT); /* remove EOF/EOT flags */ dev->block_num = dev->file = 0; mt_com.mt_op = MTREW; mt_com.mt_count = 1; if (ioctl(dev->fd, MTIOCTOP, (char *)&mt_com) < 0) { dev->dev_errno = errno; printf("Rewind error on %s. ERR=%s.\n", dev->dev_name, strerror(dev->dev_errno)); return 0; } return 1; } /* * Write an end of file on the device * Returns: 0 on success * non-zero on failure */ int weof_dev(DEVICE *dev, int num) { struct mtop mt_com; int stat; if (dev->fd < 0) { dev->dev_errno = EBADF; printf("Bad call to fsf_dev. Archive not open\n"); return -1; } dev->state &= ~(ST_EOT | ST_EOF); /* remove EOF/EOT flags */ dev->block_num = 0; printf("weof_dev\n"); mt_com.mt_op = MTWEOF; mt_com.mt_count = num; stat = ioctl(dev->fd, MTIOCTOP, (char *)&mt_com); if (stat == 0) { dev->file++; dev->file_addr = 0; } else { dev->dev_errno = errno; printf("ioctl MTWEOF error on %s. ERR=%s.\n", dev->dev_name, strerror(dev->dev_errno)); } return stat; } void quitcmd() { quit = 1; } /* * Rewind the tape. */ static void rewindcmd() { if (!rewind_dev(dev)) { printf("Bad status from rewind. ERR=%s\n", strerror(dev->dev_errno)); } else { printf("Rewound %s\n", dev->dev_name); } } /* * Write and end of file on the tape */ static void weofcmd() { int stat; if ((stat = weof_dev(dev, 1)) < 0) { printf("Bad status from weof %d. ERR=%s\n", stat, strerror(dev->dev_errno)); return; } else { printf("Wrote EOF to %s\n", dev->dev_name); } } /* * Read a record from the tape */ static void rrcmd() { char *buf; int stat, len; if (!get_cmd("Enter length to read: ")) { return; } len = atoi(cmd); if (len < 0 || len > 1000000) { printf("Bad length entered, using default of 1024 bytes.\n"); len = 1024; } buf = (char *)malloc(len); stat = read(fd, buf, len); if (stat > 0 && stat <= len) { errno = 0; } printf("Read of %d bytes gives stat=%d. ERR=%s\n", len, stat, strerror(errno)); free(buf); } /* * Write a record to the tape */ static void wrcmd() { int stat; int rfd; rfd = open("/dev/urandom", O_RDONLY); if (rfd) { read(rfd, dev->buf, dev->buf_len); } else { printf("Cannot open /dev/urandom.\n"); return; } printf("Write one block of %u bytes.\n", dev->buf_len); stat = write(dev->fd, dev->buf, dev->buf_len); if (stat != (int)dev->buf_len) { if (stat == -1) { printf("Bad status from write. ERR=%s\n", strerror(errno)); } else { printf("Expected to write %d bytes but wrote only %d.\n", dev->buf_len, stat); } } } /* * Scan tape by reading block by block. Report what is * on the tape. Note, this command does raw reads, and as such * will not work with fixed block size devices. */ static void scancmd() { int stat; int blocks, tot_blocks, tot_files; int block_size; uint64_t bytes; blocks = block_size = tot_blocks = 0; bytes = 0; if (dev->state & ST_EOT) { printf("End of tape\n"); return; } tot_files = dev->file; printf("Starting scan at file %u\n", dev->file); for (;;) { if ((stat = read(dev->fd, buf, sizeof(buf))) < 0) { dev->dev_errno = errno; printf("Bad status from read %d. ERR=%s\n", stat, strerror(dev->dev_errno)); if (blocks > 0) printf("%d block%s of %d bytes in file %d\n", blocks, blocks>1?"s":"", block_size, dev->file); return; } if (stat != block_size) { if (blocks > 0) { printf("%d block%s of %d bytes in file %d\n", blocks, blocks>1?"s":"", block_size, dev->file); blocks = 0; } block_size = stat; } if (stat == 0) { /* EOF */ printf("End of File mark.\n"); /* Two reads of zero means end of tape */ if (dev->state & ST_EOF) dev->state |= ST_EOT; else { dev->state |= ST_EOF; dev->file++; } if (dev->state & ST_EOT) { printf("End of tape\n"); break; } } else { /* Got data */ dev->state &= ~ST_EOF; blocks++; tot_blocks++; bytes += stat; } } tot_files = dev->file - tot_files; printf("Total files=%d, blocks=%d, bytes = %d\n", tot_files, tot_blocks, (int)bytes); } static void rawfill_cmd() { int stat; int rfd; uint32_t block_num = 0; uint32_t *p; int my_errno; rfd = open("/dev/urandom", O_RDONLY); if (rfd) { read(rfd, dev->buf, dev->buf_len); } else { printf("Cannot open /dev/urandom.\n"); return; } p = (uint32_t *)dev->buf; printf("Begin writing blocks of %u bytes.\n", dev->buf_len); for ( ;; ) { *p = block_num; stat = write(dev->fd, dev->buf, dev->buf_len); if (stat == (int)dev->buf_len) { if ((block_num++ % 100) == 0) { printf("+"); fflush(stdout); } continue; } break; } my_errno = errno; printf("\n"); weofcmd(); printf("Write failed. Last block written=%d. stat=%d ERR=%s\n", (int)block_num, stat, strerror(my_errno)); } /* Strip any trailing junk from the command */ void strip_trailing_junk(char *cmd) { char *p; p = cmd + strlen(cmd) - 1; /* strip trailing junk from command */ while ((p >= cmd) && (*p == '\n' || *p == '\r' || *p == ' ')) *p-- = 0; } /* folded search for string - case insensitive */ int fstrsch(char *a, char *b) /* folded case search */ { register char *s1,*s2; register char c1=0, c2=0; s1=a; s2=b; while (*s1) { /* do it the fast way */ if ((*s1++ | 0x20) != (*s2++ | 0x20)) return 0; /* failed */ } while (*a) { /* do it over the correct slow way */ if (isupper(c1 = *a)) { c1 = tolower((int)c1); } if (isupper(c2 = *b)) { c2 = tolower((int)c2); } if (c1 != c2) { return 0; } a++; b++; } return 1; } struct cmdstruct { char *key; void (*func)(); char *help; }; static struct cmdstruct commands[] = { {"help", helpcmd, "print this command"}, {"quit", quitcmd, "quit tapetest"}, {"rawfill", rawfill_cmd, "use write() to fill tape"}, {"rewind", rewindcmd, "rewind the tape"}, {"rr", rrcmd, "raw read the tape"}, {"wr", wrcmd, "raw write one block to the tape"}, {"scan", scancmd, "read() tape block by block to EOT and report"}, {"weof", weofcmd, "write an EOF on the tape"}, }; #define comsize (sizeof(commands)/sizeof(struct cmdstruct)) static void do_tape_cmds() { unsigned int i; int found; while (get_cmd("*")) { found = 0; for (i=0; i 0) cmd[--i] = 0; continue; } cmd[i++] = ch; cmd[i] = 0; } quit = 1; return 0; } --Message-Boundary-2321 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: <20030820092347.U20029@root.org> Content-Description: Content-Disposition: INLINE _______________________________________________ freebsd-scsi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-scsi To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" --Message-Boundary-2321-- From owner-freebsd-threads@FreeBSD.ORG Wed Aug 20 10:15:27 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D979016A4BF; Wed, 20 Aug 2003 10:15:27 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6558243FDD; Wed, 20 Aug 2003 10:15:27 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5994972DD4; Wed, 20 Aug 2003 10:15:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5406A72DD2; Wed, 20 Aug 2003 10:15:27 -0700 (PDT) Date: Wed, 20 Aug 2003 10:15:27 -0700 (PDT) From: Doug White To: Nate Lawson In-Reply-To: <20030820092347.G20029@root.org> Message-ID: <20030820101248.L61485@carver.gumbysoft.com> References: <20030820092347.G20029@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-stable@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: (Fwd) Lost data on FreeBSD tape (fwd) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 17:15:28 -0000 On Wed, 20 Aug 2003, Nate Lawson wrote: > This appears to be a pthreads problem, not scsi. Anyone care to look at > it? This will be an interesting fix ... since pthreads use non-blocking file descriptors underneath, fixing it may involve changing the semantics of non-blocking files. > The interesting thing is that when the program > works, it gets a 0 status on a write, which > indicates that the tape is at the end of the > Logical EOF marker (or in other words, the > tape is almost full): I'm kind of curious what he's referring to here. There are no EOF markers unless you write them yourself. Does bakula require you to stripe tapes before use? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Wed Aug 20 14:44:33 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC54716A4BF; Wed, 20 Aug 2003 14:44:32 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B78DE43F85; Wed, 20 Aug 2003 14:44:31 -0700 (PDT) (envelope-from davidxu@FreeBSD.org) Received: from localhost (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7KLiTUp008139; Wed, 20 Aug 2003 14:44:30 -0700 (PDT) (envelope-from davidxu@FreeBSD.org) From: David Xu To: deischen@FreeBSD.org, Daniel Eischen Date: Thu, 21 Aug 2003 05:47:31 +0800 User-Agent: KMail/1.5.2 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200308210547.25134.davidxu@FreeBSD.org> Content-Type: Multipart/Mixed; boundary="Boundary-00=_zx+Q/XlcOGFLZ07" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: threads@FreeBSD.org Subject: buffered signal X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: davidxu@FreeBSD.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 21:44:33 -0000 --Boundary-00=_zx+Q/XlcOGFLZ07 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Dan, I am thinking about a problem with buffered signals. Suppose if libkse is in critical region and signal A and B arrived, then A and B are buffered. Later, after thread leaves critical region, thread starts to process buffered signal A, before it can process A, another signal C arrived, so thread starts to process signal C, then in signal handler of C, it masks signal A in kernel and returns, so signal won't be processed in future because we current test kernel signal to see if A is masked. Though A is already delivered to userland but will never be processed! we never check this blocked signal A in pthread_sigmask,and sigpending() and sigsuspend(), sigwait...., possible we can repost it to kernel, but may have side effect, for example, it would lose orignal siginfo meaning. When A is masked, it must be masked by a signal handler by another new signal but not by normal user code, because buffered signal can only happen when it is executing libkse code, and further think that changing signal mask in signal handler is always not stable and not suggested, I think we can always process all buffered signals and ignore kernel signal mask. I am not very sure if it is legal, but shouldn't have problem in real world. ;-) Regards, David Xu --Boundary-00=_zx+Q/XlcOGFLZ07-- From owner-freebsd-threads@FreeBSD.ORG Wed Aug 20 23:57:33 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFA2416A4BF; Wed, 20 Aug 2003 23:57:33 -0700 (PDT) Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9CC843F93; Wed, 20 Aug 2003 23:57:31 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 4.21) id 19pjNx-0001P9-Rg; Thu, 21 Aug 2003 08:57:29 +0200 Date: Thu, 21 Aug 2003 08:57:29 +0200 From: Sheldon Hearn To: deischen@freebsd.org, freebsd-java@freebsd.org, threads@freebsd.org Message-ID: <20030821065729.GC5288@starjuice.net> Mail-Followup-To: deischen@freebsd.org, freebsd-java@freebsd.org, threads@freebsd.org References: <20030820065729.GL736@starjuice.net> <20030820141128.GG736@starjuice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030820141128.GG736@starjuice.net> User-Agent: Mutt/1.5.4i Sender: Sheldon Hearn Subject: Re: vmark hangs with libthr and libkse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 06:57:34 -0000 On (2003/08/20 16:11), Sheldon Hearn wrote: > > Any messages on the console or break-to-debugger info? Are you using > > SCHED_4BSD or SCHED_ULE? > > I think it was SCHED_4BSD. I scribbled the panic down on a piece of > paper, but can't find it now. *sigh* Nope, it's SCHED_ULE. > > > I just do what my old man told me when I complained that banging my head > > > against the wall hurt... "Don't do that, then". :-) > > > > No, please do that and give us some more info. We claim there > > are no bugs in libkse, so it's up to you to prove us wrong :-) > > Okay, let me finish my work, sync my disks and give it another whirl > this afternoon. :-) I tried with libkse and now I don't even get a useful panic. Just "page fault" and disk sync! I've found my scrap of paper, though. Here's what I got last week: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 code = supervisor write, page not present processor eflags = interrupt enabled, resume, IOPL = 0 current process = 4 (g_down) I don't have DDB in my kernel I could reinstall a kernel with DDB enabled. But then what do I do when I get my "page fault" followed by disk sync? I realize that the person seeing the problem is usually the person who should diagnose it, but I'm under hard pressure on a deadline for work. Perhaps someone else with a bit more free time could try this out? Ciao, Sheldon. From owner-freebsd-threads@FreeBSD.ORG Thu Aug 21 02:01:48 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFADC16A4BF; Thu, 21 Aug 2003 02:01:48 -0700 (PDT) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2B9B43FB1; Thu, 21 Aug 2003 02:01:38 -0700 (PDT) (envelope-from davidxu@viatech.com.cn) Received: from [192.168.1.240] (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RKXCQ85L; Thu, 21 Aug 2003 16:43:04 +0800 Date: Thu, 21 Aug 2003 17:05:26 +0800 From: David Xu To: Sheldon Hearn , deischen@freebsd.org , freebsd-java@freebsd.org , threads@freebsd.org Message-Id: <20030821165727.C1C0.DAVIDXU@viatech.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Mail 1.0 Subject: Re: vmark hangs with libthr and libkse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 09:01:49 -0000 ----- Original Message ----- From: "Sheldon Hearn" To: ; ; Sent: Thursday, August 21, 2003 2:57 PM Subject: Re: vmark hangs with libthr and libkse > On (2003/08/20 16:11), Sheldon Hearn wrote: > > > > Any messages on the console or break-to-debugger info? Are you using > > > SCHED_4BSD or SCHED_ULE? > > > > I think it was SCHED_4BSD. I scribbled the panic down on a piece of > > paper, but can't find it now. *sigh* > > Nope, it's SCHED_ULE. > ULE does not work with KSE, I have uploaded a patch, please try it. http://people.freebsd.org/~davidxu/kse/kse_ule.diff You can not get cpu affinity for KSE process with this scheduler, The patch only let KSE process work under ULE scheduler. I have not fully tested it, for some reason, I won't commit the patch. > > > > I just do what my old man told me when I complained that banging my head > > > > against the wall hurt... "Don't do that, then". :-) > > > > > > No, please do that and give us some more info. We claim there > > > are no bugs in libkse, so it's up to you to prove us wrong :-) > > > > Okay, let me finish my work, sync my disks and give it another whirl > > this afternoon. :-) > > I tried with libkse and now I don't even get a useful panic. Just "page > fault" and disk sync! > > I've found my scrap of paper, though. Here's what I got last week: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > code = supervisor write, page not present > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 4 (g_down) > > I don't have DDB in my kernel > > I could reinstall a kernel with DDB enabled. But then what do I do when > I get my "page fault" followed by disk sync? > > I realize that the person seeing the problem is usually the person who > should diagnose it, but I'm under hard pressure on a deadline for work. > > Perhaps someone else with a bit more free time could try this out? > > Ciao, > Sheldon. > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" -- David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Aug 21 02:06:26 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0621916A4BF; Thu, 21 Aug 2003 02:06:26 -0700 (PDT) Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82E0243F3F; Thu, 21 Aug 2003 02:06:22 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 4.21) id 19plOe-0001mY-3D; Thu, 21 Aug 2003 11:06:20 +0200 Date: Thu, 21 Aug 2003 11:06:20 +0200 From: Sheldon Hearn To: David Xu Message-ID: <20030821090620.GM5288@starjuice.net> Mail-Followup-To: David Xu , "deischen@freebsd.org" , "freebsd-java@freebsd.org" , "threads@freebsd.org" References: <20030821165727.C1C0.DAVIDXU@viatech.com.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821165727.C1C0.DAVIDXU@viatech.com.cn> User-Agent: Mutt/1.5.4i Sender: Sheldon Hearn cc: "deischen@freebsd.org" cc: "threads@freebsd.org" cc: "freebsd-java@freebsd.org" Subject: Re: vmark hangs with libthr and libkse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 09:06:26 -0000 On (2003/08/21 17:05), David Xu wrote: > ULE does not work with KSE, I have uploaded a patch, please try it. > http://people.freebsd.org/~davidxu/kse/kse_ule.diff > You can not get cpu affinity for KSE process with this scheduler, > The patch only let KSE process work under ULE scheduler. > I have not fully tested it, for some reason, I won't commit the patch. Good to know. I'll try to test your patch at the end of the day, if I finish my work. Realistically, I'll probably only have feedback for you late tomorrow. Ciao, Sheldon. From owner-freebsd-threads@FreeBSD.ORG Fri Aug 22 12:54:55 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C598A16A4BF for ; Fri, 22 Aug 2003 12:54:55 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B83443FB1 for ; Fri, 22 Aug 2003 12:54:54 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h7MJs7i10151; Fri, 22 Aug 2003 21:54:08 +0200 From: Kern Sibbald To: Doug White Content-Type: text/plain Organization: Message-Id: <1061582047.28811.324.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Aug 2003 21:54:07 +0200 Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org cc: Nate Lawson Subject: pthread problem writing tapes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2003 19:54:56 -0000 Hello, > On Wed, 20 Aug 2003, Nate Lawson wrote: >> This appears to be a pthreads problem, not scsi. Anyone care to look at >> it? > This will be an interesting fix ... since pthreads use non-blocking file > descriptors underneath, fixing it may involve changing the semantics of > non-blocking files. >> The interesting thing is that when the program >> works, it gets a 0 status on a write, which >> indicates that the tape is at the end of the >> Logical EOF marker (or in other words, the >> tape is almost full): > I'm kind of curious what he's referring to here. Yes, I'm sorry, my description was not very clear or accurate. What I wanted to say is that when writing to a tape at some point you get a zero status back (i.e. no bytes written) this indicates to the program that the logical end of tape (not EOF as I wrote) has been reached. The logical end of tape is a marker on the tape before the physical end of the tape. If you stop writing when the logical end of tape is reached, you are more or less guaranteed that any buffered blocks will be correctly written to the tape. If you continue writing you eventually reach the physical end of the tape and the O/S returns a -1 status and errno=ENOSPC. > There are no EOF markers unless you write them yourself. > Does bakula require you to stripe tapes > before use? > -- > Doug White | FreeBSD: The Power to Serve > dwhite@gumbysoft.com | www.FreeBSD.org Best regards, Kern From owner-freebsd-threads@FreeBSD.ORG Sat Aug 23 01:52:39 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8908716A4D7 for ; Sat, 23 Aug 2003 01:52:39 -0700 (PDT) Received: from outgoing3.securityfocus.com (outgoing3.securityfocus.com [205.206.231.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52ECC44436 for ; Sat, 23 Aug 2003 00:49:05 -0700 (PDT) (envelope-from bugtraq-return-@securityfocus.com) Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19]) by outgoing3.securityfocus.com (Postfix) with SMTP id EC391A353E for ; Sat, 23 Aug 2003 01:44:06 -0600 (MDT) Received: (qmail 5924 invoked by alias); 23 Aug 2003 01:45:24 -0000 Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Date: 23 Aug 2003 01:45:24 -0000 Message-ID: <1061603124.5923.ezmlm@securityfocus.com> From: bugtraq-return-@securityfocus.com To: freebsd-threads@freebsd.org Delivered-To: responder for bugtraq@securityfocus.com Received: (qmail 5915 invoked from network); 23 Aug 2003 01:45:24 -0000 Received: from mail.securityfocus.com (205.206.231.9) by lists.securityfocus.com with SMTP; 23 Aug 2003 01:45:24 -0000 Received: (qmail 18558 invoked by alias); 23 Aug 2003 07:39:49 -0000 Received: (qmail 18551 invoked from network); 23 Aug 2003 07:39:49 -0000 Received: from outgoing2.securityfocus.com (205.206.231.26) by mail.securityfocus.com with SMTP; 23 Aug 2003 07:39:49 -0000 Received: from MORDOR (BSN-95-242-77.dsl.siol.net [193.95.242.77]) by outgoing2.securityfocus.com (Postfix) with ESMTP id 209D08F79F for ; Sat, 23 Aug 2003 01:43:03 -0600 (MDT) MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: ezmlm response X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2003 08:52:39 -0000 Hi! This is the ezmlm program. I'm managing the bugtraq@securityfocus.com mailing list. I'm working for my owner, who can be reached at bugtraq-owner@securityfocus.com. This is a generic help message. The message I received wasn't sent to any of my command addresses. Here is a list of the command addresses supported: Send mail to the following for info and FAQ for this list: Similar addresses exist for the digest list: To get messages 123 through 145 (a maximum of 100 per request), mail: To get an index with subject and author for messages 123-456, mail: To receive all messages with the same subject as message 12345, send an empty message to: The messages do not really need to be empty, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example "john@host.domain", just add a hyphen and your address (with '=' instead of '@') after the command word: To stop subscription for this address, mail: --- Administrative commands for the bugtraq list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: For help and a description of available commands, send a message to: To subscribe to the list, send a message to: To remove your address from the list, just send a message to the address in the ``List-Unsubscribe'' header of any list message. If you haven't changed addresses since subscribing, you can also send a message to: or for the digest to: For addition or removal of addresses, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete the transaction. If you need to get in touch with the human owner of this list, please send a message to: Please include a FORWARDED list message with ALL HEADERS intact to make it easier to help you. --- Enclosed is a copy of the request I received. Return-Path: Received: (qmail 5915 invoked from network); 23 Aug 2003 01:45:24 -0000 Received: from mail.securityfocus.com (205.206.231.9) by lists.securityfocus.com with SMTP; 23 Aug 2003 01:45:24 -0000 Received: (qmail 18558 invoked by alias); 23 Aug 2003 07:39:49 -0000 Received: (qmail 18551 invoked from network); 23 Aug 2003 07:39:49 -0000 Received: from outgoing2.securityfocus.com (205.206.231.26) by mail.securityfocus.com with SMTP; 23 Aug 2003 07:39:49 -0000 Received: from MORDOR (BSN-95-242-77.dsl.siol.net [193.95.242.77]) by outgoing2.securityfocus.com (Postfix) with ESMTP id 209D08F79F for ; Sat, 23 Aug 2003 01:43:03 -0600 (MDT) From: To: Subject: Re: Approved Date: Sat, 23 Aug 2003 9:49:03 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0015B1F4" Message-Id: <20030823074303.209D08F79F@outgoing2.securityfocus.com> This is a multipart message in MIME format --_NextPart_000_0015B1F4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0015B1F4--