From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 04:08:48 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D97AFE31; Sun, 21 Jul 2013 04:08:48 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by mx1.freebsd.org (Postfix) with ESMTP id 92B2214D; Sun, 21 Jul 2013 04:08:48 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6L48fDi000644; Sun, 21 Jul 2013 00:08:41 -0400 (EDT) Received: from rtp-jclarke-8916.cisco.com (rtp-jclarke-8916.cisco.com [10.117.46.167]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6L48aak008654; Sun, 21 Jul 2013 00:08:37 -0400 (EDT) Message-ID: <51EB5EC4.6050802@marcuscom.com> Date: Sun, 21 Jul 2013 00:08:36 -0400 From: Joe Marcus Clarke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Koop Mast , freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 04:08:49 -0000 On 7/19/13 1:55 AM, Daniel Eischen wrote: > On Thu, 18 Jul 2013, Daniel Eischen wrote: > >> On Thu, 18 Jul 2013, Daniel Eischen wrote: >> >>> On Thu, 18 Jul 2013, Joe Marcus Clarke wrote: >>> >>>> On 7/18/13 11:09 AM, Daniel Eischen wrote: >>>>> On Wed, 17 Jul 2013, Joe Marcus Clarke wrote: >>>>> >>>>>> It seems we might have a discrepancy between the way our pthread >>>>>> implementation works compared to Linux. If a mutex is set to NORMAL >>>>>> type and one goes to unlock it, EPERM is returned unless the current >>>>>> thread is the mutex owner. While this sounds perfectly sane, it >>>>>> appears >>>>>> Linux only returns EPERM if the mutex type is ERRORCHECK. >>>>>> >>>>>> We are seeing some problems in ported code because of this. As a >>>>>> suggestion, if people agree, would it be possible to emulate the >>>>>> behavior of Linux and only return EPERM if the mutex is of type >>>>>> ERRORCHECK or RECURSVIE? >>>>> >>>>> First, any software that does that is broken. >>>>> >>>>> Second, the POSIX spec seems to imply that an error is returned >>>>> when a different thread tries to unlock an already locked mutex: >>>>> >>>>> >>>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.htm >>>>> >>>>> >>>>> >>>>> Is the mutex robust or not robust? If not robust >>>>> (PTHREAD_MUTEX_STALLED), then a PTHREAD_MUTEX_NORMAL mutex >>>>> cannot be unlocked by any other thread than the owner. >>>>> So, it would seem to be wrong to _not_ return an >>>>> error when the mutex is not unlocked after >>>>> pthread_mutex_unlock() returns. >>>>> >>>> >>>> Don't get me wrong, I agree with you. This behavior should result in >>>> EPERM. However, my comment was more on the portability side to >>>> maintain >>>> parity with Linux in order to support the 3rd party code people wanting >>>> to run on FreeBSD. We can workaround it in some cases, but I was >>>> floating up to you guys to perhaps create a broader workaround. >>> >>> If it is not a robust mutex, the behavior _is_ undefined, so I >>> think Linux is allowed to return 0 (no error), just as FreeBSD >>> is allowed to return an error. I will check Solaris 10 later >>> to see what it does. >> >> I tried Solaris 10. For an already locked PTHREAD_MUTEX_NORMAL >> mutex: > > Ugh! I misread the problem when I tried to recreate it and > test it on Solaris, so forget that last email. > > It seems Solaris behaves like Linux with PTHREAD_MUTEX_NORMAL > and _unlocking_ mutexes owned by other threads (dead or not). > Solaris only returns EPERM for PTHREAD_MUTEX_ERRORCHECK > mutexes. Given that, should we do the same? Joe > > Test program was updated: > > http://people.freebsd.org/~deischen/mutex_test.c > -- PGP Key : http://www.marcuscom.com/pgp.asc From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 07:00:01 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C7DE6726 for ; Sun, 21 Jul 2013 07:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id BACCD77F for ; Sun, 21 Jul 2013 07:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6L701j8068571 for ; Sun, 21 Jul 2013 07:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6L701xw068570; Sun, 21 Jul 2013 07:00:01 GMT (envelope-from gnats) Date: Sun, 21 Jul 2013 07:00:01 GMT Message-Id: <201307210700.r6L701xw068570@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: Konstantin Belousov Subject: Re: threads/180652: compat32 problem in clock_getcpuclockid2 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Konstantin Belousov List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 07:00:01 -0000 The following reply was made to PR threads/180652; it has been noted by GNATS. From: Konstantin Belousov To: Petr Salinger Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/180652: compat32 problem in clock_getcpuclockid2 Date: Sun, 21 Jul 2013 09:58:06 +0300 --JeoFlc3Bdq4ZaQzA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 20, 2013 at 10:08:45PM +0200, Petr Salinger wrote: > I tried. The tst-timer4.c timed out. I will look at it later. This is because SIGEV_THREAD does not work on 32bit compat. The sigev_value member of sigevent must be copied in. The patch below worked for me, look at the convert_sigevent32() for added line with sigev_value copying. diff --git a/sys/compat/freebsd32/freebsd32.h b/sys/compat/freebsd32/freebs= d32.h index a95b0e5..9b04965 100644 --- a/sys/compat/freebsd32/freebsd32.h +++ b/sys/compat/freebsd32/freebsd32.h @@ -69,6 +69,15 @@ struct timespec32 { CP((src).fld,(dst).fld,tv_nsec); \ } while (0) =20 +struct itimerspec32 { + struct timespec32 it_interval; + struct timespec32 it_value; +}; +#define ITS_CP(src, dst) do { \ + TS_CP((src), (dst), it_interval); \ + TS_CP((src), (dst), it_value); \ +} while (0) + struct rusage32 { struct timeval32 ru_utime; struct timeval32 ru_stime; diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index cfcd83b..6dcbfa6 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -2331,6 +2331,70 @@ freebsd32_clock_getres(struct thread *td, return (error); } =20 +int freebsd32_ktimer_create(struct thread *td, + struct freebsd32_ktimer_create_args *uap) +{ + struct sigevent32 ev32; + struct sigevent ev, *evp; + int error, id; + + if (uap->evp =3D=3D NULL) { + evp =3D NULL; + } else { + evp =3D &ev; + error =3D copyin(uap->evp, &ev32, sizeof(ev32)); + if (error !=3D 0) + return (error); + error =3D convert_sigevent32(&ev32, &ev); + if (error !=3D 0) + return (error); + } + error =3D kern_ktimer_create(td, uap->clock_id, &ev, &id, -1); + if (error =3D=3D 0) { + error =3D copyout(&id, uap->timerid, sizeof(int)); + if (error !=3D 0) + kern_ktimer_delete(td, id); + } + return (error); +} + +int +freebsd32_ktimer_settime(struct thread *td, + struct freebsd32_ktimer_settime_args *uap) +{ + struct itimerspec32 val32, oval32; + struct itimerspec val, oval, *ovalp; + int error; + + error =3D copyin(uap->value, &val32, sizeof(val32)); + if (error !=3D 0) + return (error); + ITS_CP(val32, val); + ovalp =3D uap->ovalue !=3D NULL ? &oval : NULL; + error =3D kern_ktimer_settime(td, uap->timerid, uap->flags, &val, ovalp); + if (error =3D=3D 0 && uap->ovalue !=3D NULL) { + ITS_CP(oval, oval32); + error =3D copyout(&oval32, uap->ovalue, sizeof(oval32)); + } + return (error); +} + +int +freebsd32_ktimer_gettime(struct thread *td, + struct freebsd32_ktimer_gettime_args *uap) +{ + struct itimerspec32 val32; + struct itimerspec val; + int error; + + error =3D kern_ktimer_gettime(td, uap->timerid, &val); + if (error =3D=3D 0) { + ITS_CP(val, val32); + error =3D copyout(&val32, uap->value, sizeof(val32)); + } + return (error); +} + int freebsd32_clock_getcpuclockid2(struct thread *td, struct freebsd32_clock_getcpuclockid2_args *uap) @@ -2410,7 +2474,7 @@ siginfo_to_siginfo32(const siginfo_t *src, struct sig= info32 *dst) dst->si_uid =3D src->si_uid; dst->si_status =3D src->si_status; dst->si_addr =3D (uintptr_t)src->si_addr; - dst->si_value.sigval_int =3D src->si_value.sival_int; + dst->si_value.sival_int =3D src->si_value.sival_int; dst->si_timerid =3D src->si_timerid; dst->si_overrun =3D src->si_overrun; } @@ -2912,3 +2976,29 @@ freebsd32_posix_fadvise(struct thread *td, return (kern_posix_fadvise(td, uap->fd, PAIR32TO64(off_t, uap->offset), PAIR32TO64(off_t, uap->len), uap->advice)); } + +int +convert_sigevent32(struct sigevent32 *sig32, struct sigevent *sig) +{ + + CP(*sig32, *sig, sigev_notify); + switch (sig->sigev_notify) { + case SIGEV_NONE: + break; + case SIGEV_THREAD_ID: + CP(*sig32, *sig, sigev_notify_thread_id); + /* FALLTHROUGH */ + case SIGEV_SIGNAL: + CP(*sig32, *sig, sigev_signo); + PTRIN_CP(*sig32, *sig, sigev_value.sival_ptr); + break; + case SIGEV_KEVENT: + CP(*sig32, *sig, sigev_notify_kqueue); + CP(*sig32, *sig, sigev_notify_kevent_flags); + PTRIN_CP(*sig32, *sig, sigev_value.sival_ptr); + break; + default: + return (EINVAL); + } + return (0); +} diff --git a/sys/compat/freebsd32/freebsd32_signal.h b/sys/compat/freebsd32= /freebsd32_signal.h index d31a8ae..18899f8 100644 --- a/sys/compat/freebsd32/freebsd32_signal.h +++ b/sys/compat/freebsd32/freebsd32_signal.h @@ -97,6 +97,8 @@ struct sigevent32 { } _sigev_un; }; =20 +struct sigevent; +int convert_sigevent32(struct sigevent32 *sig32, struct sigevent *sig); void siginfo_to_siginfo32(const siginfo_t *src, struct siginfo32 *dst); =20 #endif /* !_COMPAT_FREEBSD32_SIGNAL_H_ */ diff --git a/sys/compat/freebsd32/syscalls.master b/sys/compat/freebsd32/sy= scalls.master index 6cb649f..daee72c 100644 --- a/sys/compat/freebsd32/syscalls.master +++ b/sys/compat/freebsd32/syscalls.master @@ -441,11 +441,17 @@ const struct timespec32 *tp); } 234 AUE_NULL STD { int freebsd32_clock_getres(clockid_t clock_id, \ struct timespec32 *tp); } -235 AUE_NULL UNIMPL timer_create -236 AUE_NULL UNIMPL timer_delete -237 AUE_NULL UNIMPL timer_settime -238 AUE_NULL UNIMPL timer_gettime -239 AUE_NULL UNIMPL timer_getoverrun +235 AUE_NULL STD { int freebsd32_ktimer_create(\ + clockid_t clock_id, \ + struct sigevent32 *evp, int *timerid); } +236 AUE_NULL NOPROTO { int ktimer_delete(int timerid); } +237 AUE_NULL STD { int freebsd32_ktimer_settime(int timerid,\ + int flags, \ + const struct itimerspec32 *value, \ + struct itimerspec32 *ovalue); } +238 AUE_NULL STD { int freebsd32_ktimer_gettime(int timerid,\ + struct itimerspec32 *value); } +239 AUE_NULL NOPROTO { int ktimer_getoverrun(int timerid); } 240 AUE_NULL STD { int freebsd32_nanosleep( \ const struct timespec32 *rqtp, \ struct timespec32 *rmtp); } @@ -476,7 +482,7 @@ struct aiocb32 *aiocbp); } 257 AUE_NULL NOSTD { int freebsd32_lio_listio(int mode, \ struct aiocb32 * const *acb_list, \ - int nent, struct sigevent *sig); } + int nent, struct sigevent32 *sig); } 258 AUE_NULL UNIMPL nosys 259 AUE_NULL UNIMPL nosys 260 AUE_NULL UNIMPL nosys @@ -825,8 +831,8 @@ const char *msg_ptr, size_t msg_len,\ unsigned msg_prio, \ const struct timespec32 *abs_timeout);} -461 AUE_NULL NOPROTO|NOSTD { int kmq_notify(int mqd, \ - const struct sigevent *sigev); } +461 AUE_NULL NOSTD { int freebsd32_kmq_notify(int mqd, \ + const struct sigevent32 *sigev); } 462 AUE_NULL NOPROTO|NOSTD { int kmq_unlink(const char *path); } 463 AUE_NULL NOPROTO { int abort2(const char *why, int nargs, void **args)= ; } 464 AUE_NULL NOPROTO { int thr_set_name(long id, const char *name); } diff --git a/sys/kern/kern_time.c b/sys/kern/kern_time.c index 6b908a0..415188c 100644 --- a/sys/kern/kern_time.c +++ b/sys/kern/kern_time.c @@ -98,9 +98,6 @@ static int realtimer_settime(struct itimer *, int, static int realtimer_delete(struct itimer *); static void realtimer_clocktime(clockid_t, struct timespec *); static void realtimer_expire(void *); -static int kern_timer_create(struct thread *, clockid_t, - struct sigevent *, int *, int); -static int kern_timer_delete(struct thread *, int); =20 int register_posix_clock(int, struct kclock *); void itimer_fire(struct itimer *it); @@ -1078,20 +1075,18 @@ sys_ktimer_create(struct thread *td, struct ktimer_= create_args *uap) evp1 =3D &ev; } else evp1 =3D NULL; - - error =3D kern_timer_create(td, uap->clock_id, evp1, &id, -1); - + error =3D kern_ktimer_create(td, uap->clock_id, evp1, &id, -1); if (error =3D=3D 0) { error =3D copyout(&id, uap->timerid, sizeof(int)); if (error !=3D 0) - kern_timer_delete(td, id); + kern_ktimer_delete(td, id); } return (error); } =20 -static int -kern_timer_create(struct thread *td, clockid_t clock_id, - struct sigevent *evp, int *timerid, int preset_id) +int +kern_ktimer_create(struct thread *td, clockid_t clock_id, struct sigevent = *evp, + int *timerid, int preset_id) { struct proc *p =3D td->td_proc; struct itimer *it; @@ -1206,7 +1201,8 @@ struct ktimer_delete_args { int sys_ktimer_delete(struct thread *td, struct ktimer_delete_args *uap) { - return (kern_timer_delete(td, uap->timerid)); + + return (kern_ktimer_delete(td, uap->timerid)); } =20 static struct itimer * @@ -1228,8 +1224,8 @@ itimer_find(struct proc *p, int timerid) return (it); } =20 -static int -kern_timer_delete(struct thread *td, int timerid) +int +kern_ktimer_delete(struct thread *td, int timerid) { struct proc *p =3D td->td_proc; struct itimer *it; @@ -1271,35 +1267,40 @@ struct ktimer_settime_args { int sys_ktimer_settime(struct thread *td, struct ktimer_settime_args *uap) { - struct proc *p =3D td->td_proc; - struct itimer *it; struct itimerspec val, oval, *ovalp; int error; =20 error =3D copyin(uap->value, &val, sizeof(val)); if (error !=3D 0) return (error); -=09 - if (uap->ovalue !=3D NULL) - ovalp =3D &oval; - else - ovalp =3D NULL; + ovalp =3D uap->ovalue !=3D NULL ? &oval : NULL; + error =3D kern_ktimer_settime(td, uap->timerid, uap->flags, &val, ovalp); + if (error =3D=3D 0 && uap->ovalue !=3D NULL) + error =3D copyout(ovalp, uap->ovalue, sizeof(*ovalp)); + return (error); +} =20 +int +kern_ktimer_settime(struct thread *td, int timer_id, int flags, + struct itimerspec *val, struct itimerspec *oval) +{ + struct proc *p; + struct itimer *it; + int error; + + p =3D td->td_proc; PROC_LOCK(p); - if (uap->timerid < 3 || - (it =3D itimer_find(p, uap->timerid)) =3D=3D NULL) { + if (timer_id < 3 || (it =3D itimer_find(p, timer_id)) =3D=3D NULL) { PROC_UNLOCK(p); error =3D EINVAL; } else { PROC_UNLOCK(p); itimer_enter(it); - error =3D CLOCK_CALL(it->it_clockid, timer_settime, - (it, uap->flags, &val, ovalp)); + error =3D CLOCK_CALL(it->it_clockid, timer_settime, (it, + flags, val, oval)); itimer_leave(it); ITIMER_UNLOCK(it); } - if (error =3D=3D 0 && uap->ovalue !=3D NULL) - error =3D copyout(ovalp, uap->ovalue, sizeof(*ovalp)); return (error); } =20 @@ -1312,26 +1313,34 @@ struct ktimer_gettime_args { int sys_ktimer_gettime(struct thread *td, struct ktimer_gettime_args *uap) { - struct proc *p =3D td->td_proc; - struct itimer *it; struct itimerspec val; int error; =20 + error =3D kern_ktimer_gettime(td, uap->timerid, &val); + if (error =3D=3D 0) + error =3D copyout(&val, uap->value, sizeof(val)); + return (error); +} + +int +kern_ktimer_gettime(struct thread *td, int timer_id, struct itimerspec *va= l) +{ + struct proc *p; + struct itimer *it; + int error; + + p =3D td->td_proc; PROC_LOCK(p); - if (uap->timerid < 3 || - (it =3D itimer_find(p, uap->timerid)) =3D=3D NULL) { + if (timer_id < 3 || (it =3D itimer_find(p, timer_id)) =3D=3D NULL) { PROC_UNLOCK(p); error =3D EINVAL; } else { PROC_UNLOCK(p); itimer_enter(it); - error =3D CLOCK_CALL(it->it_clockid, timer_gettime, - (it, &val)); + error =3D CLOCK_CALL(it->it_clockid, timer_gettime, (it, val)); itimer_leave(it); ITIMER_UNLOCK(it); } - if (error =3D=3D 0) - error =3D copyout(&val, uap->value, sizeof(val)); return (error); } =20 @@ -1626,7 +1635,7 @@ itimers_event_hook_exit(void *arg, struct proc *p) panic("unhandled event"); for (; i < TIMER_MAX; ++i) { if ((it =3D its->its_timers[i]) !=3D NULL) - kern_timer_delete(curthread, i); + kern_ktimer_delete(curthread, i); } if (its->its_timers[0] =3D=3D NULL && its->its_timers[1] =3D=3D NULL && diff --git a/sys/kern/uipc_mqueue.c b/sys/kern/uipc_mqueue.c index 73579d3..ae3f1a6 100644 --- a/sys/kern/uipc_mqueue.c +++ b/sys/kern/uipc_mqueue.c @@ -2235,10 +2235,9 @@ sys_kmq_timedsend(struct thread *td, struct kmq_time= dsend_args *uap) return (error); } =20 -int -sys_kmq_notify(struct thread *td, struct kmq_notify_args *uap) +static int +kern_kmq_notify(struct thread *td, int mqd, struct sigevent *sigev) { - struct sigevent ev; struct filedesc *fdp; struct proc *p; struct mqueue *mq; @@ -2246,34 +2245,31 @@ sys_kmq_notify(struct thread *td, struct kmq_notify= _args *uap) struct mqueue_notifier *nt, *newnt =3D NULL; int error; =20 - p =3D td->td_proc; - fdp =3D td->td_proc->p_fd; - if (uap->sigev) { - error =3D copyin(uap->sigev, &ev, sizeof(ev)); - if (error) - return (error); - if (ev.sigev_notify !=3D SIGEV_SIGNAL && - ev.sigev_notify !=3D SIGEV_THREAD_ID && - ev.sigev_notify !=3D SIGEV_NONE) + if (sigev !=3D NULL) { + if (sigev->sigev_notify !=3D SIGEV_SIGNAL && + sigev->sigev_notify !=3D SIGEV_THREAD_ID && + sigev->sigev_notify !=3D SIGEV_NONE) return (EINVAL); - if ((ev.sigev_notify =3D=3D SIGEV_SIGNAL || - ev.sigev_notify =3D=3D SIGEV_THREAD_ID) && - !_SIG_VALID(ev.sigev_signo)) + if ((sigev->sigev_notify =3D=3D SIGEV_SIGNAL || + sigev->sigev_notify =3D=3D SIGEV_THREAD_ID) && + !_SIG_VALID(sigev->sigev_signo)) return (EINVAL); } - error =3D getmq(td, uap->mqd, &fp, NULL, &mq); + p =3D td->td_proc; + fdp =3D td->td_proc->p_fd; + error =3D getmq(td, mqd, &fp, NULL, &mq); if (error) return (error); again: FILEDESC_SLOCK(fdp); - fp2 =3D fget_locked(fdp, uap->mqd); + fp2 =3D fget_locked(fdp, mqd); if (fp2 =3D=3D NULL) { FILEDESC_SUNLOCK(fdp); error =3D EBADF; goto out; } #ifdef CAPABILITIES - error =3D cap_check(cap_rights(fdp, uap->mqd), CAP_POLL_EVENT); + error =3D cap_check(cap_rights(fdp, mqd), CAP_POLL_EVENT); if (error) { FILEDESC_SUNLOCK(fdp); goto out; @@ -2286,12 +2282,12 @@ again: } mtx_lock(&mq->mq_mutex); FILEDESC_SUNLOCK(fdp); - if (uap->sigev !=3D NULL) { + if (sigev !=3D NULL) { if (mq->mq_notifier !=3D NULL) { error =3D EBUSY; } else { PROC_LOCK(p); - nt =3D notifier_search(p, uap->mqd); + nt =3D notifier_search(p, mqd); if (nt =3D=3D NULL) { if (newnt =3D=3D NULL) { PROC_UNLOCK(p); @@ -2314,10 +2310,10 @@ again: nt->nt_ksi.ksi_flags |=3D KSI_INS | KSI_EXT; nt->nt_ksi.ksi_code =3D SI_MESGQ; nt->nt_proc =3D p; - nt->nt_ksi.ksi_mqd =3D uap->mqd; + nt->nt_ksi.ksi_mqd =3D mqd; notifier_insert(p, nt); } - nt->nt_sigev =3D ev; + nt->nt_sigev =3D *sigev; mq->mq_notifier =3D nt; PROC_UNLOCK(p); /* @@ -2330,7 +2326,7 @@ again: mqueue_send_notification(mq); } } else { - notifier_remove(p, mq, uap->mqd); + notifier_remove(p, mq, mqd); } mtx_unlock(&mq->mq_mutex); =20 @@ -2341,6 +2337,20 @@ out: return (error); } =20 +int +sys_kmq_notify(struct thread *td, struct kmq_notify_args *uap) +{ + struct sigevent ev; + int error; + + if (uap->sigev !=3D NULL) { + error =3D copyin(uap->sigev, &ev, sizeof(ev)); + if (error !=3D 0) + return (error); + } + return (kern_kmq_notify(td, uap->mqd, &ev)); +} + static void mqueue_fdclose(struct thread *td, int fd, struct file *fp) { @@ -2637,6 +2647,7 @@ static struct syscall_helper_data mq_syscalls[] =3D { #ifdef COMPAT_FREEBSD32 #include #include +#include #include #include =20 @@ -2763,12 +2774,30 @@ freebsd32_kmq_timedreceive(struct thread *td, return (error); } =20 +int +freebsd32_kmq_notify(struct thread *td, struct freebsd32_kmq_notify_args *= uap) +{ + struct sigevent ev; + struct sigevent32 ev32; + int error; + + if (uap->sigev !=3D NULL) { + error =3D copyin(uap->sigev, &ev32, sizeof(ev32)); + if (error !=3D 0) + return (error); + error =3D convert_sigevent32(&ev32, &ev); + if (error !=3D 0) + return (error); + } + return (kern_kmq_notify(td, uap->mqd, &ev)); +} + static struct syscall_helper_data mq32_syscalls[] =3D { SYSCALL32_INIT_HELPER(freebsd32_kmq_open), SYSCALL32_INIT_HELPER(freebsd32_kmq_setattr), SYSCALL32_INIT_HELPER(freebsd32_kmq_timedsend), SYSCALL32_INIT_HELPER(freebsd32_kmq_timedreceive), - SYSCALL32_INIT_HELPER_COMPAT(kmq_notify), + SYSCALL32_INIT_HELPER(freebsd32_kmq_notify), SYSCALL32_INIT_HELPER_COMPAT(kmq_unlink), SYSCALL_INIT_LAST }; diff --git a/sys/kern/vfs_aio.c b/sys/kern/vfs_aio.c index 5fb9341..862443c 100644 --- a/sys/kern/vfs_aio.c +++ b/sys/kern/vfs_aio.c @@ -2755,31 +2755,6 @@ aiocb32_copyin_old_sigevent(struct aiocb *ujob, stru= ct aiocb *kjob) } =20 static int -convert_sigevent32(struct sigevent32 *sig32, struct sigevent *sig) -{ - - CP(*sig32, *sig, sigev_notify); - switch (sig->sigev_notify) { - case SIGEV_NONE: - break; - case SIGEV_THREAD_ID: - CP(*sig32, *sig, sigev_notify_thread_id); - /* FALLTHROUGH */ - case SIGEV_SIGNAL: - CP(*sig32, *sig, sigev_signo); - break; - case SIGEV_KEVENT: - CP(*sig32, *sig, sigev_notify_kqueue); - CP(*sig32, *sig, sigev_notify_kevent_flags); - PTRIN_CP(*sig32, *sig, sigev_value.sival_ptr); - break; - default: - return (EINVAL); - } - return (0); -} - -static int aiocb32_copyin(struct aiocb *ujob, struct aiocb *kjob) { struct aiocb32 job32; diff --git a/sys/sys/syscallsubr.h b/sys/sys/syscallsubr.h index 75278c3..e18c735 100644 --- a/sys/sys/syscallsubr.h +++ b/sys/sys/syscallsubr.h @@ -228,6 +228,13 @@ int kern_symlink(struct thread *td, char *path, char *= link, enum uio_seg segflg); int kern_symlinkat(struct thread *td, char *path1, int fd, char *path2, enum uio_seg segflg); +int kern_ktimer_create(struct thread *td, clockid_t clock_id, + struct sigevent *evp, int *timerid, int preset_id); +int kern_ktimer_delete(struct thread *, int); +int kern_ktimer_settime(struct thread *td, int timer_id, int flags, + struct itimerspec *val, struct itimerspec *oval); +int kern_ktimer_gettime(struct thread *td, int timer_id, + struct itimerspec *val); int kern_thr_new(struct thread *td, struct thr_param *param); int kern_thr_suspend(struct thread *td, struct timespec *tsp); int kern_truncate(struct thread *td, char *path, enum uio_seg pathseg, --JeoFlc3Bdq4ZaQzA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR64Z+AAoJEJDCuSvBvK1B04wP/2SH4+CBWqnlYQZGpRBr6v+t VgMV1pszYBMJ7LBqsXO2ZS6EXrKHUyQ97zQGVJFl+I+CgLWT88H/JaCkFAH091qA oB5s1Nu9d5Djp+PvP/i6xZOJA29agoKDe2qDQHyPkHR7s/CGBFb7sY9M+WpyC7lX Fxyuu+CTIi4wbvoBJI1xBHvAm5rEpMEdeq2CsPnI4lJX6g8Xzcy9ypCOporB7lHa kOTFB0e0WcVJGA3k3G+GpslyAs/Cks08fyaMLU6Va01ygkNzUF0yBfLcfg7h5E+q y9hqEqqa7DCAtKT+4NN6Mm3QB5OUZVQOFaRKUOgJOCzZYnkN1rMht9hcIqm7Ov5Y 59jvFVARzF7lvLRNpUG3AFlpgZ5DbOIIBXiptWqzWblvLrJ8uHcBkorRCD6vcCo3 A2aJFBWv5VErd4GYXN7cDAaRzyHoEygaeqZsd/FJsh1dp8G5OYB1hwexVCUOhFSK a3tuV85vVS2Y636eDF8IVXXJqbyp6dO1DJxsOVETkWuyvIjGP1tfNOvdPwfJG+LC PH6B8lL94sbAtf0mwDA8QzD3KEVSe1TvPX4jVqLgyeybZnT56idUeDmSaoYWnryJ 2FS9IanIUd5U+jbYKWcewZ4uYTMpvWjmb60J1yJNPKgZZNsQTv9jW6IK6RLT/53k 4w7GmjrbgHy8QEVDyptR =iYX1 -----END PGP SIGNATURE----- --JeoFlc3Bdq4ZaQzA-- From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 08:30:02 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 91155C20 for ; Sun, 21 Jul 2013 08:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 83F46BD7 for ; Sun, 21 Jul 2013 08:30:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6L8U2Ag097538 for ; Sun, 21 Jul 2013 08:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6L8U27O097537; Sun, 21 Jul 2013 08:30:02 GMT (envelope-from gnats) Date: Sun, 21 Jul 2013 08:30:02 GMT Message-Id: <201307210830.r6L8U27O097537@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: Petr Salinger Subject: Re: threads/180652: compat32 problem in clock_getcpuclockid2 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Petr Salinger List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 08:30:02 -0000 The following reply was made to PR threads/180652; it has been noted by GNATS. From: Petr Salinger To: Konstantin Belousov Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/180652: compat32 problem in clock_getcpuclockid2 Date: Sun, 21 Jul 2013 10:23:54 +0200 (CEST) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1230774450-1374395034=:23067 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> I only tested with adapted tst-timer2.c. I hope you would do the rest. > I tried. The tst-timer4.c timed out. I will look at it later. There have been two problems: a) sigev_value.sival_ptr have not been copied b) the code misshandles timer_create() with NULL struct sigevent With attached patch, it passes our tests. I think, that there is a similar bug in both new freebsd32_kmq_notify() and sys_kmq_notify(). They do not handle NULL in struct sigevent, it might suffice to - return (kern_kmq_notify(td, uap->mqd, &ev)); + return (kern_kmq_notify(td, uap->mqd, uap->sigev == NULL ? NULL : &ev)); But this seems not be covered by our testsuite. Petr --8323328-1230774450-1374395034=:23067 Content-Type: TEXT/plain; name=kt2.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=kt2.diff ZGlmZiAtLWdpdCBhL3N5cy9jb21wYXQvZnJlZWJzZDMyL2ZyZWVic2QzMi5o IGIvc3lzL2NvbXBhdC9mcmVlYnNkMzIvZnJlZWJzZDMyLmgNCmluZGV4IGE5 NWIwZTUuLjliMDQ5NjUgMTAwNjQ0DQotLS0gYS9zeXMvY29tcGF0L2ZyZWVi c2QzMi9mcmVlYnNkMzIuaA0KKysrIGIvc3lzL2NvbXBhdC9mcmVlYnNkMzIv ZnJlZWJzZDMyLmgNCkBAIC02OSw2ICs2OSwxNSBAQCBzdHJ1Y3QgdGltZXNw ZWMzMiB7DQogCUNQKChzcmMpLmZsZCwoZHN0KS5mbGQsdHZfbnNlYyk7CVwN CiB9IHdoaWxlICgwKQ0KIA0KK3N0cnVjdCBpdGltZXJzcGVjMzIgew0KKwlz dHJ1Y3QgdGltZXNwZWMzMiAgaXRfaW50ZXJ2YWw7DQorCXN0cnVjdCB0aW1l c3BlYzMyICBpdF92YWx1ZTsNCit9Ow0KKyNkZWZpbmUgSVRTX0NQKHNyYywg ZHN0KSBkbyB7CQkJXA0KKwlUU19DUCgoc3JjKSwgKGRzdCksIGl0X2ludGVy dmFsKTsJXA0KKwlUU19DUCgoc3JjKSwgKGRzdCksIGl0X3ZhbHVlKTsJCVwN Cit9IHdoaWxlICgwKQ0KKw0KIHN0cnVjdCBydXNhZ2UzMiB7DQogCXN0cnVj dCB0aW1ldmFsMzIgcnVfdXRpbWU7DQogCXN0cnVjdCB0aW1ldmFsMzIgcnVf c3RpbWU7DQpkaWZmIC0tZ2l0IGEvc3lzL2NvbXBhdC9mcmVlYnNkMzIvZnJl ZWJzZDMyX21pc2MuYyBiL3N5cy9jb21wYXQvZnJlZWJzZDMyL2ZyZWVic2Qz Ml9taXNjLmMNCmluZGV4IGNmY2Q4M2IuLjNkODQ5NDEgMTAwNjQ0DQotLS0g YS9zeXMvY29tcGF0L2ZyZWVic2QzMi9mcmVlYnNkMzJfbWlzYy5jDQorKysg Yi9zeXMvY29tcGF0L2ZyZWVic2QzMi9mcmVlYnNkMzJfbWlzYy5jDQpAQCAt MjMzMSw2ICsyMzMxLDcwIEBAIGZyZWVic2QzMl9jbG9ja19nZXRyZXMoc3Ry dWN0IHRocmVhZCAqdGQsDQogCXJldHVybiAoZXJyb3IpOw0KIH0NCiANCitp bnQgZnJlZWJzZDMyX2t0aW1lcl9jcmVhdGUoc3RydWN0IHRocmVhZCAqdGQs DQorICAgIHN0cnVjdCBmcmVlYnNkMzJfa3RpbWVyX2NyZWF0ZV9hcmdzICp1 YXApDQorew0KKwlzdHJ1Y3Qgc2lnZXZlbnQzMiBldjMyOw0KKwlzdHJ1Y3Qg c2lnZXZlbnQgZXYsICpldnA7DQorCWludCBlcnJvciwgaWQ7DQorDQorCWlm ICh1YXAtPmV2cCA9PSBOVUxMKSB7DQorCQlldnAgPSBOVUxMOw0KKwl9IGVs c2Ugew0KKwkJZXZwID0gJmV2Ow0KKwkJZXJyb3IgPSBjb3B5aW4odWFwLT5l dnAsICZldjMyLCBzaXplb2YoZXYzMikpOw0KKwkJaWYgKGVycm9yICE9IDAp DQorCQkJcmV0dXJuIChlcnJvcik7DQorCQllcnJvciA9IGNvbnZlcnRfc2ln ZXZlbnQzMigmZXYzMiwgJmV2KTsNCisJCWlmIChlcnJvciAhPSAwKQ0KKwkJ CXJldHVybiAoZXJyb3IpOw0KKwl9DQorCWVycm9yID0ga2Vybl9rdGltZXJf Y3JlYXRlKHRkLCB1YXAtPmNsb2NrX2lkLCBldnAsICZpZCwgLTEpOw0KKwlp ZiAoZXJyb3IgPT0gMCkgew0KKwkJZXJyb3IgPSBjb3B5b3V0KCZpZCwgdWFw LT50aW1lcmlkLCBzaXplb2YoaW50KSk7DQorCQlpZiAoZXJyb3IgIT0gMCkN CisJCQlrZXJuX2t0aW1lcl9kZWxldGUodGQsIGlkKTsNCisJfQ0KKwlyZXR1 cm4gKGVycm9yKTsNCit9DQorDQoraW50DQorZnJlZWJzZDMyX2t0aW1lcl9z ZXR0aW1lKHN0cnVjdCB0aHJlYWQgKnRkLA0KKyAgICBzdHJ1Y3QgZnJlZWJz ZDMyX2t0aW1lcl9zZXR0aW1lX2FyZ3MgKnVhcCkNCit7DQorCXN0cnVjdCBp dGltZXJzcGVjMzIgdmFsMzIsIG92YWwzMjsNCisJc3RydWN0IGl0aW1lcnNw ZWMgdmFsLCBvdmFsLCAqb3ZhbHA7DQorCWludCBlcnJvcjsNCisNCisJZXJy b3IgPSBjb3B5aW4odWFwLT52YWx1ZSwgJnZhbDMyLCBzaXplb2YodmFsMzIp KTsNCisJaWYgKGVycm9yICE9IDApDQorCQlyZXR1cm4gKGVycm9yKTsNCisJ SVRTX0NQKHZhbDMyLCB2YWwpOw0KKwlvdmFscCA9IHVhcC0+b3ZhbHVlICE9 IE5VTEwgPyAmb3ZhbCA6IE5VTEw7DQorCWVycm9yID0ga2Vybl9rdGltZXJf c2V0dGltZSh0ZCwgdWFwLT50aW1lcmlkLCB1YXAtPmZsYWdzLCAmdmFsLCBv dmFscCk7DQorCWlmIChlcnJvciA9PSAwICYmIHVhcC0+b3ZhbHVlICE9IE5V TEwpIHsNCisJCUlUU19DUChvdmFsLCBvdmFsMzIpOw0KKwkJZXJyb3IgPSBj b3B5b3V0KCZvdmFsMzIsIHVhcC0+b3ZhbHVlLCBzaXplb2Yob3ZhbDMyKSk7 DQorCX0NCisJcmV0dXJuIChlcnJvcik7DQorfQ0KKw0KK2ludA0KK2ZyZWVi c2QzMl9rdGltZXJfZ2V0dGltZShzdHJ1Y3QgdGhyZWFkICp0ZCwNCisgICAg c3RydWN0IGZyZWVic2QzMl9rdGltZXJfZ2V0dGltZV9hcmdzICp1YXApDQor ew0KKwlzdHJ1Y3QgaXRpbWVyc3BlYzMyIHZhbDMyOw0KKwlzdHJ1Y3QgaXRp bWVyc3BlYyB2YWw7DQorCWludCBlcnJvcjsNCisNCisJZXJyb3IgPSBrZXJu X2t0aW1lcl9nZXR0aW1lKHRkLCB1YXAtPnRpbWVyaWQsICZ2YWwpOw0KKwlp ZiAoZXJyb3IgPT0gMCkgew0KKwkJSVRTX0NQKHZhbCwgdmFsMzIpOw0KKwkJ ZXJyb3IgPSBjb3B5b3V0KCZ2YWwzMiwgdWFwLT52YWx1ZSwgc2l6ZW9mKHZh bDMyKSk7DQorCX0NCisJcmV0dXJuIChlcnJvcik7DQorfQ0KKw0KIGludA0K IGZyZWVic2QzMl9jbG9ja19nZXRjcHVjbG9ja2lkMihzdHJ1Y3QgdGhyZWFk ICp0ZCwNCiAgICAgc3RydWN0IGZyZWVic2QzMl9jbG9ja19nZXRjcHVjbG9j a2lkMl9hcmdzICp1YXApDQpAQCAtMjkxMiwzICsyOTc2LDI5IEBAIGZyZWVi c2QzMl9wb3NpeF9mYWR2aXNlKHN0cnVjdCB0aHJlYWQgKnRkLA0KIAlyZXR1 cm4gKGtlcm5fcG9zaXhfZmFkdmlzZSh0ZCwgdWFwLT5mZCwgUEFJUjMyVE82 NChvZmZfdCwgdWFwLT5vZmZzZXQpLA0KIAkgICAgUEFJUjMyVE82NChvZmZf dCwgdWFwLT5sZW4pLCB1YXAtPmFkdmljZSkpOw0KIH0NCisNCitpbnQNCitj b252ZXJ0X3NpZ2V2ZW50MzIoc3RydWN0IHNpZ2V2ZW50MzIgKnNpZzMyLCBz dHJ1Y3Qgc2lnZXZlbnQgKnNpZykNCit7DQorDQorCUNQKCpzaWczMiwgKnNp Zywgc2lnZXZfbm90aWZ5KTsNCisJc3dpdGNoIChzaWctPnNpZ2V2X25vdGlm eSkgew0KKwljYXNlIFNJR0VWX05PTkU6DQorCQlicmVhazsNCisJY2FzZSBT SUdFVl9USFJFQURfSUQ6DQorCQlDUCgqc2lnMzIsICpzaWcsIHNpZ2V2X25v dGlmeV90aHJlYWRfaWQpOw0KKwkJLyogRkFMTFRIUk9VR0ggKi8NCisJY2Fz ZSBTSUdFVl9TSUdOQUw6DQorCQlDUCgqc2lnMzIsICpzaWcsIHNpZ2V2X3Np Z25vKTsNCisJCVBUUklOX0NQKCpzaWczMiwgKnNpZywgc2lnZXZfdmFsdWUu c2l2YWxfcHRyKTsNCisJCWJyZWFrOw0KKwljYXNlIFNJR0VWX0tFVkVOVDoN CisJCUNQKCpzaWczMiwgKnNpZywgc2lnZXZfbm90aWZ5X2txdWV1ZSk7DQor CQlDUCgqc2lnMzIsICpzaWcsIHNpZ2V2X25vdGlmeV9rZXZlbnRfZmxhZ3Mp Ow0KKwkJUFRSSU5fQ1AoKnNpZzMyLCAqc2lnLCBzaWdldl92YWx1ZS5zaXZh bF9wdHIpOw0KKwkJYnJlYWs7DQorCWRlZmF1bHQ6DQorCQlyZXR1cm4gKEVJ TlZBTCk7DQorCX0NCisJcmV0dXJuICgwKTsNCit9DQpkaWZmIC0tZ2l0IGEv c3lzL2NvbXBhdC9mcmVlYnNkMzIvZnJlZWJzZDMyX3NpZ25hbC5oIGIvc3lz L2NvbXBhdC9mcmVlYnNkMzIvZnJlZWJzZDMyX3NpZ25hbC5oDQppbmRleCBk MzFhOGFlLi4xODg5OWY4IDEwMDY0NA0KLS0tIGEvc3lzL2NvbXBhdC9mcmVl YnNkMzIvZnJlZWJzZDMyX3NpZ25hbC5oDQorKysgYi9zeXMvY29tcGF0L2Zy ZWVic2QzMi9mcmVlYnNkMzJfc2lnbmFsLmgNCkBAIC05Nyw2ICs5Nyw4IEBA IHN0cnVjdCBzaWdldmVudDMyIHsNCiAJfSBfc2lnZXZfdW47DQogfTsNCiAN CitzdHJ1Y3Qgc2lnZXZlbnQ7DQoraW50IGNvbnZlcnRfc2lnZXZlbnQzMihz dHJ1Y3Qgc2lnZXZlbnQzMiAqc2lnMzIsIHN0cnVjdCBzaWdldmVudCAqc2ln KTsNCiB2b2lkIHNpZ2luZm9fdG9fc2lnaW5mbzMyKGNvbnN0IHNpZ2luZm9f dCAqc3JjLCBzdHJ1Y3Qgc2lnaW5mbzMyICpkc3QpOw0KIA0KICNlbmRpZiAv KiAhX0NPTVBBVF9GUkVFQlNEMzJfU0lHTkFMX0hfICovDQpkaWZmIC0tZ2l0 IGEvc3lzL2NvbXBhdC9mcmVlYnNkMzIvc3lzY2FsbHMubWFzdGVyIGIvc3lz L2NvbXBhdC9mcmVlYnNkMzIvc3lzY2FsbHMubWFzdGVyDQppbmRleCA2Y2I2 NDlmLi5kYWVlNzJjIDEwMDY0NA0KLS0tIGEvc3lzL2NvbXBhdC9mcmVlYnNk MzIvc3lzY2FsbHMubWFzdGVyDQorKysgYi9zeXMvY29tcGF0L2ZyZWVic2Qz Mi9zeXNjYWxscy5tYXN0ZXINCkBAIC00NDEsMTEgKzQ0MSwxNyBAQA0KIAkJ CQkgICAgY29uc3Qgc3RydWN0IHRpbWVzcGVjMzIgKnRwKTsgfQ0KIDIzNAlB VUVfTlVMTAlTVEQJeyBpbnQgZnJlZWJzZDMyX2Nsb2NrX2dldHJlcyhjbG9j a2lkX3QgY2xvY2tfaWQsIFwNCiAJCQkJICAgIHN0cnVjdCB0aW1lc3BlYzMy ICp0cCk7IH0NCi0yMzUJQVVFX05VTEwJVU5JTVBMCXRpbWVyX2NyZWF0ZQ0K LTIzNglBVUVfTlVMTAlVTklNUEwJdGltZXJfZGVsZXRlDQotMjM3CUFVRV9O VUxMCVVOSU1QTAl0aW1lcl9zZXR0aW1lDQotMjM4CUFVRV9OVUxMCVVOSU1Q TAl0aW1lcl9nZXR0aW1lDQotMjM5CUFVRV9OVUxMCVVOSU1QTAl0aW1lcl9n ZXRvdmVycnVuDQorMjM1CUFVRV9OVUxMCVNURAl7IGludCBmcmVlYnNkMzJf a3RpbWVyX2NyZWF0ZShcDQorCQkJCSAgICBjbG9ja2lkX3QgY2xvY2tfaWQs IFwNCisJCQkJICAgIHN0cnVjdCBzaWdldmVudDMyICpldnAsIGludCAqdGlt ZXJpZCk7IH0NCisyMzYJQVVFX05VTEwJTk9QUk9UTwl7IGludCBrdGltZXJf ZGVsZXRlKGludCB0aW1lcmlkKTsgfQ0KKzIzNwlBVUVfTlVMTAlTVEQJeyBp bnQgZnJlZWJzZDMyX2t0aW1lcl9zZXR0aW1lKGludCB0aW1lcmlkLFwNCisJ CQkJICAgIGludCBmbGFncywgXA0KKwkJCQkgICAgY29uc3Qgc3RydWN0IGl0 aW1lcnNwZWMzMiAqdmFsdWUsIFwNCisJCQkJICAgIHN0cnVjdCBpdGltZXJz cGVjMzIgKm92YWx1ZSk7IH0NCisyMzgJQVVFX05VTEwJU1RECXsgaW50IGZy ZWVic2QzMl9rdGltZXJfZ2V0dGltZShpbnQgdGltZXJpZCxcDQorCQkJCSAg ICBzdHJ1Y3QgaXRpbWVyc3BlYzMyICp2YWx1ZSk7IH0NCisyMzkJQVVFX05V TEwJTk9QUk9UTwl7IGludCBrdGltZXJfZ2V0b3ZlcnJ1bihpbnQgdGltZXJp ZCk7IH0NCiAyNDAJQVVFX05VTEwJU1RECXsgaW50IGZyZWVic2QzMl9uYW5v c2xlZXAoIFwNCiAJCQkJICAgIGNvbnN0IHN0cnVjdCB0aW1lc3BlYzMyICpy cXRwLCBcDQogCQkJCSAgICBzdHJ1Y3QgdGltZXNwZWMzMiAqcm10cCk7IH0N CkBAIC00NzYsNyArNDgyLDcgQEANCiAJCQkJICAgIHN0cnVjdCBhaW9jYjMy ICphaW9jYnApOyB9DQogMjU3CUFVRV9OVUxMCU5PU1RECXsgaW50IGZyZWVi c2QzMl9saW9fbGlzdGlvKGludCBtb2RlLCBcDQogCQkJCSAgICBzdHJ1Y3Qg YWlvY2IzMiAqIGNvbnN0ICphY2JfbGlzdCwgXA0KLQkJCQkgICAgaW50IG5l bnQsIHN0cnVjdCBzaWdldmVudCAqc2lnKTsgfQ0KKwkJCQkgICAgaW50IG5l bnQsIHN0cnVjdCBzaWdldmVudDMyICpzaWcpOyB9DQogMjU4CUFVRV9OVUxM CVVOSU1QTAlub3N5cw0KIDI1OQlBVUVfTlVMTAlVTklNUEwJbm9zeXMNCiAy NjAJQVVFX05VTEwJVU5JTVBMCW5vc3lzDQpAQCAtODI1LDggKzgzMSw4IEBA DQogCQkJCSAgICBjb25zdCBjaGFyICptc2dfcHRyLCBzaXplX3QgbXNnX2xl bixcDQogCQkJCSAgICB1bnNpZ25lZCBtc2dfcHJpbywJCQlcDQogCQkJCSAg ICBjb25zdCBzdHJ1Y3QgdGltZXNwZWMzMiAqYWJzX3RpbWVvdXQpO30NCi00 NjEJQVVFX05VTEwJTk9QUk9UT3xOT1NURAl7IGludCBrbXFfbm90aWZ5KGlu dCBtcWQsCVwNCi0JCQkJICAgIGNvbnN0IHN0cnVjdCBzaWdldmVudCAqc2ln ZXYpOyB9DQorNDYxCUFVRV9OVUxMCU5PU1RECXsgaW50IGZyZWVic2QzMl9r bXFfbm90aWZ5KGludCBtcWQsCVwNCisJCQkJICAgIGNvbnN0IHN0cnVjdCBz aWdldmVudDMyICpzaWdldik7IH0NCiA0NjIJQVVFX05VTEwJTk9QUk9UT3xO T1NURAl7IGludCBrbXFfdW5saW5rKGNvbnN0IGNoYXIgKnBhdGgpOyB9DQog NDYzCUFVRV9OVUxMCU5PUFJPVE8JeyBpbnQgYWJvcnQyKGNvbnN0IGNoYXIg KndoeSwgaW50IG5hcmdzLCB2b2lkICoqYXJncyk7IH0NCiA0NjQJQVVFX05V TEwgCU5PUFJPVE8JeyBpbnQgdGhyX3NldF9uYW1lKGxvbmcgaWQsIGNvbnN0 IGNoYXIgKm5hbWUpOyB9DQpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4va2Vybl90 aW1lLmMgYi9zeXMva2Vybi9rZXJuX3RpbWUuYw0KaW5kZXggNmI5MDhhMC4u NDE1MTg4YyAxMDA2NDQNCi0tLSBhL3N5cy9rZXJuL2tlcm5fdGltZS5jDQor KysgYi9zeXMva2Vybi9rZXJuX3RpbWUuYw0KQEAgLTk4LDkgKzk4LDYgQEAg c3RhdGljIGludAlyZWFsdGltZXJfc2V0dGltZShzdHJ1Y3QgaXRpbWVyICos IGludCwNCiBzdGF0aWMgaW50CXJlYWx0aW1lcl9kZWxldGUoc3RydWN0IGl0 aW1lciAqKTsNCiBzdGF0aWMgdm9pZAlyZWFsdGltZXJfY2xvY2t0aW1lKGNs b2NraWRfdCwgc3RydWN0IHRpbWVzcGVjICopOw0KIHN0YXRpYyB2b2lkCXJl YWx0aW1lcl9leHBpcmUodm9pZCAqKTsNCi1zdGF0aWMgaW50CWtlcm5fdGlt ZXJfY3JlYXRlKHN0cnVjdCB0aHJlYWQgKiwgY2xvY2tpZF90LA0KLQkJCXN0 cnVjdCBzaWdldmVudCAqLCBpbnQgKiwgaW50KTsNCi1zdGF0aWMgaW50CWtl cm5fdGltZXJfZGVsZXRlKHN0cnVjdCB0aHJlYWQgKiwgaW50KTsNCiANCiBp bnQJCXJlZ2lzdGVyX3Bvc2l4X2Nsb2NrKGludCwgc3RydWN0IGtjbG9jayAq KTsNCiB2b2lkCQlpdGltZXJfZmlyZShzdHJ1Y3QgaXRpbWVyICppdCk7DQpA QCAtMTA3OCwyMCArMTA3NSwxOCBAQCBzeXNfa3RpbWVyX2NyZWF0ZShzdHJ1 Y3QgdGhyZWFkICp0ZCwgc3RydWN0IGt0aW1lcl9jcmVhdGVfYXJncyAqdWFw KQ0KIAkJZXZwMSA9ICZldjsNCiAJfSBlbHNlDQogCQlldnAxID0gTlVMTDsN Ci0NCi0JZXJyb3IgPSBrZXJuX3RpbWVyX2NyZWF0ZSh0ZCwgdWFwLT5jbG9j a19pZCwgZXZwMSwgJmlkLCAtMSk7DQotDQorCWVycm9yID0ga2Vybl9rdGlt ZXJfY3JlYXRlKHRkLCB1YXAtPmNsb2NrX2lkLCBldnAxLCAmaWQsIC0xKTsN CiAJaWYgKGVycm9yID09IDApIHsNCiAJCWVycm9yID0gY29weW91dCgmaWQs IHVhcC0+dGltZXJpZCwgc2l6ZW9mKGludCkpOw0KIAkJaWYgKGVycm9yICE9 IDApDQotCQkJa2Vybl90aW1lcl9kZWxldGUodGQsIGlkKTsNCisJCQlrZXJu X2t0aW1lcl9kZWxldGUodGQsIGlkKTsNCiAJfQ0KIAlyZXR1cm4gKGVycm9y KTsNCiB9DQogDQotc3RhdGljIGludA0KLWtlcm5fdGltZXJfY3JlYXRlKHN0 cnVjdCB0aHJlYWQgKnRkLCBjbG9ja2lkX3QgY2xvY2tfaWQsDQotCXN0cnVj dCBzaWdldmVudCAqZXZwLCBpbnQgKnRpbWVyaWQsIGludCBwcmVzZXRfaWQp DQoraW50DQora2Vybl9rdGltZXJfY3JlYXRlKHN0cnVjdCB0aHJlYWQgKnRk LCBjbG9ja2lkX3QgY2xvY2tfaWQsIHN0cnVjdCBzaWdldmVudCAqZXZwLA0K KyAgICBpbnQgKnRpbWVyaWQsIGludCBwcmVzZXRfaWQpDQogew0KIAlzdHJ1 Y3QgcHJvYyAqcCA9IHRkLT50ZF9wcm9jOw0KIAlzdHJ1Y3QgaXRpbWVyICpp dDsNCkBAIC0xMjA2LDcgKzEyMDEsOCBAQCBzdHJ1Y3Qga3RpbWVyX2RlbGV0 ZV9hcmdzIHsNCiBpbnQNCiBzeXNfa3RpbWVyX2RlbGV0ZShzdHJ1Y3QgdGhy ZWFkICp0ZCwgc3RydWN0IGt0aW1lcl9kZWxldGVfYXJncyAqdWFwKQ0KIHsN Ci0JcmV0dXJuIChrZXJuX3RpbWVyX2RlbGV0ZSh0ZCwgdWFwLT50aW1lcmlk KSk7DQorDQorCXJldHVybiAoa2Vybl9rdGltZXJfZGVsZXRlKHRkLCB1YXAt PnRpbWVyaWQpKTsNCiB9DQogDQogc3RhdGljIHN0cnVjdCBpdGltZXIgKg0K QEAgLTEyMjgsOCArMTIyNCw4IEBAIGl0aW1lcl9maW5kKHN0cnVjdCBwcm9j ICpwLCBpbnQgdGltZXJpZCkNCiAJcmV0dXJuIChpdCk7DQogfQ0KIA0KLXN0 YXRpYyBpbnQNCi1rZXJuX3RpbWVyX2RlbGV0ZShzdHJ1Y3QgdGhyZWFkICp0 ZCwgaW50IHRpbWVyaWQpDQoraW50DQora2Vybl9rdGltZXJfZGVsZXRlKHN0 cnVjdCB0aHJlYWQgKnRkLCBpbnQgdGltZXJpZCkNCiB7DQogCXN0cnVjdCBw cm9jICpwID0gdGQtPnRkX3Byb2M7DQogCXN0cnVjdCBpdGltZXIgKml0Ow0K QEAgLTEyNzEsMzUgKzEyNjcsNDAgQEAgc3RydWN0IGt0aW1lcl9zZXR0aW1l X2FyZ3Mgew0KIGludA0KIHN5c19rdGltZXJfc2V0dGltZShzdHJ1Y3QgdGhy ZWFkICp0ZCwgc3RydWN0IGt0aW1lcl9zZXR0aW1lX2FyZ3MgKnVhcCkNCiB7 DQotCXN0cnVjdCBwcm9jICpwID0gdGQtPnRkX3Byb2M7DQotCXN0cnVjdCBp dGltZXIgKml0Ow0KIAlzdHJ1Y3QgaXRpbWVyc3BlYyB2YWwsIG92YWwsICpv dmFscDsNCiAJaW50IGVycm9yOw0KIA0KIAllcnJvciA9IGNvcHlpbih1YXAt PnZhbHVlLCAmdmFsLCBzaXplb2YodmFsKSk7DQogCWlmIChlcnJvciAhPSAw KQ0KIAkJcmV0dXJuIChlcnJvcik7DQotCQ0KLQlpZiAodWFwLT5vdmFsdWUg IT0gTlVMTCkNCi0JCW92YWxwID0gJm92YWw7DQotCWVsc2UNCi0JCW92YWxw ID0gTlVMTDsNCisJb3ZhbHAgPSB1YXAtPm92YWx1ZSAhPSBOVUxMID8gJm92 YWwgOiBOVUxMOw0KKwllcnJvciA9IGtlcm5fa3RpbWVyX3NldHRpbWUodGQs IHVhcC0+dGltZXJpZCwgdWFwLT5mbGFncywgJnZhbCwgb3ZhbHApOw0KKwlp ZiAoZXJyb3IgPT0gMCAmJiB1YXAtPm92YWx1ZSAhPSBOVUxMKQ0KKwkJZXJy b3IgPSBjb3B5b3V0KG92YWxwLCB1YXAtPm92YWx1ZSwgc2l6ZW9mKCpvdmFs cCkpOw0KKwlyZXR1cm4gKGVycm9yKTsNCit9DQogDQoraW50DQora2Vybl9r dGltZXJfc2V0dGltZShzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHRpbWVyX2lk LCBpbnQgZmxhZ3MsDQorICAgIHN0cnVjdCBpdGltZXJzcGVjICp2YWwsIHN0 cnVjdCBpdGltZXJzcGVjICpvdmFsKQ0KK3sNCisJc3RydWN0IHByb2MgKnA7 DQorCXN0cnVjdCBpdGltZXIgKml0Ow0KKwlpbnQgZXJyb3I7DQorDQorCXAg PSB0ZC0+dGRfcHJvYzsNCiAJUFJPQ19MT0NLKHApOw0KLQlpZiAodWFwLT50 aW1lcmlkIDwgMyB8fA0KLQkgICAgKGl0ID0gaXRpbWVyX2ZpbmQocCwgdWFw LT50aW1lcmlkKSkgPT0gTlVMTCkgew0KKwlpZiAodGltZXJfaWQgPCAzIHx8 IChpdCA9IGl0aW1lcl9maW5kKHAsIHRpbWVyX2lkKSkgPT0gTlVMTCkgew0K IAkJUFJPQ19VTkxPQ0socCk7DQogCQllcnJvciA9IEVJTlZBTDsNCiAJfSBl bHNlIHsNCiAJCVBST0NfVU5MT0NLKHApOw0KIAkJaXRpbWVyX2VudGVyKGl0 KTsNCi0JCWVycm9yID0gQ0xPQ0tfQ0FMTChpdC0+aXRfY2xvY2tpZCwgdGlt ZXJfc2V0dGltZSwNCi0JCQkJKGl0LCB1YXAtPmZsYWdzLCAmdmFsLCBvdmFs cCkpOw0KKwkJZXJyb3IgPSBDTE9DS19DQUxMKGl0LT5pdF9jbG9ja2lkLCB0 aW1lcl9zZXR0aW1lLCAoaXQsDQorCQkgICAgZmxhZ3MsIHZhbCwgb3ZhbCkp Ow0KIAkJaXRpbWVyX2xlYXZlKGl0KTsNCiAJCUlUSU1FUl9VTkxPQ0soaXQp Ow0KIAl9DQotCWlmIChlcnJvciA9PSAwICYmIHVhcC0+b3ZhbHVlICE9IE5V TEwpDQotCQllcnJvciA9IGNvcHlvdXQob3ZhbHAsIHVhcC0+b3ZhbHVlLCBz aXplb2YoKm92YWxwKSk7DQogCXJldHVybiAoZXJyb3IpOw0KIH0NCiANCkBA IC0xMzEyLDI2ICsxMzEzLDM0IEBAIHN0cnVjdCBrdGltZXJfZ2V0dGltZV9h cmdzIHsNCiBpbnQNCiBzeXNfa3RpbWVyX2dldHRpbWUoc3RydWN0IHRocmVh ZCAqdGQsIHN0cnVjdCBrdGltZXJfZ2V0dGltZV9hcmdzICp1YXApDQogew0K LQlzdHJ1Y3QgcHJvYyAqcCA9IHRkLT50ZF9wcm9jOw0KLQlzdHJ1Y3QgaXRp bWVyICppdDsNCiAJc3RydWN0IGl0aW1lcnNwZWMgdmFsOw0KIAlpbnQgZXJy b3I7DQogDQorCWVycm9yID0ga2Vybl9rdGltZXJfZ2V0dGltZSh0ZCwgdWFw LT50aW1lcmlkLCAmdmFsKTsNCisJaWYgKGVycm9yID09IDApDQorCQllcnJv ciA9IGNvcHlvdXQoJnZhbCwgdWFwLT52YWx1ZSwgc2l6ZW9mKHZhbCkpOw0K KwlyZXR1cm4gKGVycm9yKTsNCit9DQorDQoraW50DQora2Vybl9rdGltZXJf Z2V0dGltZShzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHRpbWVyX2lkLCBzdHJ1 Y3QgaXRpbWVyc3BlYyAqdmFsKQ0KK3sNCisJc3RydWN0IHByb2MgKnA7DQor CXN0cnVjdCBpdGltZXIgKml0Ow0KKwlpbnQgZXJyb3I7DQorDQorCXAgPSB0 ZC0+dGRfcHJvYzsNCiAJUFJPQ19MT0NLKHApOw0KLQlpZiAodWFwLT50aW1l cmlkIDwgMyB8fA0KLQkgICAoaXQgPSBpdGltZXJfZmluZChwLCB1YXAtPnRp bWVyaWQpKSA9PSBOVUxMKSB7DQorCWlmICh0aW1lcl9pZCA8IDMgfHwgKGl0 ID0gaXRpbWVyX2ZpbmQocCwgdGltZXJfaWQpKSA9PSBOVUxMKSB7DQogCQlQ Uk9DX1VOTE9DSyhwKTsNCiAJCWVycm9yID0gRUlOVkFMOw0KIAl9IGVsc2Ug ew0KIAkJUFJPQ19VTkxPQ0socCk7DQogCQlpdGltZXJfZW50ZXIoaXQpOw0K LQkJZXJyb3IgPSBDTE9DS19DQUxMKGl0LT5pdF9jbG9ja2lkLCB0aW1lcl9n ZXR0aW1lLA0KLQkJCQkoaXQsICZ2YWwpKTsNCisJCWVycm9yID0gQ0xPQ0tf Q0FMTChpdC0+aXRfY2xvY2tpZCwgdGltZXJfZ2V0dGltZSwgKGl0LCB2YWwp KTsNCiAJCWl0aW1lcl9sZWF2ZShpdCk7DQogCQlJVElNRVJfVU5MT0NLKGl0 KTsNCiAJfQ0KLQlpZiAoZXJyb3IgPT0gMCkNCi0JCWVycm9yID0gY29weW91 dCgmdmFsLCB1YXAtPnZhbHVlLCBzaXplb2YodmFsKSk7DQogCXJldHVybiAo ZXJyb3IpOw0KIH0NCiANCkBAIC0xNjI2LDcgKzE2MzUsNyBAQCBpdGltZXJz X2V2ZW50X2hvb2tfZXhpdCh2b2lkICphcmcsIHN0cnVjdCBwcm9jICpwKQ0K IAkJCXBhbmljKCJ1bmhhbmRsZWQgZXZlbnQiKTsNCiAJCWZvciAoOyBpIDwg VElNRVJfTUFYOyArK2kpIHsNCiAJCQlpZiAoKGl0ID0gaXRzLT5pdHNfdGlt ZXJzW2ldKSAhPSBOVUxMKQ0KLQkJCQlrZXJuX3RpbWVyX2RlbGV0ZShjdXJ0 aHJlYWQsIGkpOw0KKwkJCQlrZXJuX2t0aW1lcl9kZWxldGUoY3VydGhyZWFk LCBpKTsNCiAJCX0NCiAJCWlmIChpdHMtPml0c190aW1lcnNbMF0gPT0gTlVM TCAmJg0KIAkJICAgIGl0cy0+aXRzX3RpbWVyc1sxXSA9PSBOVUxMICYmDQpk aWZmIC0tZ2l0IGEvc3lzL2tlcm4vdWlwY19tcXVldWUuYyBiL3N5cy9rZXJu L3VpcGNfbXF1ZXVlLmMNCmluZGV4IDczNTc5ZDMuLmFlM2YxYTYgMTAwNjQ0 DQotLS0gYS9zeXMva2Vybi91aXBjX21xdWV1ZS5jDQorKysgYi9zeXMva2Vy bi91aXBjX21xdWV1ZS5jDQpAQCAtMjIzNSwxMCArMjIzNSw5IEBAIHN5c19r bXFfdGltZWRzZW5kKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3Qga21xX3Rp bWVkc2VuZF9hcmdzICp1YXApDQogCXJldHVybiAoZXJyb3IpOw0KIH0NCiAN Ci1pbnQNCi1zeXNfa21xX25vdGlmeShzdHJ1Y3QgdGhyZWFkICp0ZCwgc3Ry dWN0IGttcV9ub3RpZnlfYXJncyAqdWFwKQ0KK3N0YXRpYyBpbnQNCitrZXJu X2ttcV9ub3RpZnkoc3RydWN0IHRocmVhZCAqdGQsIGludCBtcWQsIHN0cnVj dCBzaWdldmVudCAqc2lnZXYpDQogew0KLQlzdHJ1Y3Qgc2lnZXZlbnQgZXY7 DQogCXN0cnVjdCBmaWxlZGVzYyAqZmRwOw0KIAlzdHJ1Y3QgcHJvYyAqcDsN CiAJc3RydWN0IG1xdWV1ZSAqbXE7DQpAQCAtMjI0NiwzNCArMjI0NSwzMSBA QCBzeXNfa21xX25vdGlmeShzdHJ1Y3QgdGhyZWFkICp0ZCwgc3RydWN0IGtt cV9ub3RpZnlfYXJncyAqdWFwKQ0KIAlzdHJ1Y3QgbXF1ZXVlX25vdGlmaWVy ICpudCwgKm5ld250ID0gTlVMTDsNCiAJaW50IGVycm9yOw0KIA0KLQlwID0g dGQtPnRkX3Byb2M7DQotCWZkcCA9IHRkLT50ZF9wcm9jLT5wX2ZkOw0KLQlp ZiAodWFwLT5zaWdldikgew0KLQkJZXJyb3IgPSBjb3B5aW4odWFwLT5zaWdl diwgJmV2LCBzaXplb2YoZXYpKTsNCi0JCWlmIChlcnJvcikNCi0JCQlyZXR1 cm4gKGVycm9yKTsNCi0JCWlmIChldi5zaWdldl9ub3RpZnkgIT0gU0lHRVZf U0lHTkFMICYmDQotCQkgICAgZXYuc2lnZXZfbm90aWZ5ICE9IFNJR0VWX1RI UkVBRF9JRCAmJg0KLQkJICAgIGV2LnNpZ2V2X25vdGlmeSAhPSBTSUdFVl9O T05FKQ0KKwlpZiAoc2lnZXYgIT0gTlVMTCkgew0KKwkJaWYgKHNpZ2V2LT5z aWdldl9ub3RpZnkgIT0gU0lHRVZfU0lHTkFMICYmDQorCQkgICAgc2lnZXYt PnNpZ2V2X25vdGlmeSAhPSBTSUdFVl9USFJFQURfSUQgJiYNCisJCSAgICBz aWdldi0+c2lnZXZfbm90aWZ5ICE9IFNJR0VWX05PTkUpDQogCQkJcmV0dXJu IChFSU5WQUwpOw0KLQkJaWYgKChldi5zaWdldl9ub3RpZnkgPT0gU0lHRVZf U0lHTkFMIHx8DQotCQkgICAgIGV2LnNpZ2V2X25vdGlmeSA9PSBTSUdFVl9U SFJFQURfSUQpICYmDQotCQkJIV9TSUdfVkFMSUQoZXYuc2lnZXZfc2lnbm8p KQ0KKwkJaWYgKChzaWdldi0+c2lnZXZfbm90aWZ5ID09IFNJR0VWX1NJR05B TCB8fA0KKwkJICAgIHNpZ2V2LT5zaWdldl9ub3RpZnkgPT0gU0lHRVZfVEhS RUFEX0lEKSAmJg0KKwkJICAgICFfU0lHX1ZBTElEKHNpZ2V2LT5zaWdldl9z aWdubykpDQogCQkJcmV0dXJuIChFSU5WQUwpOw0KIAl9DQotCWVycm9yID0g Z2V0bXEodGQsIHVhcC0+bXFkLCAmZnAsIE5VTEwsICZtcSk7DQorCXAgPSB0 ZC0+dGRfcHJvYzsNCisJZmRwID0gdGQtPnRkX3Byb2MtPnBfZmQ7DQorCWVy cm9yID0gZ2V0bXEodGQsIG1xZCwgJmZwLCBOVUxMLCAmbXEpOw0KIAlpZiAo ZXJyb3IpDQogCQlyZXR1cm4gKGVycm9yKTsNCiBhZ2FpbjoNCiAJRklMRURF U0NfU0xPQ0soZmRwKTsNCi0JZnAyID0gZmdldF9sb2NrZWQoZmRwLCB1YXAt Pm1xZCk7DQorCWZwMiA9IGZnZXRfbG9ja2VkKGZkcCwgbXFkKTsNCiAJaWYg KGZwMiA9PSBOVUxMKSB7DQogCQlGSUxFREVTQ19TVU5MT0NLKGZkcCk7DQog CQllcnJvciA9IEVCQURGOw0KIAkJZ290byBvdXQ7DQogCX0NCiAjaWZkZWYg Q0FQQUJJTElUSUVTDQotCWVycm9yID0gY2FwX2NoZWNrKGNhcF9yaWdodHMo ZmRwLCB1YXAtPm1xZCksIENBUF9QT0xMX0VWRU5UKTsNCisJZXJyb3IgPSBj YXBfY2hlY2soY2FwX3JpZ2h0cyhmZHAsIG1xZCksIENBUF9QT0xMX0VWRU5U KTsNCiAJaWYgKGVycm9yKSB7DQogCQlGSUxFREVTQ19TVU5MT0NLKGZkcCk7 DQogCQlnb3RvIG91dDsNCkBAIC0yMjg2LDEyICsyMjgyLDEyIEBAIGFnYWlu Og0KIAl9DQogCW10eF9sb2NrKCZtcS0+bXFfbXV0ZXgpOw0KIAlGSUxFREVT Q19TVU5MT0NLKGZkcCk7DQotCWlmICh1YXAtPnNpZ2V2ICE9IE5VTEwpIHsN CisJaWYgKHNpZ2V2ICE9IE5VTEwpIHsNCiAJCWlmIChtcS0+bXFfbm90aWZp ZXIgIT0gTlVMTCkgew0KIAkJCWVycm9yID0gRUJVU1k7DQogCQl9IGVsc2Ug ew0KIAkJCVBST0NfTE9DSyhwKTsNCi0JCQludCA9IG5vdGlmaWVyX3NlYXJj aChwLCB1YXAtPm1xZCk7DQorCQkJbnQgPSBub3RpZmllcl9zZWFyY2gocCwg bXFkKTsNCiAJCQlpZiAobnQgPT0gTlVMTCkgew0KIAkJCQlpZiAobmV3bnQg PT0gTlVMTCkgew0KIAkJCQkJUFJPQ19VTkxPQ0socCk7DQpAQCAtMjMxNCwx MCArMjMxMCwxMCBAQCBhZ2FpbjoNCiAJCQkJbnQtPm50X2tzaS5rc2lfZmxh Z3MgfD0gS1NJX0lOUyB8IEtTSV9FWFQ7DQogCQkJCW50LT5udF9rc2kua3Np X2NvZGUgPSBTSV9NRVNHUTsNCiAJCQkJbnQtPm50X3Byb2MgPSBwOw0KLQkJ CQludC0+bnRfa3NpLmtzaV9tcWQgPSB1YXAtPm1xZDsNCisJCQkJbnQtPm50 X2tzaS5rc2lfbXFkID0gbXFkOw0KIAkJCQlub3RpZmllcl9pbnNlcnQocCwg bnQpOw0KIAkJCX0NCi0JCQludC0+bnRfc2lnZXYgPSBldjsNCisJCQludC0+ bnRfc2lnZXYgPSAqc2lnZXY7DQogCQkJbXEtPm1xX25vdGlmaWVyID0gbnQ7 DQogCQkJUFJPQ19VTkxPQ0socCk7DQogCQkJLyoNCkBAIC0yMzMwLDcgKzIz MjYsNyBAQCBhZ2FpbjoNCiAJCQkJbXF1ZXVlX3NlbmRfbm90aWZpY2F0aW9u KG1xKTsNCiAJCX0NCiAJfSBlbHNlIHsNCi0JCW5vdGlmaWVyX3JlbW92ZShw LCBtcSwgdWFwLT5tcWQpOw0KKwkJbm90aWZpZXJfcmVtb3ZlKHAsIG1xLCBt cWQpOw0KIAl9DQogCW10eF91bmxvY2soJm1xLT5tcV9tdXRleCk7DQogDQpA QCAtMjM0MSw2ICsyMzM3LDIwIEBAIG91dDoNCiAJcmV0dXJuIChlcnJvcik7 DQogfQ0KIA0KK2ludA0KK3N5c19rbXFfbm90aWZ5KHN0cnVjdCB0aHJlYWQg KnRkLCBzdHJ1Y3Qga21xX25vdGlmeV9hcmdzICp1YXApDQorew0KKwlzdHJ1 Y3Qgc2lnZXZlbnQgZXY7DQorCWludCBlcnJvcjsNCisNCisJaWYgKHVhcC0+ c2lnZXYgIT0gTlVMTCkgew0KKwkJZXJyb3IgPSBjb3B5aW4odWFwLT5zaWdl diwgJmV2LCBzaXplb2YoZXYpKTsNCisJCWlmIChlcnJvciAhPSAwKQ0KKwkJ CXJldHVybiAoZXJyb3IpOw0KKwl9DQorCXJldHVybiAoa2Vybl9rbXFfbm90 aWZ5KHRkLCB1YXAtPm1xZCwgJmV2KSk7DQorfQ0KKw0KIHN0YXRpYyB2b2lk DQogbXF1ZXVlX2ZkY2xvc2Uoc3RydWN0IHRocmVhZCAqdGQsIGludCBmZCwg c3RydWN0IGZpbGUgKmZwKQ0KIHsNCkBAIC0yNjM3LDYgKzI2NDcsNyBAQCBz dGF0aWMgc3RydWN0IHN5c2NhbGxfaGVscGVyX2RhdGEgbXFfc3lzY2FsbHNb XSA9IHsNCiAjaWZkZWYgQ09NUEFUX0ZSRUVCU0QzMg0KICNpbmNsdWRlIDxj b21wYXQvZnJlZWJzZDMyL2ZyZWVic2QzMi5oPg0KICNpbmNsdWRlIDxjb21w YXQvZnJlZWJzZDMyL2ZyZWVic2QzMl9wcm90by5oPg0KKyNpbmNsdWRlIDxj b21wYXQvZnJlZWJzZDMyL2ZyZWVic2QzMl9zaWduYWwuaD4NCiAjaW5jbHVk ZSA8Y29tcGF0L2ZyZWVic2QzMi9mcmVlYnNkMzJfc3lzY2FsbC5oPg0KICNp bmNsdWRlIDxjb21wYXQvZnJlZWJzZDMyL2ZyZWVic2QzMl91dGlsLmg+DQog DQpAQCAtMjc2MywxMiArMjc3NCwzMCBAQCBmcmVlYnNkMzJfa21xX3RpbWVk cmVjZWl2ZShzdHJ1Y3QgdGhyZWFkICp0ZCwNCiAJcmV0dXJuIChlcnJvcik7 DQogfQ0KIA0KK2ludA0KK2ZyZWVic2QzMl9rbXFfbm90aWZ5KHN0cnVjdCB0 aHJlYWQgKnRkLCBzdHJ1Y3QgZnJlZWJzZDMyX2ttcV9ub3RpZnlfYXJncyAq dWFwKQ0KK3sNCisJc3RydWN0IHNpZ2V2ZW50IGV2Ow0KKwlzdHJ1Y3Qgc2ln ZXZlbnQzMiBldjMyOw0KKwlpbnQgZXJyb3I7DQorDQorCWlmICh1YXAtPnNp Z2V2ICE9IE5VTEwpIHsNCisJCWVycm9yID0gY29weWluKHVhcC0+c2lnZXYs ICZldjMyLCBzaXplb2YoZXYzMikpOw0KKwkJaWYgKGVycm9yICE9IDApDQor CQkJcmV0dXJuIChlcnJvcik7DQorCQllcnJvciA9IGNvbnZlcnRfc2lnZXZl bnQzMigmZXYzMiwgJmV2KTsNCisJCWlmIChlcnJvciAhPSAwKQ0KKwkJCXJl dHVybiAoZXJyb3IpOw0KKwl9DQorCXJldHVybiAoa2Vybl9rbXFfbm90aWZ5 KHRkLCB1YXAtPm1xZCwgJmV2KSk7DQorfQ0KKw0KIHN0YXRpYyBzdHJ1Y3Qg c3lzY2FsbF9oZWxwZXJfZGF0YSBtcTMyX3N5c2NhbGxzW10gPSB7DQogCVNZ U0NBTEwzMl9JTklUX0hFTFBFUihmcmVlYnNkMzJfa21xX29wZW4pLA0KIAlT WVNDQUxMMzJfSU5JVF9IRUxQRVIoZnJlZWJzZDMyX2ttcV9zZXRhdHRyKSwN CiAJU1lTQ0FMTDMyX0lOSVRfSEVMUEVSKGZyZWVic2QzMl9rbXFfdGltZWRz ZW5kKSwNCiAJU1lTQ0FMTDMyX0lOSVRfSEVMUEVSKGZyZWVic2QzMl9rbXFf dGltZWRyZWNlaXZlKSwNCi0JU1lTQ0FMTDMyX0lOSVRfSEVMUEVSX0NPTVBB VChrbXFfbm90aWZ5KSwNCisJU1lTQ0FMTDMyX0lOSVRfSEVMUEVSKGZyZWVi c2QzMl9rbXFfbm90aWZ5KSwNCiAJU1lTQ0FMTDMyX0lOSVRfSEVMUEVSX0NP TVBBVChrbXFfdW5saW5rKSwNCiAJU1lTQ0FMTF9JTklUX0xBU1QNCiB9Ow0K ZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3Zmc19haW8uYyBiL3N5cy9rZXJuL3Zm c19haW8uYw0KaW5kZXggNWZiOTM0MS4uODYyNDQzYyAxMDA2NDQNCi0tLSBh L3N5cy9rZXJuL3Zmc19haW8uYw0KKysrIGIvc3lzL2tlcm4vdmZzX2Fpby5j DQpAQCAtMjc1NSwzMSArMjc1NSw2IEBAIGFpb2NiMzJfY29weWluX29sZF9z aWdldmVudChzdHJ1Y3QgYWlvY2IgKnVqb2IsIHN0cnVjdCBhaW9jYiAqa2pv YikNCiB9DQogDQogc3RhdGljIGludA0KLWNvbnZlcnRfc2lnZXZlbnQzMihz dHJ1Y3Qgc2lnZXZlbnQzMiAqc2lnMzIsIHN0cnVjdCBzaWdldmVudCAqc2ln KQ0KLXsNCi0NCi0JQ1AoKnNpZzMyLCAqc2lnLCBzaWdldl9ub3RpZnkpOw0K LQlzd2l0Y2ggKHNpZy0+c2lnZXZfbm90aWZ5KSB7DQotCWNhc2UgU0lHRVZf Tk9ORToNCi0JCWJyZWFrOw0KLQljYXNlIFNJR0VWX1RIUkVBRF9JRDoNCi0J CUNQKCpzaWczMiwgKnNpZywgc2lnZXZfbm90aWZ5X3RocmVhZF9pZCk7DQot CQkvKiBGQUxMVEhST1VHSCAqLw0KLQljYXNlIFNJR0VWX1NJR05BTDoNCi0J CUNQKCpzaWczMiwgKnNpZywgc2lnZXZfc2lnbm8pOw0KLQkJYnJlYWs7DQot CWNhc2UgU0lHRVZfS0VWRU5UOg0KLQkJQ1AoKnNpZzMyLCAqc2lnLCBzaWdl dl9ub3RpZnlfa3F1ZXVlKTsNCi0JCUNQKCpzaWczMiwgKnNpZywgc2lnZXZf bm90aWZ5X2tldmVudF9mbGFncyk7DQotCQlQVFJJTl9DUCgqc2lnMzIsICpz aWcsIHNpZ2V2X3ZhbHVlLnNpdmFsX3B0cik7DQotCQlicmVhazsNCi0JZGVm YXVsdDoNCi0JCXJldHVybiAoRUlOVkFMKTsNCi0JfQ0KLQlyZXR1cm4gKDAp Ow0KLX0NCi0NCi1zdGF0aWMgaW50DQogYWlvY2IzMl9jb3B5aW4oc3RydWN0 IGFpb2NiICp1am9iLCBzdHJ1Y3QgYWlvY2IgKmtqb2IpDQogew0KIAlzdHJ1 Y3QgYWlvY2IzMiBqb2IzMjsNCmRpZmYgLS1naXQgYS9zeXMvc3lzL3N5c2Nh bGxzdWJyLmggYi9zeXMvc3lzL3N5c2NhbGxzdWJyLmgNCmluZGV4IDc1Mjc4 YzMuLmUxOGM3MzUgMTAwNjQ0DQotLS0gYS9zeXMvc3lzL3N5c2NhbGxzdWJy LmgNCisrKyBiL3N5cy9zeXMvc3lzY2FsbHN1YnIuaA0KQEAgLTIyOCw2ICsy MjgsMTMgQEAgaW50CWtlcm5fc3ltbGluayhzdHJ1Y3QgdGhyZWFkICp0ZCwg Y2hhciAqcGF0aCwgY2hhciAqbGluaywNCiAJICAgIGVudW0gdWlvX3NlZyBz ZWdmbGcpOw0KIGludAlrZXJuX3N5bWxpbmthdChzdHJ1Y3QgdGhyZWFkICp0 ZCwgY2hhciAqcGF0aDEsIGludCBmZCwgY2hhciAqcGF0aDIsDQogCSAgICBl bnVtIHVpb19zZWcgc2VnZmxnKTsNCitpbnQJa2Vybl9rdGltZXJfY3JlYXRl KHN0cnVjdCB0aHJlYWQgKnRkLCBjbG9ja2lkX3QgY2xvY2tfaWQsDQorCSAg ICBzdHJ1Y3Qgc2lnZXZlbnQgKmV2cCwgaW50ICp0aW1lcmlkLCBpbnQgcHJl c2V0X2lkKTsNCitpbnQJa2Vybl9rdGltZXJfZGVsZXRlKHN0cnVjdCB0aHJl YWQgKiwgaW50KTsNCitpbnQJa2Vybl9rdGltZXJfc2V0dGltZShzdHJ1Y3Qg dGhyZWFkICp0ZCwgaW50IHRpbWVyX2lkLCBpbnQgZmxhZ3MsDQorCSAgICBz dHJ1Y3QgaXRpbWVyc3BlYyAqdmFsLCBzdHJ1Y3QgaXRpbWVyc3BlYyAqb3Zh bCk7DQoraW50CWtlcm5fa3RpbWVyX2dldHRpbWUoc3RydWN0IHRocmVhZCAq dGQsIGludCB0aW1lcl9pZCwNCisJICAgIHN0cnVjdCBpdGltZXJzcGVjICp2 YWwpOw0KIGludAlrZXJuX3Rocl9uZXcoc3RydWN0IHRocmVhZCAqdGQsIHN0 cnVjdCB0aHJfcGFyYW0gKnBhcmFtKTsNCiBpbnQJa2Vybl90aHJfc3VzcGVu ZChzdHJ1Y3QgdGhyZWFkICp0ZCwgc3RydWN0IHRpbWVzcGVjICp0c3ApOw0K IGludAlrZXJuX3RydW5jYXRlKHN0cnVjdCB0aHJlYWQgKnRkLCBjaGFyICpw YXRoLCBlbnVtIHVpb19zZWcgcGF0aHNlZywNCg== --8323328-1230774450-1374395034=:23067-- From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 09:10:03 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6691AF5C for ; Sun, 21 Jul 2013 09:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 48EE7D51 for ; Sun, 21 Jul 2013 09:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6L9A3u3004929 for ; Sun, 21 Jul 2013 09:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6L9A3bV004928; Sun, 21 Jul 2013 09:10:03 GMT (envelope-from gnats) Date: Sun, 21 Jul 2013 09:10:03 GMT Message-Id: <201307210910.r6L9A3bV004928@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: Konstantin Belousov Subject: Re: threads/180652: compat32 problem in clock_getcpuclockid2 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Konstantin Belousov List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 09:10:03 -0000 The following reply was made to PR threads/180652; it has been noted by GNATS. From: Konstantin Belousov To: Petr Salinger Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/180652: compat32 problem in clock_getcpuclockid2 Date: Sun, 21 Jul 2013 12:05:19 +0300 --E6cJGRvJdK5HoYjj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2013 at 10:23:54AM +0200, Petr Salinger wrote: > >> I only tested with adapted tst-timer2.c. I hope you would do the res= t. > > I tried. The tst-timer4.c timed out. I will look at it later. >=20 > There have been two problems: >=20 > a) sigev_value.sival_ptr have not been copied > b) the code misshandles timer_create() with NULL struct sigevent >=20 > With attached patch, it passes our tests. >=20 > I think, that there is a similar bug in both new > freebsd32_kmq_notify() and sys_kmq_notify(). > They do not handle NULL in struct sigevent, it might suffice to >=20 > - return (kern_kmq_notify(td, uap->mqd, &ev)); > + return (kern_kmq_notify(td, uap->mqd, uap->sigev =3D=3D NULL ? NULL : &= ev)); >=20 > But this seems not be covered by our testsuite. Thank you. I mailed you about sival_int earlier. The bugfix for NULL sigev is applied to both timers and mqueue. I intend to commit the patch below later today. diff --git a/sys/compat/freebsd32/freebsd32.h b/sys/compat/freebsd32/freebs= d32.h index a95b0e5..9b04965 100644 --- a/sys/compat/freebsd32/freebsd32.h +++ b/sys/compat/freebsd32/freebsd32.h @@ -69,6 +69,15 @@ struct timespec32 { CP((src).fld,(dst).fld,tv_nsec); \ } while (0) =20 +struct itimerspec32 { + struct timespec32 it_interval; + struct timespec32 it_value; +}; +#define ITS_CP(src, dst) do { \ + TS_CP((src), (dst), it_interval); \ + TS_CP((src), (dst), it_value); \ +} while (0) + struct rusage32 { struct timeval32 ru_utime; struct timeval32 ru_stime; diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index cfcd83b..4899e03 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -2331,6 +2331,70 @@ freebsd32_clock_getres(struct thread *td, return (error); } =20 +int freebsd32_ktimer_create(struct thread *td, + struct freebsd32_ktimer_create_args *uap) +{ + struct sigevent32 ev32; + struct sigevent ev, *evp; + int error, id; + + if (uap->evp =3D=3D NULL) { + evp =3D NULL; + } else { + evp =3D &ev; + error =3D copyin(uap->evp, &ev32, sizeof(ev32)); + if (error !=3D 0) + return (error); + error =3D convert_sigevent32(&ev32, &ev); + if (error !=3D 0) + return (error); + } + error =3D kern_ktimer_create(td, uap->clock_id, evp, &id, -1); + if (error =3D=3D 0) { + error =3D copyout(&id, uap->timerid, sizeof(int)); + if (error !=3D 0) + kern_ktimer_delete(td, id); + } + return (error); +} + +int +freebsd32_ktimer_settime(struct thread *td, + struct freebsd32_ktimer_settime_args *uap) +{ + struct itimerspec32 val32, oval32; + struct itimerspec val, oval, *ovalp; + int error; + + error =3D copyin(uap->value, &val32, sizeof(val32)); + if (error !=3D 0) + return (error); + ITS_CP(val32, val); + ovalp =3D uap->ovalue !=3D NULL ? &oval : NULL; + error =3D kern_ktimer_settime(td, uap->timerid, uap->flags, &val, ovalp); + if (error =3D=3D 0 && uap->ovalue !=3D NULL) { + ITS_CP(oval, oval32); + error =3D copyout(&oval32, uap->ovalue, sizeof(oval32)); + } + return (error); +} + +int +freebsd32_ktimer_gettime(struct thread *td, + struct freebsd32_ktimer_gettime_args *uap) +{ + struct itimerspec32 val32; + struct itimerspec val; + int error; + + error =3D kern_ktimer_gettime(td, uap->timerid, &val); + if (error =3D=3D 0) { + ITS_CP(val, val32); + error =3D copyout(&val32, uap->value, sizeof(val32)); + } + return (error); +} + int freebsd32_clock_getcpuclockid2(struct thread *td, struct freebsd32_clock_getcpuclockid2_args *uap) @@ -2410,7 +2474,7 @@ siginfo_to_siginfo32(const siginfo_t *src, struct sig= info32 *dst) dst->si_uid =3D src->si_uid; dst->si_status =3D src->si_status; dst->si_addr =3D (uintptr_t)src->si_addr; - dst->si_value.sigval_int =3D src->si_value.sival_int; + dst->si_value.sival_int =3D src->si_value.sival_int; dst->si_timerid =3D src->si_timerid; dst->si_overrun =3D src->si_overrun; } @@ -2912,3 +2976,29 @@ freebsd32_posix_fadvise(struct thread *td, return (kern_posix_fadvise(td, uap->fd, PAIR32TO64(off_t, uap->offset), PAIR32TO64(off_t, uap->len), uap->advice)); } + +int +convert_sigevent32(struct sigevent32 *sig32, struct sigevent *sig) +{ + + CP(*sig32, *sig, sigev_notify); + switch (sig->sigev_notify) { + case SIGEV_NONE: + break; + case SIGEV_THREAD_ID: + CP(*sig32, *sig, sigev_notify_thread_id); + /* FALLTHROUGH */ + case SIGEV_SIGNAL: + CP(*sig32, *sig, sigev_signo); + PTRIN_CP(*sig32, *sig, sigev_value.sival_ptr); + break; + case SIGEV_KEVENT: + CP(*sig32, *sig, sigev_notify_kqueue); + CP(*sig32, *sig, sigev_notify_kevent_flags); + PTRIN_CP(*sig32, *sig, sigev_value.sival_ptr); + break; + default: + return (EINVAL); + } + return (0); +} diff --git a/sys/compat/freebsd32/freebsd32_signal.h b/sys/compat/freebsd32= /freebsd32_signal.h index d31a8ae..18899f8 100644 --- a/sys/compat/freebsd32/freebsd32_signal.h +++ b/sys/compat/freebsd32/freebsd32_signal.h @@ -97,6 +97,8 @@ struct sigevent32 { } _sigev_un; }; =20 +struct sigevent; +int convert_sigevent32(struct sigevent32 *sig32, struct sigevent *sig); void siginfo_to_siginfo32(const siginfo_t *src, struct siginfo32 *dst); =20 #endif /* !_COMPAT_FREEBSD32_SIGNAL_H_ */ diff --git a/sys/compat/freebsd32/syscalls.master b/sys/compat/freebsd32/sy= scalls.master index 6cb649f..daee72c 100644 --- a/sys/compat/freebsd32/syscalls.master +++ b/sys/compat/freebsd32/syscalls.master @@ -441,11 +441,17 @@ const struct timespec32 *tp); } 234 AUE_NULL STD { int freebsd32_clock_getres(clockid_t clock_id, \ struct timespec32 *tp); } -235 AUE_NULL UNIMPL timer_create -236 AUE_NULL UNIMPL timer_delete -237 AUE_NULL UNIMPL timer_settime -238 AUE_NULL UNIMPL timer_gettime -239 AUE_NULL UNIMPL timer_getoverrun +235 AUE_NULL STD { int freebsd32_ktimer_create(\ + clockid_t clock_id, \ + struct sigevent32 *evp, int *timerid); } +236 AUE_NULL NOPROTO { int ktimer_delete(int timerid); } +237 AUE_NULL STD { int freebsd32_ktimer_settime(int timerid,\ + int flags, \ + const struct itimerspec32 *value, \ + struct itimerspec32 *ovalue); } +238 AUE_NULL STD { int freebsd32_ktimer_gettime(int timerid,\ + struct itimerspec32 *value); } +239 AUE_NULL NOPROTO { int ktimer_getoverrun(int timerid); } 240 AUE_NULL STD { int freebsd32_nanosleep( \ const struct timespec32 *rqtp, \ struct timespec32 *rmtp); } @@ -476,7 +482,7 @@ struct aiocb32 *aiocbp); } 257 AUE_NULL NOSTD { int freebsd32_lio_listio(int mode, \ struct aiocb32 * const *acb_list, \ - int nent, struct sigevent *sig); } + int nent, struct sigevent32 *sig); } 258 AUE_NULL UNIMPL nosys 259 AUE_NULL UNIMPL nosys 260 AUE_NULL UNIMPL nosys @@ -825,8 +831,8 @@ const char *msg_ptr, size_t msg_len,\ unsigned msg_prio, \ const struct timespec32 *abs_timeout);} -461 AUE_NULL NOPROTO|NOSTD { int kmq_notify(int mqd, \ - const struct sigevent *sigev); } +461 AUE_NULL NOSTD { int freebsd32_kmq_notify(int mqd, \ + const struct sigevent32 *sigev); } 462 AUE_NULL NOPROTO|NOSTD { int kmq_unlink(const char *path); } 463 AUE_NULL NOPROTO { int abort2(const char *why, int nargs, void **args)= ; } 464 AUE_NULL NOPROTO { int thr_set_name(long id, const char *name); } diff --git a/sys/kern/kern_time.c b/sys/kern/kern_time.c index 6b908a0..415188c 100644 --- a/sys/kern/kern_time.c +++ b/sys/kern/kern_time.c @@ -98,9 +98,6 @@ static int realtimer_settime(struct itimer *, int, static int realtimer_delete(struct itimer *); static void realtimer_clocktime(clockid_t, struct timespec *); static void realtimer_expire(void *); -static int kern_timer_create(struct thread *, clockid_t, - struct sigevent *, int *, int); -static int kern_timer_delete(struct thread *, int); =20 int register_posix_clock(int, struct kclock *); void itimer_fire(struct itimer *it); @@ -1078,20 +1075,18 @@ sys_ktimer_create(struct thread *td, struct ktimer_= create_args *uap) evp1 =3D &ev; } else evp1 =3D NULL; - - error =3D kern_timer_create(td, uap->clock_id, evp1, &id, -1); - + error =3D kern_ktimer_create(td, uap->clock_id, evp1, &id, -1); if (error =3D=3D 0) { error =3D copyout(&id, uap->timerid, sizeof(int)); if (error !=3D 0) - kern_timer_delete(td, id); + kern_ktimer_delete(td, id); } return (error); } =20 -static int -kern_timer_create(struct thread *td, clockid_t clock_id, - struct sigevent *evp, int *timerid, int preset_id) +int +kern_ktimer_create(struct thread *td, clockid_t clock_id, struct sigevent = *evp, + int *timerid, int preset_id) { struct proc *p =3D td->td_proc; struct itimer *it; @@ -1206,7 +1201,8 @@ struct ktimer_delete_args { int sys_ktimer_delete(struct thread *td, struct ktimer_delete_args *uap) { - return (kern_timer_delete(td, uap->timerid)); + + return (kern_ktimer_delete(td, uap->timerid)); } =20 static struct itimer * @@ -1228,8 +1224,8 @@ itimer_find(struct proc *p, int timerid) return (it); } =20 -static int -kern_timer_delete(struct thread *td, int timerid) +int +kern_ktimer_delete(struct thread *td, int timerid) { struct proc *p =3D td->td_proc; struct itimer *it; @@ -1271,35 +1267,40 @@ struct ktimer_settime_args { int sys_ktimer_settime(struct thread *td, struct ktimer_settime_args *uap) { - struct proc *p =3D td->td_proc; - struct itimer *it; struct itimerspec val, oval, *ovalp; int error; =20 error =3D copyin(uap->value, &val, sizeof(val)); if (error !=3D 0) return (error); -=09 - if (uap->ovalue !=3D NULL) - ovalp =3D &oval; - else - ovalp =3D NULL; + ovalp =3D uap->ovalue !=3D NULL ? &oval : NULL; + error =3D kern_ktimer_settime(td, uap->timerid, uap->flags, &val, ovalp); + if (error =3D=3D 0 && uap->ovalue !=3D NULL) + error =3D copyout(ovalp, uap->ovalue, sizeof(*ovalp)); + return (error); +} =20 +int +kern_ktimer_settime(struct thread *td, int timer_id, int flags, + struct itimerspec *val, struct itimerspec *oval) +{ + struct proc *p; + struct itimer *it; + int error; + + p =3D td->td_proc; PROC_LOCK(p); - if (uap->timerid < 3 || - (it =3D itimer_find(p, uap->timerid)) =3D=3D NULL) { + if (timer_id < 3 || (it =3D itimer_find(p, timer_id)) =3D=3D NULL) { PROC_UNLOCK(p); error =3D EINVAL; } else { PROC_UNLOCK(p); itimer_enter(it); - error =3D CLOCK_CALL(it->it_clockid, timer_settime, - (it, uap->flags, &val, ovalp)); + error =3D CLOCK_CALL(it->it_clockid, timer_settime, (it, + flags, val, oval)); itimer_leave(it); ITIMER_UNLOCK(it); } - if (error =3D=3D 0 && uap->ovalue !=3D NULL) - error =3D copyout(ovalp, uap->ovalue, sizeof(*ovalp)); return (error); } =20 @@ -1312,26 +1313,34 @@ struct ktimer_gettime_args { int sys_ktimer_gettime(struct thread *td, struct ktimer_gettime_args *uap) { - struct proc *p =3D td->td_proc; - struct itimer *it; struct itimerspec val; int error; =20 + error =3D kern_ktimer_gettime(td, uap->timerid, &val); + if (error =3D=3D 0) + error =3D copyout(&val, uap->value, sizeof(val)); + return (error); +} + +int +kern_ktimer_gettime(struct thread *td, int timer_id, struct itimerspec *va= l) +{ + struct proc *p; + struct itimer *it; + int error; + + p =3D td->td_proc; PROC_LOCK(p); - if (uap->timerid < 3 || - (it =3D itimer_find(p, uap->timerid)) =3D=3D NULL) { + if (timer_id < 3 || (it =3D itimer_find(p, timer_id)) =3D=3D NULL) { PROC_UNLOCK(p); error =3D EINVAL; } else { PROC_UNLOCK(p); itimer_enter(it); - error =3D CLOCK_CALL(it->it_clockid, timer_gettime, - (it, &val)); + error =3D CLOCK_CALL(it->it_clockid, timer_gettime, (it, val)); itimer_leave(it); ITIMER_UNLOCK(it); } - if (error =3D=3D 0) - error =3D copyout(&val, uap->value, sizeof(val)); return (error); } =20 @@ -1626,7 +1635,7 @@ itimers_event_hook_exit(void *arg, struct proc *p) panic("unhandled event"); for (; i < TIMER_MAX; ++i) { if ((it =3D its->its_timers[i]) !=3D NULL) - kern_timer_delete(curthread, i); + kern_ktimer_delete(curthread, i); } if (its->its_timers[0] =3D=3D NULL && its->its_timers[1] =3D=3D NULL && diff --git a/sys/kern/uipc_mqueue.c b/sys/kern/uipc_mqueue.c index 73579d3..1439a5d 100644 --- a/sys/kern/uipc_mqueue.c +++ b/sys/kern/uipc_mqueue.c @@ -2235,10 +2235,9 @@ sys_kmq_timedsend(struct thread *td, struct kmq_time= dsend_args *uap) return (error); } =20 -int -sys_kmq_notify(struct thread *td, struct kmq_notify_args *uap) +static int +kern_kmq_notify(struct thread *td, int mqd, struct sigevent *sigev) { - struct sigevent ev; struct filedesc *fdp; struct proc *p; struct mqueue *mq; @@ -2246,34 +2245,31 @@ sys_kmq_notify(struct thread *td, struct kmq_notify= _args *uap) struct mqueue_notifier *nt, *newnt =3D NULL; int error; =20 - p =3D td->td_proc; - fdp =3D td->td_proc->p_fd; - if (uap->sigev) { - error =3D copyin(uap->sigev, &ev, sizeof(ev)); - if (error) - return (error); - if (ev.sigev_notify !=3D SIGEV_SIGNAL && - ev.sigev_notify !=3D SIGEV_THREAD_ID && - ev.sigev_notify !=3D SIGEV_NONE) + if (sigev !=3D NULL) { + if (sigev->sigev_notify !=3D SIGEV_SIGNAL && + sigev->sigev_notify !=3D SIGEV_THREAD_ID && + sigev->sigev_notify !=3D SIGEV_NONE) return (EINVAL); - if ((ev.sigev_notify =3D=3D SIGEV_SIGNAL || - ev.sigev_notify =3D=3D SIGEV_THREAD_ID) && - !_SIG_VALID(ev.sigev_signo)) + if ((sigev->sigev_notify =3D=3D SIGEV_SIGNAL || + sigev->sigev_notify =3D=3D SIGEV_THREAD_ID) && + !_SIG_VALID(sigev->sigev_signo)) return (EINVAL); } - error =3D getmq(td, uap->mqd, &fp, NULL, &mq); + p =3D td->td_proc; + fdp =3D td->td_proc->p_fd; + error =3D getmq(td, mqd, &fp, NULL, &mq); if (error) return (error); again: FILEDESC_SLOCK(fdp); - fp2 =3D fget_locked(fdp, uap->mqd); + fp2 =3D fget_locked(fdp, mqd); if (fp2 =3D=3D NULL) { FILEDESC_SUNLOCK(fdp); error =3D EBADF; goto out; } #ifdef CAPABILITIES - error =3D cap_check(cap_rights(fdp, uap->mqd), CAP_POLL_EVENT); + error =3D cap_check(cap_rights(fdp, mqd), CAP_POLL_EVENT); if (error) { FILEDESC_SUNLOCK(fdp); goto out; @@ -2286,12 +2282,12 @@ again: } mtx_lock(&mq->mq_mutex); FILEDESC_SUNLOCK(fdp); - if (uap->sigev !=3D NULL) { + if (sigev !=3D NULL) { if (mq->mq_notifier !=3D NULL) { error =3D EBUSY; } else { PROC_LOCK(p); - nt =3D notifier_search(p, uap->mqd); + nt =3D notifier_search(p, mqd); if (nt =3D=3D NULL) { if (newnt =3D=3D NULL) { PROC_UNLOCK(p); @@ -2314,10 +2310,10 @@ again: nt->nt_ksi.ksi_flags |=3D KSI_INS | KSI_EXT; nt->nt_ksi.ksi_code =3D SI_MESGQ; nt->nt_proc =3D p; - nt->nt_ksi.ksi_mqd =3D uap->mqd; + nt->nt_ksi.ksi_mqd =3D mqd; notifier_insert(p, nt); } - nt->nt_sigev =3D ev; + nt->nt_sigev =3D *sigev; mq->mq_notifier =3D nt; PROC_UNLOCK(p); /* @@ -2330,7 +2326,7 @@ again: mqueue_send_notification(mq); } } else { - notifier_remove(p, mq, uap->mqd); + notifier_remove(p, mq, mqd); } mtx_unlock(&mq->mq_mutex); =20 @@ -2341,6 +2337,20 @@ out: return (error); } =20 +int +sys_kmq_notify(struct thread *td, struct kmq_notify_args *uap) +{ + struct sigevent ev; + int error; + + if (uap->sigev !=3D NULL) { + error =3D copyin(uap->sigev, &ev, sizeof(ev)); + if (error !=3D 0) + return (error); + } + return (kern_kmq_notify(td, uap->mqd, &ev)); +} + static void mqueue_fdclose(struct thread *td, int fd, struct file *fp) { @@ -2637,6 +2647,7 @@ static struct syscall_helper_data mq_syscalls[] =3D { #ifdef COMPAT_FREEBSD32 #include #include +#include #include #include =20 @@ -2763,12 +2774,33 @@ freebsd32_kmq_timedreceive(struct thread *td, return (error); } =20 +int +freebsd32_kmq_notify(struct thread *td, struct freebsd32_kmq_notify_args *= uap) +{ + struct sigevent ev, *evp; + struct sigevent32 ev32; + int error; + + if (uap->sigev =3D=3D NULL) { + evp =3D NULL; + } else { + error =3D copyin(uap->sigev, &ev32, sizeof(ev32)); + if (error !=3D 0) + return (error); + error =3D convert_sigevent32(&ev32, &ev); + if (error !=3D 0) + return (error); + evp =3D &ev; + } + return (kern_kmq_notify(td, uap->mqd, evp)); +} + static struct syscall_helper_data mq32_syscalls[] =3D { SYSCALL32_INIT_HELPER(freebsd32_kmq_open), SYSCALL32_INIT_HELPER(freebsd32_kmq_setattr), SYSCALL32_INIT_HELPER(freebsd32_kmq_timedsend), SYSCALL32_INIT_HELPER(freebsd32_kmq_timedreceive), - SYSCALL32_INIT_HELPER_COMPAT(kmq_notify), + SYSCALL32_INIT_HELPER(freebsd32_kmq_notify), SYSCALL32_INIT_HELPER_COMPAT(kmq_unlink), SYSCALL_INIT_LAST }; diff --git a/sys/kern/vfs_aio.c b/sys/kern/vfs_aio.c index 5fb9341..862443c 100644 --- a/sys/kern/vfs_aio.c +++ b/sys/kern/vfs_aio.c @@ -2755,31 +2755,6 @@ aiocb32_copyin_old_sigevent(struct aiocb *ujob, stru= ct aiocb *kjob) } =20 static int -convert_sigevent32(struct sigevent32 *sig32, struct sigevent *sig) -{ - - CP(*sig32, *sig, sigev_notify); - switch (sig->sigev_notify) { - case SIGEV_NONE: - break; - case SIGEV_THREAD_ID: - CP(*sig32, *sig, sigev_notify_thread_id); - /* FALLTHROUGH */ - case SIGEV_SIGNAL: - CP(*sig32, *sig, sigev_signo); - break; - case SIGEV_KEVENT: - CP(*sig32, *sig, sigev_notify_kqueue); - CP(*sig32, *sig, sigev_notify_kevent_flags); - PTRIN_CP(*sig32, *sig, sigev_value.sival_ptr); - break; - default: - return (EINVAL); - } - return (0); -} - -static int aiocb32_copyin(struct aiocb *ujob, struct aiocb *kjob) { struct aiocb32 job32; diff --git a/sys/sys/syscallsubr.h b/sys/sys/syscallsubr.h index 75278c3..e18c735 100644 --- a/sys/sys/syscallsubr.h +++ b/sys/sys/syscallsubr.h @@ -228,6 +228,13 @@ int kern_symlink(struct thread *td, char *path, char *= link, enum uio_seg segflg); int kern_symlinkat(struct thread *td, char *path1, int fd, char *path2, enum uio_seg segflg); +int kern_ktimer_create(struct thread *td, clockid_t clock_id, + struct sigevent *evp, int *timerid, int preset_id); +int kern_ktimer_delete(struct thread *, int); +int kern_ktimer_settime(struct thread *td, int timer_id, int flags, + struct itimerspec *val, struct itimerspec *oval); +int kern_ktimer_gettime(struct thread *td, int timer_id, + struct itimerspec *val); int kern_thr_new(struct thread *td, struct thr_param *param); int kern_thr_suspend(struct thread *td, struct timespec *tsp); int kern_truncate(struct thread *td, char *path, enum uio_seg pathseg, --E6cJGRvJdK5HoYjj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR66ROAAoJEJDCuSvBvK1Bl3EP/0DLz7SfXRo4y1ne3u2AJwBv cFVtAgkB9cxdQJ228A9G0Mwo6iEUAlCbFxloYyVCG2Pyuiil+7SCgQ5+VLIGCkIj 4eF9NANztHTs4S3blm3GwauyeoTQAcfXYFB+GMzxtyfjaKyPPkJ39a7jZRC8e2nK yI9C9snJIocawaIObg+sMMkJxIpDWJ01sL22NaAgm4udg+OJFiqJVLPaud+PE7oi jflTZFTpQAlStezpJpjwxp1owNB2jnDcx6wQdbmO280ti9WZNRTFpmT/iV2Ah9ik QQGQ1AxtfCrMoGcbMdrADKJjq+qLI+OH87tEQZv5bK0vivEPRszTdNMAm5sFsJ+a 8SMiM616hIWSjTbANpb0suIB1AsdFgTMTzE1j7yrZ5bi5GLF9yFE5Fmsi09O3QQB lkX9Xqvg6Yvw6FRxDhl8DUDyOuxtWE+1eDhtWOBwDaDTocBxL5QnRb7rE3nQbY8v DQfnfQMy+lk193bpcuXtxjG7cHivaWJ5yKRAktOJuROsrjd05H2vuqiL4D7SC6/5 4cBdjrThoHUpCt4A4QWHygxLZsVTtq+nWZQZpeNmYGoWgy7JMz5xsO3tQMtUCcsR tg8fad2B8mCn2hbwVhx1YLCI3PVIbsW85NbrznGhcwJY7tsbFohl+UoSVIbqB8z1 p3OJYUG6yMrTJGEZy0ri =ABIi -----END PGP SIGNATURE----- --E6cJGRvJdK5HoYjj-- From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 09:30:02 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD8553F6 for ; Sun, 21 Jul 2013 09:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD74E2F for ; Sun, 21 Jul 2013 09:30:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6L9U2Tf009433 for ; Sun, 21 Jul 2013 09:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6L9U1YF009432; Sun, 21 Jul 2013 09:30:01 GMT (envelope-from gnats) Date: Sun, 21 Jul 2013 09:30:01 GMT Message-Id: <201307210930.r6L9U1YF009432@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: Petr Salinger Subject: Re: threads/180652: compat32 problem in clock_getcpuclockid2 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Petr Salinger List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 09:30:02 -0000 The following reply was made to PR threads/180652; it has been noted by GNATS. From: Petr Salinger To: Konstantin Belousov Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/180652: compat32 problem in clock_getcpuclockid2 Date: Sun, 21 Jul 2013 11:20:36 +0200 (CEST) > The bugfix for NULL sigev is applied to both timers and mqueue. > I intend to commit the patch below later today. As mentioned previously, new sys_kmq_notify() also needs ev/evp handling of NULL uap->sigev: > +int > +sys_kmq_notify(struct thread *td, struct kmq_notify_args *uap) > +{ > + struct sigevent ev; > + int error; > + > + if (uap->sigev != NULL) { > + error = copyin(uap->sigev, &ev, sizeof(ev)); > + if (error != 0) > + return (error); > + } > + return (kern_kmq_notify(td, uap->mqd, &ev)); > +} > + Thanks for very quick reactions. Petr From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 15:16:06 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 328D1BEB for ; Sun, 21 Jul 2013 15:16:06 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) by mx1.freebsd.org (Postfix) with ESMTP id EE602356 for ; Sun, 21 Jul 2013 15:16:05 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r6LFFwqb034851; Sun, 21 Jul 2013 11:15:58 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Sun, 21 Jul 2013 11:15:58 -0400 (EDT) Date: Sun, 21 Jul 2013 11:15:58 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Joe Marcus Clarke Subject: Re: Mutexes and error checking In-Reply-To: <51EB5EC4.6050802@marcuscom.com> Message-ID: References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Koop Mast , freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 15:16:06 -0000 On Sun, 21 Jul 2013, Joe Marcus Clarke wrote: > On 7/19/13 1:55 AM, Daniel Eischen wrote: >> On Thu, 18 Jul 2013, Daniel Eischen wrote: >> >> Ugh! I misread the problem when I tried to recreate it and >> test it on Solaris, so forget that last email. >> >> It seems Solaris behaves like Linux with PTHREAD_MUTEX_NORMAL >> and _unlocking_ mutexes owned by other threads (dead or not). >> Solaris only returns EPERM for PTHREAD_MUTEX_ERRORCHECK >> mutexes. > > Given that, should we do the same? I'm testing a patch. Give me a couple of days to get some more cycles. -- DE From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 15:22:02 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9D5F4C98; Sun, 21 Jul 2013 15:22:02 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by mx1.freebsd.org (Postfix) with ESMTP id 624A138D; Sun, 21 Jul 2013 15:22:01 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6LFM1Pg001235; Sun, 21 Jul 2013 11:22:01 -0400 (EDT) Received: from rtp-jclarke-8916.cisco.com (rtp-jclarke-8916.cisco.com [10.117.46.167]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6LFLwcW001248; Sun, 21 Jul 2013 11:21:59 -0400 (EDT) Message-ID: <51EBFC97.6000504@marcuscom.com> Date: Sun, 21 Jul 2013 11:21:59 -0400 From: Joe Marcus Clarke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Koop Mast , freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 15:22:02 -0000 On 7/21/13 11:15 AM, Daniel Eischen wrote: > On Sun, 21 Jul 2013, Joe Marcus Clarke wrote: > >> On 7/19/13 1:55 AM, Daniel Eischen wrote: >>> On Thu, 18 Jul 2013, Daniel Eischen wrote: >>> >>> Ugh! I misread the problem when I tried to recreate it and >>> test it on Solaris, so forget that last email. >>> >>> It seems Solaris behaves like Linux with PTHREAD_MUTEX_NORMAL >>> and _unlocking_ mutexes owned by other threads (dead or not). >>> Solaris only returns EPERM for PTHREAD_MUTEX_ERRORCHECK >>> mutexes. >> >> Given that, should we do the same? > > I'm testing a patch. Give me a couple of days to get > some more cycles. > Thanks! Joe -- PGP Key : http://www.marcuscom.com/pgp.asc From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 16:02:34 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D67D4813; Sun, 21 Jul 2013 16:02:34 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 9F9C1813; Sun, 21 Jul 2013 16:02:34 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 892361203C7; Sun, 21 Jul 2013 18:02:20 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 60E5428494; Sun, 21 Jul 2013 18:02:20 +0200 (CEST) Date: Sun, 21 Jul 2013 18:02:20 +0200 From: Jilles Tjoelker To: Joe Marcus Clarke Subject: Re: Mutexes and error checking Message-ID: <20130721160220.GA38417@stack.nl> References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51EB5EC4.6050802@marcuscom.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Daniel Eischen , Koop Mast , freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 16:02:34 -0000 On Sun, Jul 21, 2013 at 12:08:36AM -0400, Joe Marcus Clarke wrote: > On 7/19/13 1:55 AM, Daniel Eischen wrote: > > It seems Solaris behaves like Linux with PTHREAD_MUTEX_NORMAL > > and _unlocking_ mutexes owned by other threads (dead or not). > > Solaris only returns EPERM for PTHREAD_MUTEX_ERRORCHECK > > mutexes. > Given that, should we do the same? According to http://sourceware.org/glibc/wiki/LockElisionGuide, it seems like glibc wants to change behaviour here. If a mutex is implemented via some sort of transactional memory, it may not work correctly if the mutex is used as a semaphore with a different thread unlocking it. In particular, attempting to commit a transaction via the XEND instruction will cause a general protection fault if no transaction is in progress. Adding software checks against these conditions will use up valuable transactional memory tracking space. So I think allowing pthread_mutex_unlock() by a different thread would be a step backwards. -- Jilles Tjoelker From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 16:28:05 2013 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC42BE39; Sun, 21 Jul 2013 16:28:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BF7BA91D; Sun, 21 Jul 2013 16:28:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA01272; Sun, 21 Jul 2013 19:27:51 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V0wUA-000KBm-Tu; Sun, 21 Jul 2013 19:27:50 +0300 Message-ID: <51EC0BCF.6080501@FreeBSD.org> Date: Sun, 21 Jul 2013 19:26:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Marcus Clarke , Daniel Eischen Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> In-Reply-To: <20130721160220.GA38417@stack.nl> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Koop Mast , freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 16:28:05 -0000 on 21/07/2013 19:02 Jilles Tjoelker said the following: > So I think allowing pthread_mutex_unlock() by a different thread would > be a step backwards. There is something else that bothers me too. Properly written code always "knows" whether it has a lock or not. It does not try to unlock on a whim. Apparently the software in question is not properly written. Nevertheless, it takes care to check return status of pthread_mutex_unlock(). And, to add insult to injury, it depends on OS-specific behavior in doing so. That seems like "two wrongs make a right" thing. I understand that "life is such", etc, but it hurts to see us bend for such a backwards code. -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 16:39:42 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77C681B6; Sun, 21 Jul 2013 16:39:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A55B296C; Sun, 21 Jul 2013 16:39:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6LGdbaV020320; Sun, 21 Jul 2013 19:39:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6LGdbaV020320 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6LGdbWO020319; Sun, 21 Jul 2013 19:39:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jul 2013 19:39:37 +0300 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: Mutexes and error checking Message-ID: <20130721163937.GD5991@kib.kiev.ua> References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oFGQ2VdWvpciDCpb" Content-Disposition: inline In-Reply-To: <20130721160220.GA38417@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Joe Marcus Clarke , Daniel Eischen , freebsd-threads@freebsd.org, Koop Mast X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 16:39:42 -0000 --oFGQ2VdWvpciDCpb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2013 at 06:02:20PM +0200, Jilles Tjoelker wrote: > On Sun, Jul 21, 2013 at 12:08:36AM -0400, Joe Marcus Clarke wrote: > > On 7/19/13 1:55 AM, Daniel Eischen wrote: > > > It seems Solaris behaves like Linux with PTHREAD_MUTEX_NORMAL > > > and _unlocking_ mutexes owned by other threads (dead or not). > > > Solaris only returns EPERM for PTHREAD_MUTEX_ERRORCHECK > > > mutexes. >=20 > > Given that, should we do the same? >=20 > According to http://sourceware.org/glibc/wiki/LockElisionGuide, it seems > like glibc wants to change behaviour here. If a mutex is implemented via > some sort of transactional memory, it may not work correctly if the > mutex is used as a semaphore with a different thread unlocking it. In > particular, attempting to commit a transaction via the XEND instruction > will cause a general protection fault if no transaction is in progress. > Adding software checks against these conditions will use up valuable > transactional memory tracking space. For the XEND, Intel advises to use XTEST before to distinguish between transactional and not transactional executions. The elided unlock routine has to test the value of lock anyway, to distinguish between elided and fallback locking. Then, it is not too hard to add a check for the case 'locked, but not by us', since we have to check to avoid XEND for non-elided locks already. >=20 > So I think allowing pthread_mutex_unlock() by a different thread would > be a step backwards. But this is true regardless of the TSX. --oFGQ2VdWvpciDCpb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR7A7IAAoJEJDCuSvBvK1BsZ4P/jSfrnAgJcy4h2RRdMpzLL4M ERjZI2wEupkjF45NVayRVx9uBDzyd5R7CCL/uK164/9JeHYkDPSZ7XeMWZwpRMTs h7ErRco8mrThqh0nuReIw99vJUTA51xF7ZQhiTVTjIsR1A/SQrzBIMMpGkY0nGvT HGV4NK8fXMas8b5Gcsg+k0kyidyGqt6cql+/iaNL6ANfh8SbOJM9//u0PHVTzMZu jmYO81SNOjl9M8mC3qmDJlbFS5zAHlsIuB6NhEkTg3yg9ZB+WpBwGz6cPAsyFa5L G3FR4d6PKiJjypHI8teAlM7Ne8WiEw0sXs1HocBvY+rDHIl/LcCqjc6Wu7UYClL8 fFxpxJYiJyqOaSEFwmSJ7yf8dD1PC2rKpU0VnOQZp8/I6KxjqyA0HFYoPEvjwqRf C15tstROA2gPM1ODjoUuOczk9hhMbSJuCrFXgeTjzsCtVJXcMpky2EVaHAYvZJcl ewRpmBv81673IEP4h875zna6mF0LWjv3fkSekrPGmiP4TVe22SpWybQ/LB4UnVMj BYs4GCGcQe2QUFa+7FO1M90PqfQOmtz84xCFTYkyahR8V9ajQ+gyUUgSDsdJPyAO jzAGjFJopTQ10SAOm1AT/wcCLxf6ZKmfg6j0scpSVEopIwQQsgo2J7kPdyA9TEvR /WbO07t87hXfULlChIel =M74n -----END PGP SIGNATURE----- --oFGQ2VdWvpciDCpb-- From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 16:48:15 2013 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0A85410; Sun, 21 Jul 2013 16:48:15 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAC59B8; Sun, 21 Jul 2013 16:48:15 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r6LGmENP029585; Sun, 21 Jul 2013 12:48:14 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Sun, 21 Jul 2013 12:48:14 -0400 (EDT) Date: Sun, 21 Jul 2013 12:48:14 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon Subject: Re: Mutexes and error checking In-Reply-To: <51EC0BCF.6080501@FreeBSD.org> Message-ID: References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe Marcus Clarke , Koop Mast , freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 16:48:16 -0000 On Sun, 21 Jul 2013, Andriy Gapon wrote: > on 21/07/2013 19:02 Jilles Tjoelker said the following: >> So I think allowing pthread_mutex_unlock() by a different thread would >> be a step backwards. > > There is something else that bothers me too. > Properly written code always "knows" whether it has a lock or not. It does not > try to unlock on a whim. Apparently the software in question is not properly > written. Nevertheless, it takes care to check return status of > pthread_mutex_unlock(). And, to add insult to injury, it depends on OS-specific > behavior in doing so. That seems like "two wrongs make a right" thing. > > I understand that "life is such", etc, but it hurts to see us bend for such a > backwards code. I agree that this seems like broken software (threads releasing locks they don't own), but _if_ PTHREAD_MUTEX_NORMAL was explicitly set by the software, it could mean two things: o Assumption that PTHREAD_MUTEX_NORMAL mutexes are inherently faster than PTHREAD_MUTEX_DEFAULT, or o The behavior of this type of mutex, at least in regard to the unlock, is desired. For the latter case, I'm thinking specifically of thread-safe libraries. Maybe they don't care (in these unlock cases) because they know at the time that whatever the mutexes are protecting is stable. They could use robust mutexes, but they may not be as widely implemented. I think most folks assume that PTHREAD_MUTEX_NORMAL are the faster of the POSIX specified mutex types, but POSIX makes no such guarantee. I think perhaps they need a PTHREAD_MUTEX_FAST or to just specify that it is the implementations fastest type of POSIX mutex. -- DE From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 18:30:01 2013 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1ECFFCDB; Sun, 21 Jul 2013 18:30:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F0C6DC77; Sun, 21 Jul 2013 18:29:59 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA02011; Sun, 21 Jul 2013 21:29:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V0yOL-000KLU-25; Sun, 21 Jul 2013 21:29:57 +0300 Message-ID: <51EC286D.4080208@FreeBSD.org> Date: Sun, 21 Jul 2013 21:29:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Joe Marcus Clarke , Koop Mast , freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 18:30:01 -0000 on 21/07/2013 19:48 Daniel Eischen said the following: > On Sun, 21 Jul 2013, Andriy Gapon wrote: > >> on 21/07/2013 19:02 Jilles Tjoelker said the following: >>> So I think allowing pthread_mutex_unlock() by a different thread would >>> be a step backwards. >> >> There is something else that bothers me too. >> Properly written code always "knows" whether it has a lock or not. It does not >> try to unlock on a whim. Apparently the software in question is not properly >> written. Nevertheless, it takes care to check return status of >> pthread_mutex_unlock(). And, to add insult to injury, it depends on OS-specific >> behavior in doing so. That seems like "two wrongs make a right" thing. >> >> I understand that "life is such", etc, but it hurts to see us bend for such a >> backwards code. > > I agree that this seems like broken software (threads releasing > locks they don't own), but _if_ PTHREAD_MUTEX_NORMAL was > explicitly set by the software, it could mean two things: > > o Assumption that PTHREAD_MUTEX_NORMAL mutexes are > inherently faster than PTHREAD_MUTEX_DEFAULT, or > > o The behavior of this type of mutex, at least in > regard to the unlock, is desired. > > For the latter case, I'm thinking specifically of thread-safe > libraries. Maybe they don't care (in these unlock cases) because > they know at the time that whatever the mutexes are protecting > is stable. They could use robust mutexes, but they may not > be as widely implemented. > > I think most folks assume that PTHREAD_MUTEX_NORMAL are > the faster of the POSIX specified mutex types, but POSIX > makes no such guarantee. I think perhaps they need a > PTHREAD_MUTEX_FAST or to just specify that it is the > implementations fastest type of POSIX mutex. Well, my opinion is that either you want error checking or not. In the former case you use robust mutex and do other kinds of checks (like return code of pthread_* functions), in the latter case you use normal mutex, but then you don't do any return code checking. Mixing the two approaches and expecting something sane is... insane :-) JIMHO, of course. -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 20:52:14 2013 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF00C815; Sun, 21 Jul 2013 20:52:14 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by mx1.freebsd.org (Postfix) with ESMTP id A0E55231; Sun, 21 Jul 2013 20:52:14 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6LKqCin001728; Sun, 21 Jul 2013 16:52:12 -0400 (EDT) Received: from rtp-jclarke-8916.cisco.com (rtp-jclarke-8916.cisco.com [10.117.46.167]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6LKq9VB024556; Sun, 21 Jul 2013 16:52:09 -0400 (EDT) Message-ID: <51EC49F8.6070207@marcuscom.com> Date: Sun, 21 Jul 2013 16:52:08 -0400 From: Joe Marcus Clarke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> In-Reply-To: <51EC0BCF.6080501@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Koop Mast , freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 20:52:14 -0000 On 7/21/13 12:26 PM, Andriy Gapon wrote: > on 21/07/2013 19:02 Jilles Tjoelker said the following: >> So I think allowing pthread_mutex_unlock() by a different thread would >> be a step backwards. > > There is something else that bothers me too. > Properly written code always "knows" whether it has a lock or not. It does not > try to unlock on a whim. Apparently the software in question is not properly > written. Nevertheless, it takes care to check return status of > pthread_mutex_unlock(). And, to add insult to injury, it depends on OS-specific > behavior in doing so. That seems like "two wrongs make a right" thing. The specifics are this. There are some GNOME/GTK+/GLib apps that are crashing now that GLib checks the return of pthread_mutex_unlock() in g_mutex_unlock(). While we can workaround this in GLib by simply nop'ing the EPERM return, we'd like to pursue something that may be a bit more manageable for those apps written for Linux that do not use GLib. Again, I'm not arguing the voracity of the 3rd party app code, just the discrepancy between Linux and Solaris compared to FreeBSD. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc From owner-freebsd-threads@FreeBSD.ORG Mon Jul 22 11:06:53 2013 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA4144C0 for ; Mon, 22 Jul 2013 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B6AFE24B5 for ; Mon, 22 Jul 2013 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6MB6rhK053869 for ; Mon, 22 Jul 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6MB6reV053867 for freebsd-threads@FreeBSD.org; Mon, 22 Jul 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Jul 2013 11:06:53 GMT Message-Id: <201307221106.r6MB6reV053867@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 11:06:53 -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 threa/180652 threads [patch] compat32 problem in clock_getcpuclockid2 o threa/180496 threads clock_gettime() does not return CPU-time for zombie pr o threa/179158 threads ruby19 segfaults during build on ppc64 o threa/168417 threads pthread_getcpuclockid() does not work to specification o threa/163512 threads libc defaults to single threaded o threa/160708 threads possible security problem with RLIMIT_VMEM o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/30464 threads [patch] pthread mutex attributes -- pshared 20 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Jul 23 15:53:56 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD8C9429; Tue, 23 Jul 2013 15:53:56 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 3C15F2612; Tue, 23 Jul 2013 15:53:55 +0000 (UTC) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.5/8.14.5) with ESMTP id r6NFhT0E085559; Tue, 23 Jul 2013 16:43:29 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id r6NFhS6p007389; Tue, 23 Jul 2013 16:43:28 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id r6NFhS7n007384; Tue, 23 Jul 2013 16:43:28 +0100 Date: Tue, 23 Jul 2013 16:43:28 +0100 Message-Id: <201307231543.r6NFhS7n007384@higson.cam.lispworks.com> From: Martin Simmons To: Joe Marcus Clarke In-reply-to: <51EC49F8.6070207@marcuscom.com> (message from Joe Marcus Clarke on Sun, 21 Jul 2013 16:52:08 -0400) Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> <51EC49F8.6070207@marcuscom.com> Cc: deischen@freebsd.org, kwm@rainbow-runner.nl, avg@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:53:56 -0000 >>>>> On Sun, 21 Jul 2013 16:52:08 -0400, Joe Marcus Clarke said: > > The specifics are this. There are some GNOME/GTK+/GLib apps that are > crashing now that GLib checks the return of pthread_mutex_unlock() in > g_mutex_unlock(). While we can workaround this in GLib by simply > nop'ing the EPERM return, we'd like to pursue something that may be a > bit more manageable for those apps written for Linux that do not use GLib. Which apps are broken and why can't they be fixed? > Again, I'm not arguing the voracity of the 3rd party app code, just the > discrepancy between Linux and Solaris compared to FreeBSD. Note that unlocking an unlocked normal mutex on Linux (glibc) does *not* work, but leaves it in a subtly inconsistent state. Therefore bugs like the one you reported to the GNOME Bugzilla (https://bugzilla.gnome.org/show_bug.cgi?id=678758) should be fixed, not ignored by hiding the error status. __Martin From owner-freebsd-threads@FreeBSD.ORG Tue Jul 23 16:18:20 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 646B1785 for ; Tue, 23 Jul 2013 16:18:20 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AA3927FA for ; Tue, 23 Jul 2013 16:18:19 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6NGIIav024176 for ; Tue, 23 Jul 2013 12:18:18 -0400 (EDT) Received: from dhcp-10-150-54-149.cisco.com (dhcp-10-150-54-149.cisco.com [10.150.54.149]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6NGIHqs008445; Tue, 23 Jul 2013 12:18:17 -0400 (EDT) Message-ID: <51EEACC9.8000406@marcuscom.com> Date: Tue, 23 Jul 2013 12:18:17 -0400 From: Joe Marcus Clarke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Simmons Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> <51EC49F8.6070207@marcuscom.com> <201307231543.r6NFhS7n007384@higson.cam.lispworks.com> In-Reply-To: <201307231543.r6NFhS7n007384@higson.cam.lispworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: deischen@freebsd.org, kwm@rainbow-runner.nl, avg@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:18:20 -0000 On 7/23/13 11:43 AM, Martin Simmons wrote: >>>>>> On Sun, 21 Jul 2013 16:52:08 -0400, Joe Marcus Clarke said: >> >> The specifics are this. There are some GNOME/GTK+/GLib apps that are >> crashing now that GLib checks the return of pthread_mutex_unlock() in >> g_mutex_unlock(). While we can workaround this in GLib by simply >> nop'ing the EPERM return, we'd like to pursue something that may be a >> bit more manageable for those apps written for Linux that do not use GLib. > > Which apps are broken and why can't they be fixed? Koop, do you have a complete list? The one that was reported to me was sonata (a Python app). I have not yet traced down the offending code as I was curious why Linux was not failing, and this appears to be why. Joe > > >> Again, I'm not arguing the voracity of the 3rd party app code, just the >> discrepancy between Linux and Solaris compared to FreeBSD. > > Note that unlocking an unlocked normal mutex on Linux (glibc) does *not* work, > but leaves it in a subtly inconsistent state. Therefore bugs like the one you > reported to the GNOME Bugzilla > (https://bugzilla.gnome.org/show_bug.cgi?id=678758) should be fixed, not > ignored by hiding the error status. > > __Martin > -- PGP Key : http://www.marcuscom.com/pgp.asc From owner-freebsd-threads@FreeBSD.ORG Tue Jul 23 16:45:18 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 10CA5F58; Tue, 23 Jul 2013 16:45:18 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C668E2948; Tue, 23 Jul 2013 16:45:17 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r6NGjFr5011890; Tue, 23 Jul 2013 12:45:15 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Tue, 23 Jul 2013 12:45:16 -0400 (EDT) Date: Tue, 23 Jul 2013 12:45:15 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Joe Marcus Clarke Subject: Re: Mutexes and error checking In-Reply-To: <51EEACC9.8000406@marcuscom.com> Message-ID: References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> <51EC49F8.6070207@marcuscom.com> <201307231543.r6NFhS7n007384@higson.cam.lispworks.com> <51EEACC9.8000406@marcuscom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: kwm@rainbow-runner.nl, avg@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:45:18 -0000 On Tue, 23 Jul 2013, Joe Marcus Clarke wrote: > On 7/23/13 11:43 AM, Martin Simmons wrote: >>>>>>> On Sun, 21 Jul 2013 16:52:08 -0400, Joe Marcus Clarke said: >>> >>> The specifics are this. There are some GNOME/GTK+/GLib apps that are >>> crashing now that GLib checks the return of pthread_mutex_unlock() in >>> g_mutex_unlock(). While we can workaround this in GLib by simply >>> nop'ing the EPERM return, we'd like to pursue something that may be a >>> bit more manageable for those apps written for Linux that do not use GLib. >> >> Which apps are broken and why can't they be fixed? > > Koop, do you have a complete list? The one that was reported to me was > sonata (a Python app). I have not yet traced down the offending code as > I was curious why Linux was not failing, and this appears to be why. FYI, here is a very lighty tested patch that allows an unlock on a PTHREAD_MUTEX_NORMAL mutex by a non-owning thread: http://people.freebsd.org/~deischen/libthr_mutex_normal.diffs I do not argue for or against this behavior in making this patch, as I can see both sides of the argument. -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Jul 24 10:53:44 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95EE4C6B; Wed, 24 Jul 2013 10:53:44 +0000 (UTC) (envelope-from kwm@rainbow-runner.nl) Received: from fep18.mx.upcmail.net (fep18.mx.upcmail.net [62.179.121.38]) by mx1.freebsd.org (Postfix) with ESMTP id 94C222952; Wed, 24 Jul 2013 10:53:43 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep18-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130724105336.MIYO26154.viefep18-int.chello.at@edge01.upcmail.net>; Wed, 24 Jul 2013 12:53:36 +0200 Received: from crashalot.rainbow-runner.nl ([178.84.132.32]) by edge01.upcmail.net with edge id 4Atb1m00Q0i5fp601Atbvn; Wed, 24 Jul 2013 12:53:36 +0200 X-SourceIP: 178.84.132.32 Message-ID: <51EFB228.20907@rainbow-runner.nl> Date: Wed, 24 Jul 2013 12:53:28 +0200 From: Koop Mast User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Marcus Clarke Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> <51EC49F8.6070207@marcuscom.com> <201307231543.r6NFhS7n007384@higson.cam.lispworks.com> <51EEACC9.8000406@marcuscom.com> In-Reply-To: <51EEACC9.8000406@marcuscom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: deischen@freebsd.org, avg@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 10:53:44 -0000 On 07/23/13 18:18, Joe Marcus Clarke wrote: > On 7/23/13 11:43 AM, Martin Simmons wrote: >>>>>>> On Sun, 21 Jul 2013 16:52:08 -0400, Joe Marcus Clarke said: >>> The specifics are this. There are some GNOME/GTK+/GLib apps that are >>> crashing now that GLib checks the return of pthread_mutex_unlock() in >>> g_mutex_unlock(). While we can workaround this in GLib by simply >>> nop'ing the EPERM return, we'd like to pursue something that may be a >>> bit more manageable for those apps written for Linux that do not use GLib. >> Which apps are broken and why can't they be fixed? > Koop, do you have a complete list? The one that was reported to me was > sonata (a Python app). I have not yet traced down the offending code as > I was curious why Linux was not failing, and this appears to be why. > > Joe I only am aware of audio/sonata currently. I can remember seeing a similar error once or twice before. So while looking for more failures like the one in sonata, I ran into a fix for sonata in the OpenBSD ports [1]. . I also found the same solution was fixed in lxpanel [2]. The fix is to use the |GDK| mutual exclusion lock to prevent more then one thread being active [3]. With this I can fix the few ports that exhibit this problem and we don't have to change anything in base. -Koop [1] http://www.openbsd.org/cgi-bin/cvsweb/ports/audio/sonata/patches/patch-sonata_main_py?rev=1.5;content-type=text%2Fplain [2] https://github.com/hsgg/lxpanel/commit/75f5e575e692818869cb3d7fded6f42c735f6954 [3] http://www.pygtk.org/docs/pygtk/gdk-functions.html#function-gdk--threads-enter >> >>> Again, I'm not arguing the voracity of the 3rd party app code, just the >>> discrepancy between Linux and Solaris compared to FreeBSD. >> Note that unlocking an unlocked normal mutex on Linux (glibc) does *not* work, >> but leaves it in a subtly inconsistent state. Therefore bugs like the one you >> reported to the GNOME Bugzilla >> (https://bugzilla.gnome.org/show_bug.cgi?id=678758) should be fixed, not >> ignored by hiding the error status. >> >> __Martin >> >