From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86819 invoked by alias); 17 Feb 2020 09:42:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 86811 invoked by uid 89); 17 Feb 2020 09:42:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:mvmlfp1, H*f:sk:mvmlfp1, employ X-HELO: albireo.enyo.de From: Florian Weimer To: Andreas Schwab Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] Always do locking when accessing streams (bug 15142, bug 14697) References: <87y2t2slcq.fsf@mid.deneb.enyo.de> Date: Mon, 17 Feb 2020 09:42:00 -0000 In-Reply-To: (Andreas Schwab's message of "Mon, 17 Feb 2020 10:19:31 +0100") Message-ID: <8736b9eel2.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2020-02/txt/msg00738.txt.bz2 * Andreas Schwab: > On Feb 16 2020, Florian Weimer wrote: > >> I'm not sure if the justification is correct. We don't know if there >> are programs which call flockfile on some file and expect exit to >> still work (and terminate the program), which is part of what >> nptl/tst-stdio1 tests. > > But that's exactly what the bug is about. Random memory corruption > cannot be the answer. Sure, but breaking existing programs so that they never terminate is not acceptable, either. (They might employ external locking and not have any data races, so they don't need this change.) Just to be clear, I think your patch is worth a try, we just have to be prepared to revert it and replace it with symbol versioning for exit.