From owner-freebsd-gnome@freebsd.org Sat Sep 14 04:57:41 2019 Return-Path: Delivered-To: freebsd-gnome@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 022C4DEF1D for ; Sat, 14 Sep 2019 04:57:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46VgH86CPdz4Vsc for ; Sat, 14 Sep 2019 04:57:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id D30C8DEF1C; Sat, 14 Sep 2019 04:57:40 +0000 (UTC) Delivered-To: gnome@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D1B6EDEF1B for ; Sat, 14 Sep 2019 04:57:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46VgH84tJ3z4VsZ for ; Sat, 14 Sep 2019 04:57:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 839971AB23 for ; Sat, 14 Sep 2019 04:57:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x8E4veq2070881 for ; Sat, 14 Sep 2019 04:57:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x8E4verU070880 for gnome@FreeBSD.org; Sat, 14 Sep 2019 04:57:40 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: gnome@FreeBSD.org Subject: [Bug 236815] [patch] devel/glib20: loops over all possible file descriptors Date: Sat, 14 Sep 2019 04:57:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: lantw44@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnome@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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-gnome@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2019 04:57:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236815 --- Comment #23 from Ting-Wei Lan --- (In reply to Ting-Wei Lan from comment #12) > 1. malloc() can not cause deadlock, it is heavy used by many multithread = apps. Thread-safe does not imply async-signal-safe. The former can be achieved by using a mutex on shared resources, but the latter cannot. 'man fork' says: If the process has more than one thread, locks and other resources held by = the other threads are not released and therefore only async-signal-safe functio= ns (see sigaction(2)) are guaranteed to work in the child process until a call= to execve(2) or a similar function. Since fdwalk is called from the child process and it is possible for the pa= rent process to have multiple threads, it can only call async-signal-safe functi= ons. malloc is thread-safe but not async-signal-safe because the implementation= is likely to use a lock to protect global data. Assume that there is a thread calling malloc while you are calling fork. If the malloc lock is held while forking, the child process will have the malloc lock held as well. Since the child process only has one thread, which is the thread calling fork, the ma= lloc lock can never be released because the thread holding the lock does not exi= st in the child process. Therefore, if you call malloc in the child process be= fore exec, it is possible to cause deadlock. > 2. Docs says that opendir() is thread and mt safe: > http://man7.org/linux/man-pages/man3/opendir.3.html > But readdir() is not: MT-Unsafe: > http://man7.org/linux/man-pages/man3/readdir.3.html The current master branch uses neither opendir nor readdir. > 3. Reading dir using more than one syscall is bad idea because between re= ad > it can change some content is it will not be handled/processed. > As I remember this was a reason to drop opendir() in mine FAM backend and= =20 > some strange crashes: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214338 > So I do not understand why some one can need LOCK() in fdwalk(). fdwalk should not use LOCK. Where did you find it? --=20 You are receiving this mail because: You are the assignee for the bug.=