From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24891 invoked from network); 6 Oct 2022 20:05:17 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 Oct 2022 20:05:17 -0000 Received: (qmail 19709 invoked by uid 550); 6 Oct 2022 20:05:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19674 invoked from network); 6 Oct 2022 20:05:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dt0SHFZ4hp+6UpdnJMOwEOEKTguSA6LNnBC/FH1rVGI=; b=RWLm82LvdVV1yqU50tvZg5wQ8ZhwK/w2Ztkkoarv4dilqgxYyc0r273HgpdsI66S8B i9Z7HpQ4s4Lpia3Nvtl9XzZFE7UnHWPqY5JVN+py16+jNk6yF1wA6p6mFkG8fJTiO+AU 2j2YQtqQPbs+ZRAgIZA34plZf9EMP9kAXDKpfKbCUZEL3uinZhmHIkIjWnHDed93Jksr P9fe43K+hYOHHOhh7g3dQPF+48j6Asn7f881QxMP7vw1Gp0ehjKoODWozLLQ4ZXsps3R UlIr5QSVWL8o24MqXvzG0C72CLwuH/ZZmff+vKe0XDo71/gabSuMeGkgbNgVUtWpl9a0 jwdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dt0SHFZ4hp+6UpdnJMOwEOEKTguSA6LNnBC/FH1rVGI=; b=pPW04oFw30i/ehAedN/YWgEwXS1lOaX4GO+/hKmPhhbNNrKRLpPvIb7S4c4VW8HHQF 1Hce518GjAp6fbVfNtd9yoleWlaGTuK3gJVjpN/wqMZo1wVo0v7HUovf/ySyGOLFWu8Q jbYab3CdLjVVQwA0D1bPF7EmFM5twcBLYY/c48j7vIGspwcC1RSrUSXCusTnKkF0on1I 2WkKWFfmu2j8PIUzzqdYoBwU1hrWd3l3E1mhvuejabg5SZaywCXdhFOevuz/2v/qgSwA B1zQBVh2JvmA7YRetvfbzyB72ZS5YXSVFARvOXOevYHfL55Zi0Ooa59rSMRSxF9WFSiv qy1w== X-Gm-Message-State: ACrzQf0IO4p1JQJ04Pazu2MvjffjdgJsexl+Lj8d0BxykzAZoggeMJcS rTg6D5cYVSKh7a6b17MTBWuoFBtFi8nEM4/WP+TFQqch X-Google-Smtp-Source: AMsMyM40VUIwoqMHpV3eFkvTe21ik8+IJjM8Y1MzxUo24dNB3pPQk+gtYl3z/W7+pTQDklcqOjBh3IcUaKgApzbSRHE= X-Received: by 2002:a17:902:e80c:b0:17f:92cb:2fdd with SMTP id u12-20020a170902e80c00b0017f92cb2fddmr1468536plg.137.1665086700442; Thu, 06 Oct 2022 13:05:00 -0700 (PDT) MIME-Version: 1.0 References: <033092a85a52d9f8e8d73a235e2381ae@ispras.ru> <6cf9cc5562e17610392c0f9c2cc68316@ispras.ru> <20221006192042.GW29905@brightrain.aerifal.cx> In-Reply-To: <20221006192042.GW29905@brightrain.aerifal.cx> From: Jeffrey Walton Date: Thu, 6 Oct 2022 16:04:48 -0400 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Re: MT fork and key_lock in pthread_key_create.c On Thu, Oct 6, 2022 at 3:21 PM Rich Felker wrote: > On Thu, Oct 06, 2022 at 10:02:11AM +0300, Alexey Izbyshev wrote: > > On 2022-10-06 09:37, Alexey Izbyshev wrote: > > >... > > >Also, I looked at how __aio_atfork() handles a similar case with > > >maplock, and it seems wrong. It takes the read lock and then simply > > >unlocks it both in the parent and in the child. But if there were > > >other holders of the read lock at the time of fork(), the lock won't > > >end up in the unlocked state in the child. It should probably be > > >completely nulled-out in the child instead. > > > > > Looking at aio further, I don't understand how it's supposed to work > > with MT fork at all. __aio_atfork() is called in _Fork() when the > > allocator locks are already held. Meanwhile another thread could be > > stuck in __aio_get_queue() holding maplock in exclusive mode while > > trying to allocate, resulting in deadlock. > > Indeed, this is messy and I don't think it makes sense to be doing > this at all. The child is just going to throw away the state so the > parent shouldn't need to synchronize at all, but if we walk the > multi-level map[] table in the child after async fork, it's possible > that the contents seen are inconsistent, even that the pointers are > only half-written or something. > > I see a few possible solutions: > > 1. Just set map = 0 in the child and leak the memory. This is not > going to matter unless you're doing multiple generations of fork > with aio anyway. This may make security testing and evaluation trickier, like when using -fanalyze=memory. I think it is better to work with the tools nowadays. Jeff