From owner-freebsd-arch@FreeBSD.ORG Sun Jun 21 11:52:05 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D440C106564A for ; Sun, 21 Jun 2009 11:52:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id B52F28FC19 for ; Sun, 21 Jun 2009 11:52:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n5LBq04k082541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jun 2009 14:52:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n5LBq0d9031850; Sun, 21 Jun 2009 14:52:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n5LBpvjI031849; Sun, 21 Jun 2009 14:51:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jun 2009 14:51:57 +0300 From: Kostik Belousov To: Jilles Tjoelker Message-ID: <20090621115157.GJ2884@deviant.kiev.zoral.com.ua> References: <20090619162328.GA79975@stack.nl> <20090620161540.GF2884@deviant.kiev.zoral.com.ua> <20090620203300.GA21763@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sT9gWZPUZYhvPS56" Content-Disposition: inline In-Reply-To: <20090620203300.GA21763@stack.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-arch@freebsd.org Subject: Re: deadlocks with intr NFS mounts and ^Z (or: PCATCH and sleepable locks) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 11:52:06 -0000 --sT9gWZPUZYhvPS56 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 20, 2009 at 10:33:00PM +0200, Jilles Tjoelker wrote: > On Sat, Jun 20, 2009 at 07:15:40PM +0300, Kostik Belousov wrote: > > On Fri, Jun 19, 2009 at 06:23:28PM +0200, Jilles Tjoelker wrote: > > > I have been having trouble with deadlocks with NFS mounts for a while, > > > and I have found at least one way it can deadlock. It seems an issue > > > with the sleep/lock system. >=20 > > > NFS sleeps while holding a lockmgr lock, waiting for a reply from the > > > server. When the mount is set intr, this is an interruptible sleep, so > > > that interrupting signals can abort the sleep. However, this also mea= ns > > > that SIGSTOP etc will suspend the thread without waking it up first, = so > > > it will be suspended with a lock held. >=20 > > > If it holds the wrong locks, it is possible that the shell will not be > > > able to run, and the process cannot be continued in the normal manner. >=20 > > > Due to some other things I do not understand, it is then possible that > > > the process cannot be continued at all (SIGCONT seems ignored), but in > > > simple cases SIGCONT works, and things go back to normal. >=20 > > > In any case, this situation is undesirable, as even 'umount -f' doesn= 't > > > work while the thread is suspended. >=20 > > > Of course, this reasoning applies to any code that goes to sleep > > > interruptibly while holding a lock (sx or lockmgr). Is this supposed = to > > > be possible (likely useful)? If so, a third type of sleep would be > > > needed that is interrupted by signals but not suspended? If not, > > > something should check that it doesn't happen and NFS intr mounts may > > > need to check for signals periodically or find a way to avoid sleeping > > > with locks held. >=20 > > > The td_locks field is only accessible for the current thread, so it > > > cannot be used to check if suspending is safe. >=20 > > > Also, making SIGSTOP and the like interrupt/restart syscalls is not > > > acceptable unless you find some way to do it such that userland won't > > > notice. For example, a read of 10 megabytes from a regular file with > > > that much available must not return less then 10 megabytes. >=20 > > Note that NFS does check for the signals during i/o, so you may get > > short reads anyway. >=20 > > I do think that the right solution both there and with SINGLE_NO_EXIT > > case for thread_single is to stop at the usermode boundary instead of > > suspending a thread in the interruptible sleep state. >=20 > > I set error code returned from interrupted msleep() to ERESTART, > > that seems to be the right thing, at least to restart the i/o that > > transferred no data upon receiving SIGSTOP. >=20 > Any such short read on a regular file is wrong. That that badness > already occurs in some cases is not an excuse to make it occur more > often. Particularly because process suspension is expected not to affect > the process and interrupting syscalls would change the behaviour of the > debugged program significantly, while the current interruptions only > occur with signals that likely terminate the process anyway (note that > intr mounts only check for SIGINT, SIGTERM, SIGHUP, SIGKILL, SIGSTOP and > SIGQUIT and appear to mask all others; I don't know why SIGTSTP gets > through -- possibly a thread/process difference). >=20 > No matter the SIGSTOP issue, a warning about the interruptions in the > mount_nfs(8) man page may be in order; the current language makes the > impression that intr is only a good thing, which is not the case. This > applies to all NFS versions. A better way to deal with nonresponsive NFS > servers that will not come back would be forced unmount (does it always > work, apart from the case mentioned above? same for the experimental > client?). SIGKILL (but not any other signal, not even SIGSTOP) could > also be allowed on processes blocked on nointr mounts. >=20 > Another point (mostly for socket operations and the like) is that the > current causes of interrupted system calls are under control of the > application: if you do not catch any signals, you will only get short > read/writes for reasons related to the underlying object; hence, it is > often not necessary to add (ugly) code to handle it: any unexpected > short read or write is a problem with the underlying object. >=20 > Another example which currently works and would be a shame to break: >=20 > % /usr/bin/time sleep 10 > ^Z > zsh: suspended /usr/bin/time sleep 10 > % fg > [1] + continued /usr/bin/time sleep 10 > 10.00 real 0.00 user 0.00 sys > % >=20 > What's more, the fact that this works is thanks to the kernel. sleep(1) > just calls nanosleep(2), and because it doesn't catch any signals, that > suffices. >=20 > I do notice this is already broken for debuggers. Attaching gdb or truss > to a running sleep process immediately aborts the nanosleep with EINTR. The point is valid, I updated the patch by adding a special flag for the msleep that indicates that stop is allowed only on usermode boundary. Sleeps from the nfs client where resources are possibly locked are marked with the flag. diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 5c1d553..5312ffa 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -2310,18 +2310,28 @@ static void sig_suspend_threads(struct thread *td, struct proc *p, int sending) { struct thread *td2; + int wakeup_swapper; =20 PROC_LOCK_ASSERT(p, MA_OWNED); PROC_SLOCK_ASSERT(p, MA_OWNED); =20 + wakeup_swapper =3D 0; FOREACH_THREAD_IN_PROC(p, td2) { thread_lock(td2); td2->td_flags |=3D TDF_ASTPENDING | TDF_NEEDSUSPCHK; if ((TD_IS_SLEEPING(td2) || TD_IS_SWAPPED(td2)) && - (td2->td_flags & TDF_SINTR) && - !TD_IS_SUSPENDED(td2)) { - thread_suspend_one(td2); - } else { + (td2->td_flags & TDF_SINTR)) { + if (td2->td_flags & TDF_SBDRY) { + if (TD_IS_SUSPENDED(td2)) + wakeup_swapper |=3D + thread_unsuspend_one(td2); + if (TD_ON_SLEEPQ(td2)) + wakeup_swapper |=3D + sleepq_abort(td2, ERESTART); + } else if (!TD_IS_SUSPENDED(td2)) { + thread_suspend_one(td2); + } + } else if (!TD_IS_SUSPENDED(td2)) { if (sending || td !=3D td2) td2->td_flags |=3D TDF_ASTPENDING; #ifdef SMP @@ -2331,6 +2341,8 @@ sig_suspend_threads(struct thread *td, struct proc *p= , int sending) } thread_unlock(td2); } + if (wakeup_swapper) + kick_proc0(); } =20 int diff --git a/sys/kern/kern_synch.c b/sys/kern/kern_synch.c index b91c1a5..58488ac 100644 --- a/sys/kern/kern_synch.c +++ b/sys/kern/kern_synch.c @@ -188,6 +188,8 @@ _sleep(void *ident, struct lock_object *lock, int prior= ity, flags =3D SLEEPQ_SLEEP; if (catch) flags |=3D SLEEPQ_INTERRUPTIBLE; + if (priority & PBDRY) + flags |=3D SLEEPQ_STOP_ON_BDRY; =20 sleepq_lock(ident); CTR5(KTR_PROC, "sleep: thread %ld (pid %ld, %s) on %s (%p)", @@ -344,11 +346,16 @@ wakeup(void *ident) { int wakeup_swapper; =20 + repeat: sleepq_lock(ident); wakeup_swapper =3D sleepq_broadcast(ident, SLEEPQ_SLEEP, 0, 0); sleepq_release(ident); - if (wakeup_swapper) - kick_proc0(); + if (wakeup_swapper) { + if (ident =3D=3D &proc0) + goto repeat; + else + kick_proc0(); + } } =20 /* @@ -361,11 +368,16 @@ wakeup_one(void *ident) { int wakeup_swapper; =20 + repeat: sleepq_lock(ident); wakeup_swapper =3D sleepq_signal(ident, SLEEPQ_SLEEP, 0, 0); sleepq_release(ident); - if (wakeup_swapper) - kick_proc0(); + if (wakeup_swapper) { + if (ident =3D=3D &proc0) + goto repeat; + else + kick_proc0(); + } } =20 static void diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c index bb8779b..800a1d1 100644 --- a/sys/kern/kern_thread.c +++ b/sys/kern/kern_thread.c @@ -504,6 +504,22 @@ thread_unlink(struct thread *td) /* Must NOT clear links to proc! */ } =20 +static int +recalc_remaining(struct proc *p, int mode) +{ + int remaining; + + if (mode =3D=3D SINGLE_EXIT) + remaining =3D p->p_numthreads; + else if (mode =3D=3D SINGLE_BOUNDARY) + remaining =3D p->p_numthreads - p->p_boundary_count; + else if (mode =3D=3D SINGLE_NO_EXIT) + remaining =3D p->p_numthreads - p->p_suspcount; + else + panic("recalc_remaining: wrong mode %d", mode); + return (remaining); +} + /* * Enforce single-threading. * @@ -551,12 +567,7 @@ thread_single(int mode) p->p_flag |=3D P_STOPPED_SINGLE; PROC_SLOCK(p); p->p_singlethread =3D td; - if (mode =3D=3D SINGLE_EXIT) - remaining =3D p->p_numthreads; - else if (mode =3D=3D SINGLE_BOUNDARY) - remaining =3D p->p_numthreads - p->p_boundary_count; - else - remaining =3D p->p_numthreads - p->p_suspcount; + remaining =3D recalc_remaining(p, mode); while (remaining !=3D 1) { if (P_SHOULDSTOP(p) !=3D P_STOPPED_SINGLE) goto stopme; @@ -587,18 +598,17 @@ thread_single(int mode) wakeup_swapper |=3D sleepq_abort(td2, ERESTART); break; + case SINGLE_NO_EXIT: + if (TD_IS_SUSPENDED(td2) && + !(td2->td_flags & TDF_BOUNDARY)) + wakeup_swapper |=3D + thread_unsuspend_one(td2); + if (TD_ON_SLEEPQ(td2) && + (td2->td_flags & TDF_SINTR)) + wakeup_swapper |=3D + sleepq_abort(td2, ERESTART); + break; default: - if (TD_IS_SUSPENDED(td2)) { - thread_unlock(td2); - continue; - } - /* - * maybe other inhibited states too? - */ - if ((td2->td_flags & TDF_SINTR) && - (td2->td_inhibitors & - (TDI_SLEEPING | TDI_SWAPPED))) - thread_suspend_one(td2); break; } } @@ -611,12 +621,7 @@ thread_single(int mode) } if (wakeup_swapper) kick_proc0(); - if (mode =3D=3D SINGLE_EXIT) - remaining =3D p->p_numthreads; - else if (mode =3D=3D SINGLE_BOUNDARY) - remaining =3D p->p_numthreads - p->p_boundary_count; - else - remaining =3D p->p_numthreads - p->p_suspcount; + remaining =3D recalc_remaining(p, mode); =20 /* * Maybe we suspended some threads.. was it enough? @@ -630,12 +635,7 @@ stopme: * In the mean time we suspend as well. */ thread_suspend_switch(td); - if (mode =3D=3D SINGLE_EXIT) - remaining =3D p->p_numthreads; - else if (mode =3D=3D SINGLE_BOUNDARY) - remaining =3D p->p_numthreads - p->p_boundary_count; - else - remaining =3D p->p_numthreads - p->p_suspcount; + remaining =3D recalc_remaining(p, mode); } if (mode =3D=3D SINGLE_EXIT) { /* diff --git a/sys/kern/subr_sleepqueue.c b/sys/kern/subr_sleepqueue.c index 01fcc73..781c186 100644 --- a/sys/kern/subr_sleepqueue.c +++ b/sys/kern/subr_sleepqueue.c @@ -341,6 +341,8 @@ sleepq_add(void *wchan, struct lock_object *lock, const= char *wmesg, int flags, if (flags & SLEEPQ_INTERRUPTIBLE) { td->td_flags |=3D TDF_SINTR; td->td_flags &=3D ~TDF_SLEEPABORT; + if (flags & SLEEPQ_STOP_ON_BDRY) + td->td_flags |=3D TDF_SBDRY; } thread_unlock(td); } diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c index 22e2a79..d5d426e 100644 --- a/sys/nfsclient/nfs_bio.c +++ b/sys/nfsclient/nfs_bio.c @@ -1255,7 +1255,7 @@ nfs_getcacheblk(struct vnode *vp, daddr_t bn, int siz= e, struct thread *td) sigset_t oldset; =20 nfs_set_sigmask(td, &oldset); - bp =3D getblk(vp, bn, size, PCATCH, 0, 0); + bp =3D getblk(vp, bn, size, NFS_PCATCH, 0, 0); nfs_restore_sigmask(td, &oldset); while (bp =3D=3D NULL) { if (nfs_sigintr(nmp, NULL, td)) @@ -1292,7 +1292,7 @@ nfs_vinvalbuf(struct vnode *vp, int flags, struct thr= ead *td, int intrflg) if ((nmp->nm_flag & NFSMNT_INT) =3D=3D 0) intrflg =3D 0; if (intrflg) { - slpflag =3D PCATCH; + slpflag =3D NFS_PCATCH; slptimeo =3D 2 * hz; } else { slpflag =3D 0; @@ -1371,7 +1371,7 @@ nfs_asyncio(struct nfsmount *nmp, struct buf *bp, str= uct ucred *cred, struct thr } again: if (nmp->nm_flag & NFSMNT_INT) - slpflag =3D PCATCH; + slpflag =3D NFS_PCATCH; gotiod =3D FALSE; =20 /* @@ -1440,7 +1440,7 @@ again: mtx_unlock(&nfs_iod_mtx); =09 return (error2); } - if (slpflag =3D=3D PCATCH) { + if (slpflag =3D=3D NFS_PCATCH) { slpflag =3D 0; slptimeo =3D 2 * hz; } diff --git a/sys/nfsclient/nfs_socket.c b/sys/nfsclient/nfs_socket.c index 1ae31a5..2398695 100644 --- a/sys/nfsclient/nfs_socket.c +++ b/sys/nfsclient/nfs_socket.c @@ -516,7 +516,7 @@ nfs_reconnect(struct nfsreq *rep) =20 KASSERT(mtx_owned(&nmp->nm_mtx), ("NFS mnt lock not owned !")); if (nmp->nm_flag & NFSMNT_INT) - slpflag =3D PCATCH; + slpflag =3D NFS_PCATCH; /* * Wait for any pending writes to this socket to drain (or timeout). */ @@ -768,7 +768,7 @@ tryagain: slpflag =3D 0; mtx_lock(&nmp->nm_mtx); if (nmp->nm_flag & NFSMNT_INT) - slpflag =3D PCATCH; + slpflag =3D NFS_PCATCH; mtx_unlock(&nmp->nm_mtx); mtx_lock(&rep->r_mtx); while ((rep->r_mrep =3D=3D NULL) && (error =3D=3D 0) &&=20 @@ -1791,7 +1791,7 @@ nfs_connect_lock(struct nfsreq *rep) =20 td =3D rep->r_td; if (rep->r_nmp->nm_flag & NFSMNT_INT) - slpflag =3D PCATCH; + slpflag =3D NFS_PCATCH; while (*statep & NFSSTA_SNDLOCK) { error =3D nfs_sigintr(rep->r_nmp, rep, td); if (error) { @@ -1800,7 +1800,7 @@ nfs_connect_lock(struct nfsreq *rep) *statep |=3D NFSSTA_WANTSND; (void) msleep(statep, &rep->r_nmp->nm_mtx, slpflag | (PZERO - 1), "nfsndlck", slptimeo); - if (slpflag =3D=3D PCATCH) { + if (slpflag & PCATCH) { slpflag =3D 0; slptimeo =3D 2 * hz; } diff --git a/sys/nfsclient/nfs_vnops.c b/sys/nfsclient/nfs_vnops.c index 3623fab..a8d098b 100644 --- a/sys/nfsclient/nfs_vnops.c +++ b/sys/nfsclient/nfs_vnops.c @@ -2931,7 +2931,7 @@ nfs_flush(struct vnode *vp, int waitfor, int commit) int bvecsize =3D 0, bveccount; =20 if (nmp->nm_flag & NFSMNT_INT) - slpflag =3D PCATCH; + slpflag =3D NFS_PCATCH; if (!commit) passone =3D 0; bo =3D &vp->v_bufobj; @@ -3129,7 +3129,7 @@ loop: error =3D EINTR; goto done; } - if (slpflag =3D=3D PCATCH) { + if (slpflag & PCATCH) { slpflag =3D 0; slptimeo =3D 2 * hz; } @@ -3167,7 +3167,7 @@ loop: error =3D nfs_sigintr(nmp, NULL, td); if (error) goto done; - if (slpflag =3D=3D PCATCH) { + if (slpflag & PCATCH) { slpflag =3D 0; slptimeo =3D 2 * hz; } diff --git a/sys/nfsclient/nfsmount.h b/sys/nfsclient/nfsmount.h index 85f8501..c98a172 100644 --- a/sys/nfsclient/nfsmount.h +++ b/sys/nfsclient/nfsmount.h @@ -147,6 +147,8 @@ struct nfsmount { #define NFS_TPRINTF_DELAY 30 #endif =20 +#define NFS_PCATCH (PCATCH | PBDRY) + #endif =20 #endif diff --git a/sys/sys/param.h b/sys/sys/param.h index 06745f8..5ee9c16 100644 --- a/sys/sys/param.h +++ b/sys/sys/param.h @@ -186,6 +186,7 @@ #define PRIMASK 0x0ff #define PCATCH 0x100 /* OR'd with pri for tsleep to check signals */ #define PDROP 0x200 /* OR'd with pri to stop re-entry of interlock mutex */ +#define PBDRY 0x400 /* for PCATCH stop is done on the user boundary */ =20 #define NZERO 0 /* default "nice" */ =20 diff --git a/sys/sys/proc.h b/sys/sys/proc.h index 0a4b79c..b65db62 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -320,7 +320,7 @@ do { \ #define TDF_BOUNDARY 0x00000400 /* Thread suspended at user boundary */ #define TDF_ASTPENDING 0x00000800 /* Thread has some asynchronous events. = */ #define TDF_TIMOFAIL 0x00001000 /* Timeout from sleep after we were awake.= */ -#define TDF_UNUSED2000 0x00002000 /* --available-- */ +#define TDF_SBDRY 0x00002000 /* Stop only on usermode boundary. */ #define TDF_UPIBLOCKED 0x00004000 /* Thread blocked on user PI mutex. */ #define TDF_NEEDSUSPCHK 0x00008000 /* Thread may need to suspend. */ #define TDF_NEEDRESCHED 0x00010000 /* Thread needs to yield. */ diff --git a/sys/sys/sleepqueue.h b/sys/sys/sleepqueue.h index 0d1f361..362945a 100644 --- a/sys/sys/sleepqueue.h +++ b/sys/sys/sleepqueue.h @@ -93,6 +93,8 @@ struct thread; #define SLEEPQ_SX 0x03 /* Used by an sx lock. */ #define SLEEPQ_LK 0x04 /* Used by a lockmgr. */ #define SLEEPQ_INTERRUPTIBLE 0x100 /* Sleep is interruptible. */ +#define SLEEPQ_STOP_ON_BDRY 0x200 /* Stop sleeping thread on + user mode boundary */ =20 void init_sleepqueues(void); int sleepq_abort(struct thread *td, int intrval); --sT9gWZPUZYhvPS56 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAko+Ht0ACgkQC3+MBN1Mb4i8UACdF/vS3aAq6zWOi4PO438RpVA5 lVQAoLWpwuS57yLZjH8mMLPYEoE1xIGs =ClRu -----END PGP SIGNATURE----- --sT9gWZPUZYhvPS56-- From owner-freebsd-arch@FreeBSD.ORG Sun Jun 21 14:03:15 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14D9E106566C; Sun, 21 Jun 2009 14:03:15 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9953C8FC15; Sun, 21 Jun 2009 14:03:14 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n5LE3CHu098004; Sun, 21 Jun 2009 16:03:12 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n5LE3CTL098003; Sun, 21 Jun 2009 16:03:12 +0200 (CEST) (envelope-from marius) Date: Sun, 21 Jun 2009 16:03:12 +0200 From: Marius Strobl To: Jeff Roberson Message-ID: <20090621140312.GC71667@alchemy.franken.de> References: <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Peter Grehan Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 14:03:15 -0000 On Wed, Jun 17, 2009 at 12:55:52PM -1000, Jeff Roberson wrote: > > On Tue, 9 Jun 2009, Peter Grehan wrote: > > >>As for sparc64 allocating the storage for the dynamic area > >>from end probably isn't a good idea as the pmap code assumes > >>that the range from KERNBASE to end is covered by the pages > >>allocated by and locked into the TLB for the kernel by the > >>loader > > > >Ditto for ppc. It's possible to get the additional space from within or > >after return from pmap_bootstrap() (like thread0's kstack, or the msgbuf). > > http://people.freebsd.org/~jeff/dpcpu.diff > > I have updated this patch based on feedback relating to various > architectures md code. I tried to model most architectures after the way > msgbuf memory was taken. I have no capacity to test anything other than > i386 and amd64. ARM is reported to work with one minor diff. Apparently > sparc64 worked with the earlier diff but this should be cleaner. If > anyone can report back on sparc64, mips, or powerpc, I'd appreciate it. > The earlier patch worked on sparc64 as long as the kernel happened to leave enough room in the last 4MB page allocated for it. The new version unfortunately doesn't compile on sparc64 as pmap_bootstrap_alloc() is static to its pmap.c (I think it should also stay that way). Also the memory allocated with it isn't safe to be used before we've taken over the trap table. A kernel built with the sparc64 bits replaced with the following patch boots fine: http://people.freebsd.org/~marius/sparc64_dpcpu.diff Do you have some simple test case for DPCPU which can be used to verify that it actually works? Marius From owner-freebsd-arch@FreeBSD.ORG Sun Jun 21 16:17:28 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E83106564A; Sun, 21 Jun 2009 16:17:28 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD7F8FC16; Sun, 21 Jun 2009 16:17:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fxm17 with SMTP id 17so167299fxm.43 for ; Sun, 21 Jun 2009 09:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=kMs5hl0rMrLoduzM9odLHZg/FSTAczKHiMqPzAbWupA=; b=jXFSch78ucLlbiuOqmtI4Q+gmp+07kpiomZ8v2j6zIp02DdeLMpoYt0U/8o744/6fU 9GBqAAwiQBt2AGIkj5wba5KlVkuc8tScPkMhR8oVQr8X2Dp3tCBy93PFaPqw3VmwzpwP DNe+J4jSOFVEszB5Pnl7RPY3Ki1bTL0Cjf2Ww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=sZYQSd0ZTNqzJ0RB950r3MYXPYkYEEa1WaijqUF7BdI+YrImgosn778uH2yW+aKPdF nDFKSpCtHVudJXkO2BSsEcWPmIWs8j8n8Y/XD6i+aj7X2VIJW19jNvoMWQRjyAPaCYB6 wZQ6WNdQO2yMUEHwuAGjxy5v7b9gcZsdLaN00= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.105.195 with SMTP id u3mr4715192fao.13.1245599707490; Sun, 21 Jun 2009 08:55:07 -0700 (PDT) In-Reply-To: <20090621140312.GC71667@alchemy.franken.de> References: <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> <20090621140312.GC71667@alchemy.franken.de> Date: Sun, 21 Jun 2009 17:55:07 +0200 X-Google-Sender-Auth: 37ad2332a6eec4b3 Message-ID: <3bbf2fe10906210855r6c98568aj7bcc9ec3e057ae01@mail.gmail.com> From: Attilio Rao To: Marius Strobl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Peter Grehan Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 16:17:29 -0000 2009/6/21 Marius Strobl : > On Wed, Jun 17, 2009 at 12:55:52PM -1000, Jeff Roberson wrote: >> >> On Tue, 9 Jun 2009, Peter Grehan wrote: >> >> >>As for sparc64 allocating the storage for the dynamic area >> >>from end probably isn't a good idea as the pmap code assumes >> >>that the range from KERNBASE to end is covered by the pages >> >>allocated by and locked into the TLB for the kernel by the >> >>loader >> > >> >Ditto for ppc. It's possible to get the additional space from within or >> >after return from pmap_bootstrap() (like thread0's kstack, or the msgbuf). >> >> http://people.freebsd.org/~jeff/dpcpu.diff >> >> I have updated this patch based on feedback relating to various >> architectures md code. I tried to model most architectures after the way >> msgbuf memory was taken. I have no capacity to test anything other than >> i386 and amd64. ARM is reported to work with one minor diff. Apparently >> sparc64 worked with the earlier diff but this should be cleaner. If >> anyone can report back on sparc64, mips, or powerpc, I'd appreciate it. >> > > The earlier patch worked on sparc64 as long as the kernel > happened to leave enough room in the last 4MB page allocated > for it. > The new version unfortunately doesn't compile on sparc64 as > pmap_bootstrap_alloc() is static to its pmap.c (I think it > should also stay that way). Also the memory allocated with > it isn't safe to be used before we've taken over the trap > table. A kernel built with the sparc64 bits replaced with > the following patch boots fine: > http://people.freebsd.org/~marius/sparc64_dpcpu.diff > Do you have some simple test case for DPCPU which can be > used to verify that it actually works? I can suggest to switch pc_rm_queue of rmlocks in pcpu to be used as dynamic. It should not be difficult at all. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Mon Jun 22 00:10:00 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C068106566C; Mon, 22 Jun 2009 00:10:00 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-px0-f203.google.com (mail-px0-f203.google.com [209.85.216.203]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD248FC0C; Mon, 22 Jun 2009 00:10:00 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by mail-px0-f203.google.com with SMTP id 41so2222383pxi.3 for ; Sun, 21 Jun 2009 17:10:00 -0700 (PDT) Received: by 10.143.8.17 with SMTP id l17mr2366251wfi.173.1245629400015; Sun, 21 Jun 2009 17:10:00 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id 31sm1073183wff.24.2009.06.21.17.09.57 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Jun 2009 17:09:58 -0700 (PDT) Date: Sun, 21 Jun 2009 14:09:54 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Marius Strobl In-Reply-To: <20090621140312.GC71667@alchemy.franken.de> Message-ID: References: <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> <20090621140312.GC71667@alchemy.franken.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Peter Grehan Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 00:10:00 -0000 On Sun, 21 Jun 2009, Marius Strobl wrote: > On Wed, Jun 17, 2009 at 12:55:52PM -1000, Jeff Roberson wrote: >> >> On Tue, 9 Jun 2009, Peter Grehan wrote: >> >>>> As for sparc64 allocating the storage for the dynamic area >>>> from end probably isn't a good idea as the pmap code assumes >>>> that the range from KERNBASE to end is covered by the pages >>>> allocated by and locked into the TLB for the kernel by the >>>> loader >>> >>> Ditto for ppc. It's possible to get the additional space from within or >>> after return from pmap_bootstrap() (like thread0's kstack, or the msgbuf). >> >> http://people.freebsd.org/~jeff/dpcpu.diff >> >> I have updated this patch based on feedback relating to various >> architectures md code. I tried to model most architectures after the way >> msgbuf memory was taken. I have no capacity to test anything other than >> i386 and amd64. ARM is reported to work with one minor diff. Apparently >> sparc64 worked with the earlier diff but this should be cleaner. If >> anyone can report back on sparc64, mips, or powerpc, I'd appreciate it. >> > > The earlier patch worked on sparc64 as long as the kernel > happened to leave enough room in the last 4MB page allocated > for it. > The new version unfortunately doesn't compile on sparc64 as > pmap_bootstrap_alloc() is static to its pmap.c (I think it > should also stay that way). Also the memory allocated with > it isn't safe to be used before we've taken over the trap > table. A kernel built with the sparc64 bits replaced with > the following patch boots fine: > http://people.freebsd.org/~marius/sparc64_dpcpu.diff > Do you have some simple test case for DPCPU which can be > used to verify that it actually works? Thanks very much Marius. I have updated the patch at: http://people.freebsd.org/~jeff/dpcpu.diff I intend to commit this, minus the kern_synch.c diff tomorrow. There was an id in the previous patch that caused each area to be accessed as it was added but you'd have to have done a 'show pcpu' in ddb after boot to access the area. I added a counter in kern_synch.c as a better test. new in this diff: 1) I made each access cheaper by one instruction by making the pc_dynamic pointer relative to the start of the percpu area. 2) I added two helper functions for sysctl ints and quads that can be used for stats. See the temporary kern_synch.c diff for an example. 3) sparc64/sun4v by marius 4) ia64 fixes suggested by marcel. Thanks, Jeff > > Marius > From owner-freebsd-arch@FreeBSD.ORG Mon Jun 22 11:06:50 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0F461065673 for ; Mon, 22 Jun 2009 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B36598FC29 for ; Mon, 22 Jun 2009 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5MB6oLt017938 for ; Mon, 22 Jun 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5MB6oWt017934 for freebsd-arch@FreeBSD.org; Mon, 22 Jun 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Jun 2009 11:06:50 GMT Message-Id: <200906221106.n5MB6oWt017934@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 22 16:47:33 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D932A1065672; Mon, 22 Jun 2009 16:47:33 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 927358FC29; Mon, 22 Jun 2009 16:47:33 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n5MGZ62g014639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2009 09:35:06 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A3FB2BA.80803@freebsd.org> Date: Mon, 22 Jun 2009 09:35:06 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Jeff Roberson References: <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> <20090621140312.GC71667@alchemy.franken.de> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: arch@freebsd.org, Peter Grehan , Marius Strobl Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 16:47:34 -0000 Blows up on arm (xscale) during boot. I will try to look at why later. You might want to boot a UP kernel. Sam From owner-freebsd-arch@FreeBSD.ORG Mon Jun 22 16:47:34 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 302AC106567A; Mon, 22 Jun 2009 16:47:34 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E6F0B8FC17; Mon, 22 Jun 2009 16:47:33 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n5MGVRsR014625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2009 09:31:28 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A3FB1DF.80006@freebsd.org> Date: Mon, 22 Jun 2009 09:31:27 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Jeff Roberson References: <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> <20090621140312.GC71667@alchemy.franken.de> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: arch@freebsd.org, Peter Grehan , Marius Strobl Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 16:47:34 -0000 Jeff Roberson wrote: > On Sun, 21 Jun 2009, Marius Strobl wrote: > >> On Wed, Jun 17, 2009 at 12:55:52PM -1000, Jeff Roberson wrote: >>> >>> On Tue, 9 Jun 2009, Peter Grehan wrote: >>> >>>>> As for sparc64 allocating the storage for the dynamic area >>>>> from end probably isn't a good idea as the pmap code assumes >>>>> that the range from KERNBASE to end is covered by the pages >>>>> allocated by and locked into the TLB for the kernel by the >>>>> loader >>>> >>>> Ditto for ppc. It's possible to get the additional space from >>>> within or >>>> after return from pmap_bootstrap() (like thread0's kstack, or the >>>> msgbuf). >>> >>> http://people.freebsd.org/~jeff/dpcpu.diff >>> >>> I have updated this patch based on feedback relating to various >>> architectures md code. I tried to model most architectures after the >>> way >>> msgbuf memory was taken. I have no capacity to test anything other than >>> i386 and amd64. ARM is reported to work with one minor diff. Apparently >>> sparc64 worked with the earlier diff but this should be cleaner. If >>> anyone can report back on sparc64, mips, or powerpc, I'd appreciate it. >>> >> >> The earlier patch worked on sparc64 as long as the kernel >> happened to leave enough room in the last 4MB page allocated >> for it. >> The new version unfortunately doesn't compile on sparc64 as >> pmap_bootstrap_alloc() is static to its pmap.c (I think it >> should also stay that way). Also the memory allocated with >> it isn't safe to be used before we've taken over the trap >> table. A kernel built with the sparc64 bits replaced with >> the following patch boots fine: >> http://people.freebsd.org/~marius/sparc64_dpcpu.diff >> Do you have some simple test case for DPCPU which can be >> used to verify that it actually works? > > Thanks very much Marius. I have updated the patch at: > > http://people.freebsd.org/~jeff/dpcpu.diff > > I intend to commit this, minus the kern_synch.c diff tomorrow. There > was an id in the previous patch that caused each area to be accessed > as it was added but you'd have to have done a 'show pcpu' in ddb after > boot to access the area. I added a counter in kern_synch.c as a better > test. > > new in this diff: > > 1) I made each access cheaper by one instruction by making the > pc_dynamic pointer relative to the start of the percpu area. > > 2) I added two helper functions for sysctl ints and quads that can be > used for stats. See the temporary kern_synch.c diff for an example. > > 3) sparc64/sun4v by marius > > 4) ia64 fixes suggested by marcel. Does not compile on !SMP systems (s/dpcpu_ptr/dcpu_off/ in sysctl_dpcpu_quad). Sam From owner-freebsd-arch@FreeBSD.ORG Mon Jun 22 20:00:31 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9991065672; Mon, 22 Jun 2009 20:00:31 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-px0-f203.google.com (mail-px0-f203.google.com [209.85.216.203]) by mx1.freebsd.org (Postfix) with ESMTP id 5813F8FC30; Mon, 22 Jun 2009 20:00:31 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by pxi41 with SMTP id 41so17178pxi.3 for ; Mon, 22 Jun 2009 13:00:30 -0700 (PDT) Received: by 10.140.177.13 with SMTP id z13mr6029466rve.202.1245700830769; Mon, 22 Jun 2009 13:00:30 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id g22sm12641134rvb.35.2009.06.22.13.00.27 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Jun 2009 13:00:29 -0700 (PDT) Date: Mon, 22 Jun 2009 10:00:29 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Sam Leffler In-Reply-To: <4A3FB2BA.80803@freebsd.org> Message-ID: References: <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> <20090621140312.GC71667@alchemy.franken.de> <4A3FB2BA.80803@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Peter Grehan , Marius Strobl Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 20:00:32 -0000 On Mon, 22 Jun 2009, Sam Leffler wrote: > Blows up on arm (xscale) during boot. I will try to look at why later. You > might want to boot a UP kernel. I had before I did the pcpu_ptr change. I will again. I'm doing the module stuff now so I'll do another round of testing when that's done. Which xscale platfom? There are 5 or so. Thanks, Jeff > > Sam > From owner-freebsd-arch@FreeBSD.ORG Mon Jun 22 23:08:11 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CAFD1065678 for ; Mon, 22 Jun 2009 23:08:11 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id EACF38FC1F for ; Mon, 22 Jun 2009 23:08:10 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1MIs1a-0000t2-Tl for freebsd-arch@freebsd.org; Mon, 22 Jun 2009 22:30:02 +0000 Received: from 77-22-111-166-dynip.superkabel.de ([77.22.111.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Jun 2009 22:30:02 +0000 Received: from ino-news by 77-22-111-166-dynip.superkabel.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Jun 2009 22:30:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: freebsd-arch@freebsd.org To: freebsd-arch@freebsd.org From: clemens fischer Date: Mon, 22 Jun 2009 22:05:28 +0200 Lines: 16 Message-ID: <6p45h6xbmp.ln2@nntp.spotteswoode.dnsalias.org> References: <49D1492C.5050101@freebsd.org> <200903310620.n2V6Kudd072936@hergotha.csail.mit.edu> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 77-22-111-166-dynip.superkabel.de X-Archive: encrypt=none Mail-Copies-To: nobody User-Agent: tin/1.9.4-20090211 ("Rieclachan") (UNIX) (Linux/2.6.30-ARCH (i686)) Sender: news Subject: Re: On errno X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 23:08:11 -0000 On Tue-2009/03/31-08:20 Garrett Wollman wrote in gmane.os.freebsd.architechture (MID <200903310620.n2V6Kudd072936@hergotha.csail.mit.edu>): > [on strings accompanying errno] > > But all this is really irrelevant if no other operating system or > standard adopts the interface. Interfaces which are peculiar to > FreeBSD are rarely useful. plan9 already has that: programs return a string instead of a number. plan9port (user space implementation for unix) takes an empty string to mean SUCCESS and anything else as FAILURE. clemens From owner-freebsd-arch@FreeBSD.ORG Tue Jun 23 18:01:05 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81913106566C for ; Tue, 23 Jun 2009 18:01:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 568408FC14 for ; Tue, 23 Jun 2009 18:01:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EDF7046B45 for ; Tue, 23 Jun 2009 14:01:04 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E83CD8A085 for ; Tue, 23 Jun 2009 14:01:03 -0400 (EDT) From: John Baldwin To: arch@FreeBSD.org Date: Tue, 23 Jun 2009 13:41:42 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906231341.43104.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 23 Jun 2009 14:01:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: [PATCH] SYSV IPC ABI rototill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 18:01:05 -0000 There have been a several issues with the existing ABI of the SYSV IPC structures over the past several years and it has been on the todo list for at least both 7.0 and 8.0. Rather than putting it off until 9.0 I sat down and worked on it this week. The patch is not super complex. First, the ABI changes done to each structure: - struct ipc_perm - The uid/cuid members are now of type uid_t instead of unsigned short. - The gid/cgid members are now of type gid_t instead of unsigned short. - The mode member is now of type mode_t instead of unsigned short. This is just a comsetic tweak though on current architectures since mode_t == uint16_t. - struct msqid_ds - The various pad fields have been removed. - struct semid_ds - The various pad fields have been removed. The comments suggest that these fields were added to follow the SV/I386 ABI. However, if FreeBSD ever supports SYSV binaries, I imagine they will use a separate system call ABI. In that case there is no reason that the FreeBSD ABI needs the padding, so I have removed them. - struct shmid_ds and struct shmid_kernel - shm_segsz is now a size_t instead of an int. As a result of this fix I've retired shm_bsegsz from shmid_kernel as it is no longer needed. - shm_nattch is now an int instead of a short. The structure padding was such that the space was already there anyway. - shm_internal is gone. There is no good reason to be exposing random kernel pointers to userland. I've replaced the in-kernel use by moving the VM object pointer into a new 'object' field in shmid_kernel. As far as system calls, the only functions in the SYSV IPC API that are affected are msgctl(), semctl(), and shmctl(). As a result, I have made new versions of __semctl(), msgctl(), and shmctl() and marked the old slots as COMPAT7. However, another set of system calls provide an old interface to the SYSV IPC API: msgsys(), semsys(), and shmsys(). Rather than adding compat shims for these kludgy syscalls, I am simply deprecating them altogether and they will only exist under COMPAT7. Binaries and libraries (including libc) have not used the foosys() system calls to implement the SYSV IPC API since FreeBSD 4.x. They proved problematic on certain architectures such as sparc64, etc. Given that, I think that they can safely be relegated to the legacy bin. The patch is at http://www.FreeBSD.org/~jhb/patches/sysvipc_abi.patch -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jun 23 21:06:50 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5178A1065680 for ; Tue, 23 Jun 2009 21:06:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 23FBA8FC16 for ; Tue, 23 Jun 2009 21:06:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CE9B546B81; Tue, 23 Jun 2009 17:06:49 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id DBDE18A086; Tue, 23 Jun 2009 17:06:48 -0400 (EDT) From: John Baldwin To: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= Date: Tue, 23 Jun 2009 17:06:33 -0400 User-Agent: KMail/1.9.7 References: <200906231341.43104.jhb@freebsd.org> <863a9q3c7a.fsf@ds4.des.no> In-Reply-To: <863a9q3c7a.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906231706.33465.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 23 Jun 2009 17:06:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: arch@freebsd.org Subject: Re: [PATCH] SYSV IPC ABI rototill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 21:06:50 -0000 On Tuesday 23 June 2009 4:52:09 pm Dag-Erling Sm=C3=B8rgrav wrote: > John Baldwin writes: > > There have been a several issues with the existing ABI of the SYSV IPC= =20 > > structures over the past several years and it has been on the todo list= for=20 > > at least both 7.0 and 8.0. Rather than putting it off until 9.0 I sat = down=20 > > and worked on it this week. >=20 > Have you given any thought to virtualization, i.e. separate namespaces > for each jail? Will your patch make this any easier or harder to > implement? It likely has zero effect on that. The global variables one would need to virtualize are unchanged by this. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jun 23 21:07:55 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDF94106568D for ; Tue, 23 Jun 2009 21:07:55 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 855B78FC1B for ; Tue, 23 Jun 2009 21:07:55 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DAEE26D418; Tue, 23 Jun 2009 22:52:09 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id BB706844A1; Tue, 23 Jun 2009 22:52:09 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: John Baldwin References: <200906231341.43104.jhb@freebsd.org> Date: Tue, 23 Jun 2009 22:52:09 +0200 In-Reply-To: <200906231341.43104.jhb@freebsd.org> (John Baldwin's message of "Tue, 23 Jun 2009 13:41:42 -0400") Message-ID: <863a9q3c7a.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@FreeBSD.org Subject: Re: [PATCH] SYSV IPC ABI rototill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 21:07:56 -0000 John Baldwin writes: > There have been a several issues with the existing ABI of the SYSV IPC=20 > structures over the past several years and it has been on the todo list f= or=20 > at least both 7.0 and 8.0. Rather than putting it off until 9.0 I sat do= wn=20 > and worked on it this week. Have you given any thought to virtualization, i.e. separate namespaces for each jail? Will your patch make this any easier or harder to implement? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Jun 23 21:15:45 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A9511065670 for ; Tue, 23 Jun 2009 21:15:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 3119A8FC14 for ; Tue, 23 Jun 2009 21:15:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 9C7AD322D9; Tue, 23 Jun 2009 16:49:41 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 699002D600D; Tue, 23 Jun 2009 14:15:44 -0700 (PDT) Message-ID: <4A414600.4060008@elischer.org> Date: Tue, 23 Jun 2009 14:15:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: John Baldwin References: <200906231341.43104.jhb@freebsd.org> <863a9q3c7a.fsf@ds4.des.no> <200906231706.33465.jhb@freebsd.org> In-Reply-To: <200906231706.33465.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , arch@freebsd.org Subject: Re: [PATCH] SYSV IPC ABI rototill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 21:15:45 -0000 John Baldwin wrote: > On Tuesday 23 June 2009 4:52:09 pm Dag-Erling Smørgrav wrote: >> John Baldwin writes: >>> There have been a several issues with the existing ABI of the SYSV IPC >>> structures over the past several years and it has been on the todo list for >>> at least both 7.0 and 8.0. Rather than putting it off until 9.0 I sat down >>> and worked on it this week. >> Have you given any thought to virtualization, i.e. separate namespaces >> for each jail? Will your patch make this any easier or harder to >> implement? > > It likely has zero effect on that. The global variables one would need to > virtualize are unchanged by this. > Marko did this and it is in P4 somewhere... From owner-freebsd-arch@FreeBSD.ORG Tue Jun 23 23:23:34 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37BBC1065674; Tue, 23 Jun 2009 23:23:34 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2689E8FC0C; Tue, 23 Jun 2009 23:23:33 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E71551A3C3A; Tue, 23 Jun 2009 16:05:01 -0700 (PDT) Date: Tue, 23 Jun 2009 16:05:01 -0700 From: Alfred Perlstein To: John Baldwin Message-ID: <20090623230501.GH84786@elvis.mu.org> References: <200906231341.43104.jhb@freebsd.org> <863a9q3c7a.fsf@ds4.des.no> <200906231706.33465.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906231706.33465.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling Sm??rgrav , arch@freebsd.org Subject: Re: [PATCH] SYSV IPC ABI rototill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:23:34 -0000 * John Baldwin [090623 14:07] wrote: > On Tuesday 23 June 2009 4:52:09 pm Dag-Erling Sm??rgrav wrote: > > John Baldwin writes: > > > There have been a several issues with the existing ABI of the SYSV IPC > > > structures over the past several years and it has been on the todo list for > > > at least both 7.0 and 8.0. Rather than putting it off until 9.0 I sat down > > > and worked on it this week. > > > > Have you given any thought to virtualization, i.e. separate namespaces > > for each jail? Will your patch make this any easier or harder to > > implement? > > It likely has zero effect on that. The global variables one would need to > virtualize are unchanged by this. John, would it make sense to check for overflow in ipcperm_new2old and return some error so that callers get back some nasty error so that they don't make a mistake about permissions when an overflow happens? A crash/error sounds better than silent truncating of credential information, but I could be wrong. -Alfred From owner-freebsd-arch@FreeBSD.ORG Wed Jun 24 14:23:24 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03E5D1065760; Wed, 24 Jun 2009 14:23:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 458BD8FC24; Wed, 24 Jun 2009 14:23:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E856446B49; Wed, 24 Jun 2009 10:23:22 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id DBEE28A089; Wed, 24 Jun 2009 10:23:21 -0400 (EDT) From: John Baldwin To: Alfred Perlstein Date: Wed, 24 Jun 2009 08:33:03 -0400 User-Agent: KMail/1.9.7 References: <200906231341.43104.jhb@freebsd.org> <200906231706.33465.jhb@freebsd.org> <20090623230501.GH84786@elvis.mu.org> In-Reply-To: <20090623230501.GH84786@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906240833.04028.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 24 Jun 2009 10:23:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dag-Erling Sm??rgrav , arch@freebsd.org Subject: Re: [PATCH] SYSV IPC ABI rototill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 14:23:25 -0000 On Tuesday 23 June 2009 7:05:01 pm Alfred Perlstein wrote: > * John Baldwin [090623 14:07] wrote: > > On Tuesday 23 June 2009 4:52:09 pm Dag-Erling Sm??rgrav wrote: > > > John Baldwin writes: > > > > There have been a several issues with the existing ABI of the SYSV IPC > > > > structures over the past several years and it has been on the todo list for > > > > at least both 7.0 and 8.0. Rather than putting it off until 9.0 I sat down > > > > and worked on it this week. > > > > > > Have you given any thought to virtualization, i.e. separate namespaces > > > for each jail? Will your patch make this any easier or harder to > > > implement? > > > > It likely has zero effect on that. The global variables one would need to > > virtualize are unchanged by this. > > John, would it make sense to check for overflow in ipcperm_new2old and return > some error so that callers get back some nasty error so that they don't make > a mistake about permissions when an overflow happens? > > A crash/error sounds better than silent truncating of credential information, > but I could be wrong. Hmm, well, the truncation is what we have been doing all along for any users who used UIDs > USHRT_MAX, so adding an error now would change the behavior for existing binaries. Also, the truncation does not affect the actual permission checks (those are all done in the kernel), merely the reporting of the associated IDs to userland. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jun 24 15:32:36 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2DB810656D7; Wed, 24 Jun 2009 15:32:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A0B2F8FC15; Wed, 24 Jun 2009 15:32:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 56BE31A3C3A; Wed, 24 Jun 2009 08:32:36 -0700 (PDT) Date: Wed, 24 Jun 2009 08:32:36 -0700 From: Alfred Perlstein To: John Baldwin Message-ID: <20090624153236.GN84786@elvis.mu.org> References: <200906231341.43104.jhb@freebsd.org> <200906231706.33465.jhb@freebsd.org> <20090623230501.GH84786@elvis.mu.org> <200906240833.04028.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906240833.04028.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling Sm??rgrav , arch@freebsd.org Subject: Re: [PATCH] SYSV IPC ABI rototill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 15:32:37 -0000 * John Baldwin [090624 07:23] wrote: > On Tuesday 23 June 2009 7:05:01 pm Alfred Perlstein wrote: > > * John Baldwin [090623 14:07] wrote: > > > On Tuesday 23 June 2009 4:52:09 pm Dag-Erling Sm??rgrav wrote: > > > > John Baldwin writes: > > > > > There have been a several issues with the existing ABI of the SYSV IPC > > > > > structures over the past several years and it has been on the todo list for > > > > > at least both 7.0 and 8.0. Rather than putting it off until 9.0 I sat down > > > > > and worked on it this week. > > > > > > > > Have you given any thought to virtualization, i.e. separate namespaces > > > > for each jail? Will your patch make this any easier or harder to > > > > implement? > > > > > > It likely has zero effect on that. The global variables one would need to > > > virtualize are unchanged by this. > > > > John, would it make sense to check for overflow in ipcperm_new2old and return > > some error so that callers get back some nasty error so that they don't make > > a mistake about permissions when an overflow happens? > > > > A crash/error sounds better than silent truncating of credential information, > > but I could be wrong. > > Hmm, well, the truncation is what we have been doing all along for any users > who used UIDs > USHRT_MAX, so adding an error now would change the behavior > for existing binaries. Also, the truncation does not affect the actual > permission checks (those are all done in the kernel), merely the reporting of > the associated IDs to userland. OK, thank you for explaining. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Thu Jun 25 19:05:06 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 072561065697 for ; Thu, 25 Jun 2009 19:05:06 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id C1A6F8FC1A for ; Thu, 25 Jun 2009 19:05:05 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n5PIjCIQ024467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Jun 2009 14:45:16 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-arch@freebsd.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-X21KY1w0czHTT/BbE3za" Organization: U. Buffalo CSE Department Date: Thu, 25 Jun 2009 14:45:12 -0400 Message-Id: <1245955512.20785.14.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 Subject: Time to drop the warning for uid's bigger than USHRT_MAX? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 19:05:06 -0000 --=-X21KY1w0czHTT/BbE3za Content-Type: text/plain Content-Transfer-Encoding: quoted-printable John's work on the SYSV IPC stuff removes the last place I'm aware of that had an issue with uid's bigger than what will fit inside an unsigned short. So, a couple questions: 1) Does anyone know of any remaining places I'm not aware of? And, if the answer to that winds up being no... 2) lib/libc/gen/pw_scan.c has some support for providing warnings about there potentially being issues with using uid's larger than a certain value. Should the code for that remain in place "for the next time we have this issue" despite it not really being needed now or should it all just get ripped out? Given John's work just arrived and it was a pre-requisite to doing anything about this RE would probably allow for any changes related to this happening after code freeze starts but it should happen soon if it's going to happen at all. ;-) Personally I'm leaning towards adjusting things so the warnings get triggered at UID_MAX for now and providing a few comments that say "We know this looks unnecessary right now but there was a time when ...". Thanks... --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-X21KY1w0czHTT/BbE3za Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpDxa4ACgkQ/G14VSmup/a9UACfYmFWIs1PzVgZw4XMZLzO0SPj /BMAoJV9mVyVnUfQ/LCbyt8FVDsnuad8 =BFVt -----END PGP SIGNATURE----- --=-X21KY1w0czHTT/BbE3za-- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 26 15:58:26 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DF7A106564A for ; Fri, 26 Jun 2009 15:58:26 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 198CD8FC14 for ; Fri, 26 Jun 2009 15:58:26 +0000 (UTC) (envelope-from jilles@stack.nl) Received: by mx1.stack.nl (Postfix, from userid 65534) id 13B59375842; Fri, 26 Jun 2009 17:58:25 +0200 (CEST) X-Spam-DCC: dcc1: scanner01.stack.nl 1182; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on scanner01.stack.nl X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Relay-Country: _RELAYCOUNTRY_ Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 0376737583B; Fri, 26 Jun 2009 17:58:23 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 88B2F228CB; Fri, 26 Jun 2009 17:57:57 +0200 (CEST) Date: Fri, 26 Jun 2009 17:57:57 +0200 From: Jilles Tjoelker To: Ken Smith Message-ID: <20090626155757.GA89856@stack.nl> References: <1245955512.20785.14.camel@bauer.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1245955512.20785.14.camel@bauer.cse.buffalo.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-arch@freebsd.org Subject: Re: Time to drop the warning for uid's bigger than USHRT_MAX? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 15:58:26 -0000 On Thu, Jun 25, 2009 at 02:45:12PM -0400, Ken Smith wrote: > John's work on the SYSV IPC stuff removes the last place I'm aware of > that had an issue with uid's bigger than what will fit inside an > unsigned short. So, a couple questions: > 1) Does anyone know of any remaining places I'm not aware of? sa(8) has a problem with the uid 1380275712 (probably 5653842 on big endian systems). This is because uid_compare() in usrdb.c does not take the version key (#define VERSION_KEY "\0VERSION" in db.c) into account. -- Jilles Tjoelker