From owner-freebsd-threads@FreeBSD.ORG Sun Nov 23 01:38:40 2014 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A169CBDC for ; Sun, 23 Nov 2014 01:38:40 +0000 (UTC) Received: from a2-salada3.whservidor.com (a2-salada3-revenda-linux.whservidor.com [200.147.33.218]) by mx1.freebsd.org (Postfix) with ESMTP id 2104FEAB for ; Sun, 23 Nov 2014 01:38:37 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by a2-salada3.whservidor.com (Postfix) with ESMTP id 464461C006CB for ; Sat, 22 Nov 2014 23:38:30 -0200 (BRST) Received: from a2-salada3.whservidor.com ([127.0.0.1]) by localhost (a2-salada3.host.intranet [127.0.0.1]) (UOL-patch-amavisd-new, port 10024) with ESMTP id dfez0SOJoyxM for ; Sat, 22 Nov 2014 23:38:30 -0200 (BRST) Received: from a1-cpweb-a55.host.intranet (cpweb0055.servidorwebfacil.com [200.98.246.55]) by a2-salada3.whservidor.com (Postfix) with ESMTP id F06AC1C00043 for ; Sat, 22 Nov 2014 23:38:29 -0200 (BRST) Received: from iwebmast by a1-cpweb-a55.host.intranet with local (Exim 4.80) (envelope-from ) id 1XsM8D-0000dh-9y for freebsd-threads@freebsd.org; Sat, 22 Nov 2014 23:38:29 -0200 To: freebsd-threads@freebsd.org Subject: FREE, Delivery Status Notification 0000679228 X-PHP-Script: iwebmaster.com.br/post.php for 87.106.28.133 Mime-Version: 1.0 From: "FedEx International Next Flight" Reply-To: "FedEx International Next Flight" Message-Id: <768982ef0600ac57f0c9eb2397c135ce@iwebmaster.com.br> Date: Sun, 23 Nov 2014 05:38:35 +0400 X-SIG5: 2101e1ad7b02eb3b0ceff2c1fe7aef27 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 01:38:40 -0000 Dear Free, =20 Courier was unable to deliver the parcel to you. You can review complete details of your order in the find attached. =20 Sincerely, Nathan Oneill, Sr. Delivery Agent. =20 (c) 1995-2014 FedEx. The content of this message is protected by copyright = and trademark laws under U.S. and international law. From owner-freebsd-threads@FreeBSD.ORG Mon Nov 24 08:00:39 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27E4B4A9 for ; Mon, 24 Nov 2014 08:00:39 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 136DCBEF for ; Mon, 24 Nov 2014 08:00:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAO80dKD025607 for ; Mon, 24 Nov 2014 08:00:39 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201411240800.sAO80dKD025607@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [FreeBSD Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 24 Nov 2014 08:00:39 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 08:00:39 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (24 bugs) Bug 193367: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 Severity: Affects Only Me Priority: Normal Hardware: i386 Assignee: freebsd-threads@FreeBSD.org Status: New Resolution: Summary: [panic] sleeping thread Bug 194514: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194514 Severity: Affects Many People Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: New Resolution: Summary: Make the message 'Thread %p has exited with leftover' more informative Bug 192686: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192686 Severity: Affects Many People Priority: --- Hardware: i386 Assignee: freebsd-threads@FreeBSD.org Status: New Resolution: Summary: Segfaults using combinations of -pie -pthread -lm(|_p) when profiling Bug 195098: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195098 Severity: Affects Some People Priority: --- Hardware: amd64 Assignee: freebsd-threads@FreeBSD.org Status: New Resolution: Summary: pthread lock performance degradation Bug 30464: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=30464 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: [patch] pthread mutex attributes -- pshared Bug 79683: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=79683 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: svctcp_create() fails if multiple threads call at the same time, it's not thread-safe Bug 80992: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=80992 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: abort() sometimes not caught by gdb depending on thread library Bug 103975: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=103975 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: Implicit loading/unloading of libpthread.so may crash user processes Bug 110306: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=110306 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: apache 2.0 segmentation violation when calling gethostbyname Bug 115211: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=115211 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: pthread_atfork misbehaves in initial thread Bug 116668: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=116668 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: can no longer use jdk15 with libthr on -stable SMP Bug 121336: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121336 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: lang/neko threading ok on UP, broken on SMP (FreeBSD 7) Bug 122923: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=122923 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: 'nice' does not prevent background process from stealing CPU from foreground Bug 128922: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128922 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: threads hang with xorg running Bug 135673: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=135673 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: databases/mysql50-server - MySQL query lock-ups on 7.2-RELEASE amd64 Bug 141721: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=141721 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: rtprio(1): (id|rt)prio priority resets when new thread is created Bug 148515: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148515 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: Memory / syslog strangeness in FreeBSD 8.x ( possible leak/ threading issue ) Bug 150959: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=150959 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: [libc] Stub pthread_once in libc should call _libc_once Bug 160708: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=160708 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: possible security problem with RLIMIT_VMEM Bug 163512: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163512 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: libc defaults to single threaded Bug 168417: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168417 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: pthread_getcpuclockid() does not work to specification Bug 180496: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180496 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: clock_gettime() does not return CPU-time for zombie processes Bug 180652: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180652 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: [kernel] [patch] compat32 problem in clock_getcpuclockid2 Bug 184073: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184073 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-threads@FreeBSD.org Status: In Progress Resolution: Summary: wrong signal delivery to multithreaded processes in Perl From owner-freebsd-threads@FreeBSD.ORG Wed Nov 26 22:12:38 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 622F02DE; Wed, 26 Nov 2014 22:12:38 +0000 (UTC) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.233.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00E0AB55; Wed, 26 Nov 2014 22:12:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=three; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=OXLNRk8KSA6NH8Lit0offkPZ6TWuhShwHkSAY+9TMJQ=; b=HvLrniC/5+eEHbyls7bkB45I7FG2SRtfOIzbF92tkcG9uvsewJN5vcSZQeJ8GTcSVzT24uZSS7MdOInuuZHjUeF9cu2p526fm0gNgmtSMzGOWYx24oP/a3bg6o2o28I6EwxONJXV2NX2coJTl5J+v0DYD8tHGgoYKKhMVllr5NpwiGZ7JqXWWTn1DcBm3/8i2yL6r3L+Hk0Pwj2j3yYej0Mm8cDJQjRwHaCm53G/Iov22AHxdyeJ4Azy62sYQFEjS13gkOcR6GCuht7rEL3jmGNgwSwXgG7hcwNGxxkPhES8lUylR8GjrjwFcZSdPXIbO7wv0dThp9jwwhOjY/BfG8hbPXNDGq5lD5zkpRPhhY4ZiOu4kAkjl2tqp/RvZPPz/DJr/dPrckiN80KDplRcPMWmFceGqAHcTuJBHCa0NnNAGE+Xp0BQEzVP5ErXLLpUcUmjMocx8y2+wx8P8cWmUh0Ob8vkD/G94me48x7fGHFrCRz4awuhhP00hIbIIOWj2ehowmRY9lXLupPADdRk86EplqLaqfV1nmw9nEbzebhaUMRTa+GCbsiznedcU0lNqrPSM710lU835BsIzYSN6InjNPIsW0LtvWBw+FjjvWZ0ohGpsdxzQDbEGDlf1CXlg2SfZGpSDRrMnBbl+HRht5j22AdxXjECWwp+HkeerWU=; Received: from light.codelabs.ru (v-light.codelabs.ru [144.206.233.83]) by 0.mx.codelabs.ru with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1Xtkp9-000C3m-2v; Thu, 27 Nov 2014 02:12:35 +0400 Date: Thu, 27 Nov 2014 01:12:31 +0300 From: Eygene Ryabinkin To: Konstantin Belousov Subject: Re: [CFR][PATCH] Call proper signal handler from libthr for non-SA_SIGINFO case Message-ID: References: <20141120194925.GK17068@kib.kiev.ua> <20141121165658.GP17068@kib.kiev.ua> <20141121203227.GS17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <20141121203227.GS17068@kib.kiev.ua> Sender: rea@codelabs.ru Cc: davidxu@FreeBSD.org, freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 22:12:38 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Konstantin, good day. Fri, Nov 21, 2014 at 10:32:27PM +0200, Konstantin Belousov wrote: > On Fri, Nov 21, 2014 at 10:55:55PM +0300, Eygene Ryabinkin wrote: > > If there is no change in behaviour that will arise from rearranging > > the order of calls to mach-dependent and mach-independent code, > > I'd go a bit firther and unify some repeated code, > > http://codelabs.ru/fbsd/patches/libthr/11-CURRENT-fix-SIGINFO-process= ing-with-RESETHAND-v2.diff > >=20 > > Works for me too, just tested with the same Squid installation. > > This looks correct, but is much more delicate change. > In particular, the signal mask copied to usermode as part of > ucontext, for restoration at sigreturn(2), seems to be correct in > both cases, but in the postsig() case, where sendsig_common() is put > after sv_sendsig() call, it depends on the returnmask calculation. Since in original (unmodified) code returnmask is calculated before the call to kern_sigprocmask(), {{{ if (td->td_pflags & TDP_OLDMASK) { returnmask =3D td->td_oldsigmask; td->td_pflags &=3D ~TDP_OLDMASK; } else returnmask =3D td->td_sigmask; mask =3D ps->ps_catchmask[_SIG_IDX(sig)]; if (!SIGISMEMBER(ps->ps_signodefer, sig)) SIGADDSET(mask, sig); kern_sigprocmask(td, SIG_BLOCK, &mask, NULL, SIGPROCMASK_PROC_LOCKED | SIGPROCMASK_PS_LOCKED); if (SIGISMEMBER(ps->ps_sigreset, sig)) sigdflt(ps, sig); td->td_ru.ru_nsignals++; if (p->p_sig =3D=3D sig) { p->p_code =3D 0; p->p_sig =3D 0; } (*p->p_sysent->sv_sendsig)(action, &ksi, &returnmask); }}} and kern_sigprocmask() only touches td->td_sigmask, such change should be safe, because mach-dependent handlers do not use or manipulate td_sigmask. This looks logical, because we want to pass current original signal mask for the thread to sv_sendsig() to make it to be restored after signal handler's work. So returnmask is to be calculated before mangling and should not depend on it. > Can you test that signal mask after signal return is correct with your > patch? Tested with the following code: http://codelabs.ru/fbsd/patches/libthr/kern-sig-test-sigmask-restoration.c All tested masks are restored properly both for modified and unmodified kernels. > Two other notes about your patch, which should be changed before it is > committable. First, the name sendsig_common() is not telling anything. > Might be, rename the function to postsig_sigprop() or like. >=20 > In the same vein, comment is too ambitious for small helper. This is not > The common code, just a helper to handle thread signal mask and several > other details of delivery. Just specifying that this is the thing to > call after sysent->sv_sendsig() to arrange for proper bookkeeping, is > enough. Changed it to sendsig_adjust that should carry more sense. Also modified comment. > Second, function needs asserts that process lock and sigact mutex > (ps_mtx) are locked. Added them too. New patch is at http://codelabs.ru/fbsd/patches/libthr/11-CURRENT-fix-SIGINFO-processing-= with-RESETHAND-v3.diff Thanks! --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --DocE+STaALJfprDB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iL4EABEKAGYFAlR2UE9fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDgyRkUwNkJDRDQ5N0MwREU0OUVDNEZGMDE2 QUY5RUFFODE1MkVDRkIACgkQFq+eroFS7Pv3mgD/ewMG9CFOtosyKsUxdNk5ooZ1 UpypzuLV4ZBzyWT7ZQMA/1XU/oFd/jwkQYTSZnfBY4zXZeqwWyVhKuNNKOAX9GyZ =Dqzb -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-threads@FreeBSD.ORG Wed Nov 26 22:17:40 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0BC634D; Wed, 26 Nov 2014 22:17:40 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6BFCBB78; Wed, 26 Nov 2014 22:17:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAQMHZPc066908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2014 00:17:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAQMHZPc066908 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAQMHZSK066907; Thu, 27 Nov 2014 00:17:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Nov 2014 00:17:35 +0200 From: Konstantin Belousov To: Eygene Ryabinkin Subject: Re: [CFR][PATCH] Call proper signal handler from libthr for non-SA_SIGINFO case Message-ID: <20141126221734.GM17068@kib.kiev.ua> References: <20141120194925.GK17068@kib.kiev.ua> <20141121165658.GP17068@kib.kiev.ua> <20141121203227.GS17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: davidxu@FreeBSD.org, freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 22:17:41 -0000 On Thu, Nov 27, 2014 at 01:12:31AM +0300, Eygene Ryabinkin wrote: > > Added them too. New patch is at > http://codelabs.ru/fbsd/patches/libthr/11-CURRENT-fix-SIGINFO-processing-with-RESETHAND-v3.diff > You went silent for several days, I committed the modified patch earlier as r275120. Thank you. From owner-freebsd-threads@FreeBSD.ORG Thu Nov 27 04:21:28 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17D5D80B; Thu, 27 Nov 2014 04:21:28 +0000 (UTC) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.233.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAC805F7; Thu, 27 Nov 2014 04:21:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=three; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=10ZQOghPJtFrx5lzqCXAVpOEp0F7V/ooQS0yUJg1SH8=; b=gn0Doh6wvqYJw2GB6tURMB9WU0oClcCl9v9gQxopnExiz97MJ3hJTZPd3+wlFW9VGiDlMec8uVduQLwUAq30ig3K4c0gnvwi4QQMt9Vjnqb4i6FQbFQl1NOqrNYXLTXjEG21uouvm7bFz0+iK5I/IMCrtMb6NxrSkFjcgyotDWrUpM+JPfMiwrsgtjocC/u8hQs1tlnTvpvmoMsiu13MkZBRatn3lQt6zQOQ9VJL7sKPheLnOnHqu3SalKH9isjiY2Mx5SDZ3D/6w0b05w3fU0Nm8bwN7wqjvKDJ9YfwGbdUmZqNHAxlxQrAhdg7ckrQK5ybKnhneMzwGnMGYEXWy1xYM35ONOklj1+mqToarowRrfy8KPiSu/r4IFzCv7PRk0sil/lYUBmlgK0FuQR6vJDDbSgUz0GS3GNrmHGy0KAPdkNcIUoKb26L/cZjKPyuvzPDTernCqG5sWBkc8bUMvWH1Xok67Z1WkEDm5QA7CtIcPxfk2YLUmgNpwLxYSku5EMKKoq+a5uSCXmSQxk9yaLrX6Rsvrh3tsVaAuU5xLTGVFAa+zOZ7RqBkYjDxZz2EGyIv3qpA7mO4d9WIkf2/09gXgRoNTB/q6hH1k8fY7mnt4UxFBUv80VEpuGpgtNIj29L7ESSNQcql8dRq5q7k7oFRiBYJN7/8ZsZMMpa/pg=; Received: from light.codelabs.ru (v-light.codelabs.ru [144.206.233.83]) by 0.mx.codelabs.ru with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1XtqZy-000IHE-QT; Thu, 27 Nov 2014 08:21:19 +0400 Date: Thu, 27 Nov 2014 07:21:14 +0300 From: Eygene Ryabinkin To: Konstantin Belousov Subject: Re: [CFR][PATCH] Call proper signal handler from libthr for non-SA_SIGINFO case Message-ID: References: <20141120194925.GK17068@kib.kiev.ua> <20141121165658.GP17068@kib.kiev.ua> <20141121203227.GS17068@kib.kiev.ua> <20141126221734.GM17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline In-Reply-To: <20141126221734.GM17068@kib.kiev.ua> Sender: rea@codelabs.ru Cc: davidxu@FreeBSD.org, freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 04:21:28 -0000 --5I6of5zJg18YgZEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thu, Nov 27, 2014 at 12:17:35AM +0200, Konstantin Belousov wrote: > On Thu, Nov 27, 2014 at 01:12:31AM +0300, Eygene Ryabinkin wrote: > >=20 > > Added them too. New patch is at > > http://codelabs.ru/fbsd/patches/libthr/11-CURRENT-fix-SIGINFO-process= ing-with-RESETHAND-v3.diff > >=20 >=20 > You went silent for several days, I committed the modified patch > earlier as r275120. >=20 > Thank you. Fine, thanks a lot! "td->td_ru.ru_nsignals++;" perhaps doesn't belong to the new function, but it is a matter of taste. By the way, shouldn't "PROC_LOCK_ASSERT(td->td_proc, MA_OWNED);" be also present single kern_sigprocmask() is called with SIGPROCMASK_PROC_LOCKED? --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --5I6of5zJg18YgZEa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iL4EABEKAGYFAlR2prpfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDgyRkUwNkJDRDQ5N0MwREU0OUVDNEZGMDE2 QUY5RUFFODE1MkVDRkIACgkQFq+eroFS7PuvnAD+JCDxuJAOy4rdPwYJaUMBMnGL MlbJrJSFUIH1MgEaKKMA/iBw7JFiLvBtJ1jO14Y4quMy6j6ehRIyXVjVziA4+hVv =Hyos -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa-- From owner-freebsd-threads@FreeBSD.ORG Thu Nov 27 10:14:11 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6B00AC4; Thu, 27 Nov 2014 10:14:11 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 68EE7B22; Thu, 27 Nov 2014 10:14:11 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sARAE6vo025493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2014 12:14:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sARAE6vo025493 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sARAE6P4025492; Thu, 27 Nov 2014 12:14:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Nov 2014 12:14:06 +0200 From: Konstantin Belousov To: Eygene Ryabinkin Subject: Re: [CFR][PATCH] Call proper signal handler from libthr for non-SA_SIGINFO case Message-ID: <20141127101405.GP17068@kib.kiev.ua> References: <20141120194925.GK17068@kib.kiev.ua> <20141121165658.GP17068@kib.kiev.ua> <20141121203227.GS17068@kib.kiev.ua> <20141126221734.GM17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: davidxu@FreeBSD.org, freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 10:14:12 -0000 On Thu, Nov 27, 2014 at 07:21:14AM +0300, Eygene Ryabinkin wrote: > "td->td_ru.ru_nsignals++;" perhaps doesn't belong to the new function, > but it is a matter of taste. By the way, shouldn't Well, there is no common theme in the operations done in the postsig_done(), except some fiddling with the signal state after the frame is pushed to usermode stack. I have trouble formulating the purpose of the function in the introductory comment, due to this. ru_nsignals++ is not better or worse than any other operation performed. > "PROC_LOCK_ASSERT(td->td_proc, MA_OWNED);" be also present single > kern_sigprocmask() is called with SIGPROCMASK_PROC_LOCKED? This is what I suggested in my earlier mail. When I started looking into details, I decided not to do it. The reasoning is that the function itself touches no process state protected by the proc lock. It is kern_sigprocmask which works with process lock-protected data. On the other hand, the function works with p_sigacts, which is covered by ps_mtx, and I asserted it. I believe that the following patch is due. It is better way to ensure the invariants, instead of adding assert to postsig_done(). diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 15638e0..502f334 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -998,8 +998,12 @@ kern_sigprocmask(struct thread *td, int how, sigset_t *set, sigset_t *oset, int error; p = td->td_proc; - if (!(flags & SIGPROCMASK_PROC_LOCKED)) + if ((flags & SIGPROCMASK_PROC_LOCKED) != 0) + PROC_LOCK_ASSERT(p, MA_OWNED); + else PROC_LOCK(p); + mtx_assert(&p->p_sigacts->ps_mtx, (flags & SIGPROCMASK_PS_LOCKED) != 0 + ? MA_OWNED : MA_NOTOWNED); if (oset != NULL) *oset = td->td_sigmask; @@ -2510,9 +2514,11 @@ reschedule_signals(struct proc *p, sigset_t block, int flags) int sig; PROC_LOCK_ASSERT(p, MA_OWNED); + ps = p->p_sigacts; + mtx_assert(&ps->ps_mtx, (flags & SIGPROCMASK_PS_LOCKED) != 0 ? + MA_OWNED : MA_NOTOWNED); if (SIGISEMPTY(p->p_siglist)) return; - ps = p->p_sigacts; SIGSETAND(block, p->p_siglist); while ((sig = sig_ffs(&block)) != 0) { SIGDELSET(block, sig); From owner-freebsd-threads@FreeBSD.ORG Thu Nov 27 17:14:15 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E431395; Thu, 27 Nov 2014 17:14:15 +0000 (UTC) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.233.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE2FAF81; Thu, 27 Nov 2014 17:14:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=three; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=HTDW7Kl5K9x9DRq3cgw31ZlzaOdyFxpJGEXF1Gsjj4U=; b=RwOqqrn3r5AW9G/xaNouEavEHZKLRjMktRaABSF8fcgwYWI3I7BVNznys6b5pLOg/l2qA6meTayfkkKmsK01I89cQxxKG1rDwTTk49Uza+KEouRTYJmP+GxEsWjXACMRXsk1r8Ey/yfAYtrxUuSnSi7gz9k54HvwyZEn2mwWZ/QnqHxtg2P3TLPdq7lpKIt5LOtnUBB8y7o9GzfOM4kwvM6SC0CjvIhECvIjiNRkyNm1LgLZWk5DKMY+D5eV8szlyoBub5E+77HSV1ayD6wGLwOMe0eaqZqaDVANB1B8+SRAfuEALnlD4m49Yl6VrH47Bv6bwKHLeAVAgIsVqLa3IKCfSqGP7iNHV3ysBxzvgGVlWxdhHai9o8qrDYajdxh9UX/U3pYxCEgwehm2onvwX2ot5oIh1RBSu4UILd6JfjmZZtiCpzS/VxyOYqu0u1+E4JRE6ldpW4HZCnXUPpbHMVr9ycBFYxKEblE1SrJUCOjlAjhKuM2Fr3aRrztB/88okNWhpE7KM2buH1a7Ry7Ie1XmDKhLbyDVc7vzZ3pwn+r2r4X8X9p4BinimuwOj5pnP32uwuDDXZF02qe7Ek+W8qsstcC4KrFAbnXoQJEGiBofJ92VGVo+iu8T8wn0NyHbZc9dL3pH02hxwqwM7Es0U49CoIuyEVNfKPq7gJSZ9jc=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.233.66]) by 0.mx.codelabs.ru with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1Xu2dv-0007Fn-G1; Thu, 27 Nov 2014 21:14:11 +0400 Date: Thu, 27 Nov 2014 20:14:09 +0300 From: Eygene Ryabinkin To: Konstantin Belousov Subject: Re: [CFR][PATCH] Call proper signal handler from libthr for non-SA_SIGINFO case Message-ID: References: <20141120194925.GK17068@kib.kiev.ua> <20141121165658.GP17068@kib.kiev.ua> <20141121203227.GS17068@kib.kiev.ua> <20141126221734.GM17068@kib.kiev.ua> <20141127101405.GP17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ggC1wwkyYWqEab//" Content-Disposition: inline In-Reply-To: <20141127101405.GP17068@kib.kiev.ua> Sender: rea@codelabs.ru Cc: davidxu@FreeBSD.org, freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 17:14:15 -0000 --ggC1wwkyYWqEab// Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thu, Nov 27, 2014 at 12:14:06PM +0200, Konstantin Belousov wrote: > On Thu, Nov 27, 2014 at 07:21:14AM +0300, Eygene Ryabinkin wrote: > > "PROC_LOCK_ASSERT(td->td_proc, MA_OWNED);" be also present single > > kern_sigprocmask() is called with SIGPROCMASK_PROC_LOCKED? > > This is what I suggested in my earlier mail. When I started looking into > details, I decided not to do it. The reasoning is that the function > itself touches no process state protected by the proc lock. It is > kern_sigprocmask which works with process lock-protected data. On the > other hand, the function works with p_sigacts, which is covered by > ps_mtx, and I asserted it. But sendsig_done() calls kern_sigprocmask with (SIGPROCMASK_PROC_LOCKED | SIGPROCMASK_PS_LOCKED) thus guaranteeing some set of locks, so its better to have some ways to support this assertion. I understand that the current implementation of kern_sigprocmask() will test such an assertion, but things may change with time. Moreover, having all asserts at the beginning of a function makes at least myself to immediately recognise which lock(s) should be taken before this function is to be called, so it is a kind of a documentation. > I believe that the following patch is due. It is better way to ensure > the invariants, instead of adding assert to postsig_done(). These are good, but, probably, you can do something like {{{ PROC_LOCK_ASSERT(p, (flags & SIGPROCMASK_PROC_LOCKED) ? MA_OWNED : MA_NOTOW= NED) }}} inside kern_sigprocmask to have a bit stronger assertion that covers unlocked case. > diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c > index 15638e0..502f334 100644 > --- a/sys/kern/kern_sig.c > +++ b/sys/kern/kern_sig.c > @@ -998,8 +998,12 @@ kern_sigprocmask(struct thread *td, int how, sigset_= t *set, sigset_t *oset, > int error; > =20 > p =3D td->td_proc; > - if (!(flags & SIGPROCMASK_PROC_LOCKED)) > + if ((flags & SIGPROCMASK_PROC_LOCKED) !=3D 0) > + PROC_LOCK_ASSERT(p, MA_OWNED); > + else > PROC_LOCK(p); > + mtx_assert(&p->p_sigacts->ps_mtx, (flags & SIGPROCMASK_PS_LOCKED) !=3D 0 > + ? MA_OWNED : MA_NOTOWNED); > if (oset !=3D NULL) > *oset =3D td->td_sigmask; > =20 > @@ -2510,9 +2514,11 @@ reschedule_signals(struct proc *p, sigset_t block,= int flags) > int sig; > =20 > PROC_LOCK_ASSERT(p, MA_OWNED); > + ps =3D p->p_sigacts; > + mtx_assert(&ps->ps_mtx, (flags & SIGPROCMASK_PS_LOCKED) !=3D 0 ? > + MA_OWNED : MA_NOTOWNED); > if (SIGISEMPTY(p->p_siglist)) > return; > - ps =3D p->p_sigacts; > SIGSETAND(block, p->p_siglist); > while ((sig =3D sig_ffs(&block)) !=3D 0) { > SIGDELSET(block, sig); >=20 And, being in the nit-picking mode, I'd apply the following patch {{{ Index: sys/kern/kern_sig.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/kern_sig.c (revision 275189) +++ sys/kern/kern_sig.c (working copy) @@ -1043,7 +1043,7 @@ * signal, possibly waking it up. */ if (p->p_numthreads !=3D 1) - reschedule_signals(p, new_block, flags); + reschedule_signals(p, new_block, flags & SIGPROCMASK_PS_LOCKED); } =20 out: }}} because reschedule_signals() is interested only in SIGPROCMASK_PS_LOCKED, so there is no reason to pass other bits, since it may lead to some confusion. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --ggC1wwkyYWqEab// Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iL4EABEKAGYFAlR3W+FfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDgyRkUwNkJDRDQ5N0MwREU0OUVDNEZGMDE2 QUY5RUFFODE1MkVDRkIACgkQFq+eroFS7Pv7gQEAlILqnlWcwtZAtK/9jWGbtZVo Lk009Gc7LxI5RFQR8v8A/RJokGaXIfwmmbbVHyotU16CQOOiUumqKMOaKeVYnRPl =2XAU -----END PGP SIGNATURE----- --ggC1wwkyYWqEab//-- From owner-freebsd-threads@FreeBSD.ORG Thu Nov 27 21:17:01 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0087EA42 for ; Thu, 27 Nov 2014 21:17:00 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCCE8E67 for ; Thu, 27 Nov 2014 21:17:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sARLH0f9083960 for ; Thu, 27 Nov 2014 21:17:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Thu, 27 Nov 2014 21:17:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rea@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 21:17:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 Eygene Ryabinkin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rea@FreeBSD.org --- Comment #8 from Eygene Ryabinkin --- Looks like there is at least off-by-one access to the driver-specific ioctl array, http://codelabs.ru/fbsd/patches/drm2/fix-drm_drv-off-by-one.diff, since max_ioctl is not a number of a highest supported ioctl number, but rather a size of driver's ioctl array. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-threads@FreeBSD.ORG Thu Nov 27 21:20:49 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA7AFBCC for ; Thu, 27 Nov 2014 21:20:49 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2C97EAE for ; Thu, 27 Nov 2014 21:20:49 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sARLKndf087039 for ; Thu, 27 Nov 2014 21:20:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Thu, 27 Nov 2014 21:20:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rea@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 21:20:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 --- Comment #9 from Eygene Ryabinkin --- (In reply to sasamotikomi from comment #6) > (In reply to John Baldwin from comment #5) > > In all these crashes, the root bug is a NULL pointer dereference (probably) > > at drm_ioctl+0x2ca. Can you provide the kgdb backtrace from a single > > core.txt file? It would be good to see what source line corresponds to that > > address. > I still have old GENERIC kernel (/boot/kernel.old.9.1/kernel) how to do that? > I new for kernel debugging. Try the following: {{{ cd /boot/kernel.old.9.1 kgdb drm2.ko list *(drm_ioctl+0x2ca) }}} This assumes that you have drm2.ko and its symbolic information (drm2.ko.symbols) is present too. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-threads@FreeBSD.ORG Fri Nov 28 10:13:19 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77D1DAEE; Fri, 28 Nov 2014 10:13:19 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00AD7F19; Fri, 28 Nov 2014 10:13:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sASADDrY083319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2014 12:13:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sASADDrY083319 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sASADC8a083317; Fri, 28 Nov 2014 12:13:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 28 Nov 2014 12:13:12 +0200 From: Konstantin Belousov To: Eygene Ryabinkin Subject: Re: [CFR][PATCH] Call proper signal handler from libthr for non-SA_SIGINFO case Message-ID: <20141128101312.GT17068@kib.kiev.ua> References: <20141120194925.GK17068@kib.kiev.ua> <20141121165658.GP17068@kib.kiev.ua> <20141121203227.GS17068@kib.kiev.ua> <20141126221734.GM17068@kib.kiev.ua> <20141127101405.GP17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: davidxu@FreeBSD.org, freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 10:13:19 -0000 On Thu, Nov 27, 2014 at 08:14:09PM +0300, Eygene Ryabinkin wrote: > Thu, Nov 27, 2014 at 12:14:06PM +0200, Konstantin Belousov wrote: > > On Thu, Nov 27, 2014 at 07:21:14AM +0300, Eygene Ryabinkin wrote: > > > "PROC_LOCK_ASSERT(td->td_proc, MA_OWNED);" be also present single > > > kern_sigprocmask() is called with SIGPROCMASK_PROC_LOCKED? > > > > This is what I suggested in my earlier mail. When I started looking into > > details, I decided not to do it. The reasoning is that the function > > itself touches no process state protected by the proc lock. It is > > kern_sigprocmask which works with process lock-protected data. On the > > other hand, the function works with p_sigacts, which is covered by > > ps_mtx, and I asserted it. > > But sendsig_done() calls kern_sigprocmask with > (SIGPROCMASK_PROC_LOCKED | SIGPROCMASK_PS_LOCKED) thus guaranteeing > some set of locks, so its better to have some ways to support this > assertion. I understand that the current implementation of > kern_sigprocmask() will test such an assertion, but things may change > with time. kern_sigprocmask (will) assert this on its own. (will == after the patch is committed, which I am going to do right now). > > Moreover, having all asserts at the beginning of a function makes > at least myself to immediately recognise which lock(s) should be taken > before this function is to be called, so it is a kind of a documentation. > > > I believe that the following patch is due. It is better way to ensure > > the invariants, instead of adding assert to postsig_done(). > > These are good, but, probably, you can do something like > {{{ > PROC_LOCK_ASSERT(p, (flags & SIGPROCMASK_PROC_LOCKED) ? MA_OWNED : MA_NOTOWNED) > }}} > inside kern_sigprocmask to have a bit stronger assertion that covers > unlocked case. This is not needed. The process lock is not recursive, so the mere call to acquire the lock triggers the assertion on recursive acquire. > > > diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c > > index 15638e0..502f334 100644 > > --- a/sys/kern/kern_sig.c > > +++ b/sys/kern/kern_sig.c > > @@ -998,8 +998,12 @@ kern_sigprocmask(struct thread *td, int how, sigset_t *set, sigset_t *oset, > > int error; > > > > p = td->td_proc; > > - if (!(flags & SIGPROCMASK_PROC_LOCKED)) > > + if ((flags & SIGPROCMASK_PROC_LOCKED) != 0) > > + PROC_LOCK_ASSERT(p, MA_OWNED); > > + else > > PROC_LOCK(p); > > + mtx_assert(&p->p_sigacts->ps_mtx, (flags & SIGPROCMASK_PS_LOCKED) != 0 > > + ? MA_OWNED : MA_NOTOWNED); > > if (oset != NULL) > > *oset = td->td_sigmask; > > > > @@ -2510,9 +2514,11 @@ reschedule_signals(struct proc *p, sigset_t block, int flags) > > int sig; > > > > PROC_LOCK_ASSERT(p, MA_OWNED); > > + ps = p->p_sigacts; > > + mtx_assert(&ps->ps_mtx, (flags & SIGPROCMASK_PS_LOCKED) != 0 ? > > + MA_OWNED : MA_NOTOWNED); > > if (SIGISEMPTY(p->p_siglist)) > > return; > > - ps = p->p_sigacts; > > SIGSETAND(block, p->p_siglist); > > while ((sig = sig_ffs(&block)) != 0) { > > SIGDELSET(block, sig); > > > > And, being in the nit-picking mode, I'd apply the following patch > {{{ > Index: sys/kern/kern_sig.c > =================================================================== > --- sys/kern/kern_sig.c (revision 275189) > +++ sys/kern/kern_sig.c (working copy) > @@ -1043,7 +1043,7 @@ > * signal, possibly waking it up. > */ > if (p->p_numthreads != 1) > - reschedule_signals(p, new_block, flags); > + reschedule_signals(p, new_block, flags & SIGPROCMASK_PS_LOCKED); > } > > out: > }}} > because reschedule_signals() is interested only in SIGPROCMASK_PS_LOCKED, > so there is no reason to pass other bits, since it may lead to some > confusion. I disagree, I wrote reschedule_signals() to take the same set of flags as kern_sigprocmask(). From owner-freebsd-threads@FreeBSD.ORG Fri Nov 28 10:28:20 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DFF3E86; Fri, 28 Nov 2014 10:28:20 +0000 (UTC) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.233.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE477AA; Fri, 28 Nov 2014 10:28:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=three; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=CexCYhGE/NmttifFPd1supGrNXBEkDoS0vR044nuYPk=; b=w6ii1//IgDtAOSc+OQSyvhzyIIcTUoVuqy9/o7LVCrM1pifiijfxA4vk9IBik99yCXewhVmdnIsZMdnbYp0ugADLPUjdPPmmKYQSsU7o4cZvhUfSBBxhOSbEHLhBiz1fFLbtqqzm/Prho9R+qbyh534tNyovc+Z6ktiYxxrGaJgdEgqbZQErHN8pRkG8mRF4eA6AptZY+yptLOb7MxZ+FakkTM9IfWrYA+++pjmrz52VsDrjF5XTM+cAoDoOJl1z+1UWJN3blc2fWhexSYJxK3PlIIpJepBERwXtqNpUjpKJqjsfIAztp0vpxF6E5JUIQGQaERpryUldVMcuKXh8grOGr+ADEUg0Rs9DUX5kMR2Ob4bwKS+dEG1YA0JxykGAgxeIQjFEQN2MrT2sdBhxjjUp0rExlsxkAvi8sXcxFrn0rJWt3i5mU1gg1m59gOu0hGBpA4yh9f1iZ1VGYiJ35JVeWyngsKTQ83CKZohWb0PLlm8w2+XSZYx0Ld/wuvmJBYpqZvm2pBasSD1TGiZT5j53sjz6qfuWf+T6TlQ8V1Q+Eo8MPuzz+wtdlLgcFLlRkccU+ZpZEMETJjwTF1vzt06Cj0SFtKOqs6DKjB3J6Ra7OB6WUk0W1u43YJlPLuNNNhaxkYpv0/RdP6YjR6ALrrXi8OAYkonOeVliBciTgRE=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.233.66]) by 0.mx.codelabs.ru with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1XuIme-0001lL-Ey; Fri, 28 Nov 2014 14:28:16 +0400 Date: Fri, 28 Nov 2014 13:28:14 +0300 From: Eygene Ryabinkin To: Konstantin Belousov Subject: Re: [CFR][PATCH] Call proper signal handler from libthr for non-SA_SIGINFO case Message-ID: References: <20141121165658.GP17068@kib.kiev.ua> <20141121203227.GS17068@kib.kiev.ua> <20141126221734.GM17068@kib.kiev.ua> <20141127101405.GP17068@kib.kiev.ua> <20141128101312.GT17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mL5prfgbrp62Xbpc" Content-Disposition: inline In-Reply-To: <20141128101312.GT17068@kib.kiev.ua> Sender: rea@codelabs.ru Cc: davidxu@FreeBSD.org, freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 10:28:20 -0000 --mL5prfgbrp62Xbpc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Fri, Nov 28, 2014 at 12:13:12PM +0200, Konstantin Belousov wrote: > On Thu, Nov 27, 2014 at 08:14:09PM +0300, Eygene Ryabinkin wrote: > > But sendsig_done() calls kern_sigprocmask with > > (SIGPROCMASK_PROC_LOCKED | SIGPROCMASK_PS_LOCKED) thus guaranteeing > > some set of locks, so its better to have some ways to support this > > assertion. I understand that the current implementation of > > kern_sigprocmask() will test such an assertion, but things may change > > with time. > > kern_sigprocmask (will) assert this on its own. (will =3D=3D after the pa= tch > is committed, which I am going to do right now). kern_sigprocmask() will. But calling something with such set of flags (that guarantee that both locks are taken), but not checking for one of the locks that it is really so it a bit inconsistent. > > These are good, but, probably, you can do something like > > {{{ > > PROC_LOCK_ASSERT(p, (flags & SIGPROCMASK_PROC_LOCKED) ? MA_OWNED : MA_N= OTOWNED) > > }}} > > inside kern_sigprocmask to have a bit stronger assertion that covers > > unlocked case. > This is not needed. The process lock is not recursive, so the mere call > to acquire the lock triggers the assertion on recursive acquire. Got it, thanks! > > And, being in the nit-picking mode, I'd apply the following patch > > {{{ > > Index: sys/kern/kern_sig.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- sys/kern/kern_sig.c (revision 275189) > > +++ sys/kern/kern_sig.c (working copy) > > @@ -1043,7 +1043,7 @@ > > * signal, possibly waking it up. > > */ > > if (p->p_numthreads !=3D 1) > > - reschedule_signals(p, new_block, flags); > > + reschedule_signals(p, new_block, flags & SIGPROCMASK_PS_LOCKED); > > } > > =20 > > out: > > }}} > > because reschedule_signals() is interested only in SIGPROCMASK_PS_LOCKE= D, > > so there is no reason to pass other bits, since it may lead to some > > confusion. >=20 > I disagree, I wrote reschedule_signals() to take the same set of > flags as kern_sigprocmask().=20 Since reschedule_signals() now unconditionally needs PROC_LOCK to be owned, it doesn't care for at least SIGPROCMASK_PROC_LOCKED bit in flags. And, for example, if you'll pass the flags to any routine called from reschedule_signals() that checks for SIGPROCMASK_PROC_LOCKED and acquires the lock when this bit is deasserted, it will loudly (as you explained above) fail trying to take non-recursive lock for the case when original flags passed to reschedule_signals() have no SIGPROCMASK_PROC_LOCKED bit enabled. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --mL5prfgbrp62Xbpc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iL4EABEKAGYFAlR4Tj5fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDgyRkUwNkJDRDQ5N0MwREU0OUVDNEZGMDE2 QUY5RUFFODE1MkVDRkIACgkQFq+eroFS7PviaQD/eWt9cHqUA7w+i5hfeLlWijaT D7JBplMN2UIqUxosgSAA/1yu4BGZmHkGYpPsZJPOATdhu5SBche2MQbiEpfaUSaH =WvM8 -----END PGP SIGNATURE----- --mL5prfgbrp62Xbpc-- From owner-freebsd-threads@FreeBSD.ORG Fri Nov 28 10:29:02 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A38A6EB9 for ; Fri, 28 Nov 2014 10:29:02 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BEBFB3 for ; Fri, 28 Nov 2014 10:29:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sASAT2Ve005212 for ; Fri, 28 Nov 2014 10:29:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Fri, 28 Nov 2014 10:29:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 10:29:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 Konstantin Belousov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #10 from Konstantin Belousov --- (In reply to Eygene Ryabinkin from comment #8) > Looks like there is at least off-by-one access to the driver-specific ioctl > array, http://codelabs.ru/fbsd/patches/drm2/fix-drm_drv-off-by-one.diff, > since max_ioctl is not a number of a highest supported ioctl number, but > rather a size of driver's ioctl array. I think that the patch is wrong, and there is no off-by-one bug. At least in i915 case, max_ioctl is initialized as nitems(i915_ioctls), which is the number of array elements. Applying your patch, the last ioctl in the driver-specific array becomes inaccessible. As an easier test, consider what would happen after your change if array consists of single element. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-threads@FreeBSD.ORG Fri Nov 28 10:37:32 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B640D2EA for ; Fri, 28 Nov 2014 10:37:32 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F0411AE for ; Fri, 28 Nov 2014 10:37:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sASAbW37044807 for ; Fri, 28 Nov 2014 10:37:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Fri, 28 Nov 2014 10:37:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rea@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 10:37:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 --- Comment #11 from Eygene Ryabinkin --- ./i915/i915_dma.c: .max_ioctl = DRM_ARRAY_SIZE(i915_ioctls), and drmP.h reads #define DRM_ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0])) so for the case when nr = dev->driver->max_ioctl, with dev->driver->ioctls[nr] you will be doing the same thing as for {{{ array[N]; value = array[N]; }}} that is off-by-one. Am I missing something? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-threads@FreeBSD.ORG Fri Nov 28 10:49:25 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA5FC5BC for ; Fri, 28 Nov 2014 10:49:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92A382FD for ; Fri, 28 Nov 2014 10:49:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sASAnPSs059117 for ; Fri, 28 Nov 2014 10:49:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Fri, 28 Nov 2014 10:49:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 10:49:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193367 Konstantin Belousov changed: What |Removed |Added ---------------------------------------------------------------------------- Component|threads |kern Assignee|freebsd-threads@FreeBSD.org |freebsd-bugs@FreeBSD.org --- Comment #12 from Konstantin Belousov --- (In reply to Eygene Ryabinkin from comment #11) > ./i915/i915_dma.c: .max_ioctl =3D DRM_ARRAY_SIZE(i915_ioctls), > and drmP.h reads > #define DRM_ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0])) > so for the case when nr =3D dev->driver->max_ioctl, with > dev->driver->ioctls[nr] you will be doing the same thing as for > {{{ > array[N]; >=20 > value =3D array[N]; > }}} > that is off-by-one. >=20 > Am I missing something? No, you are right. Sorry for the confusion. Feel free to commit the patch with reasonable MFC period (say, 1 week). Approved by: kib. --=20 You are receiving this mail because: You are the assignee for the bug.=