From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id CD7CD385771D for ; Fri, 28 Apr 2023 08:38:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD7CD385771D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682671121; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5eQiW43ucbjN/HxF2B9QjA7XdpB4vwtxxbm9m0ALQPU=; b=Hq1D5rYJ8RRx61nrC/bpuBGwr7QBr9Au2ObfCAEwfmr4w5UA4n6QUlBgKGi5cEbTzzbqZ7 8ek972ePpZTnH10IQQxQPtk7h/QShwk9gegHbB0cipyN3VZZBIfdXYa5WJWjbGAgapN4vC FV9vp5v7SZgvFuVqgSPfiKFVPVWv9CM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-675-qM_ViTSNNP-9P-vgUIHBuw-1; Fri, 28 Apr 2023 04:38:38 -0400 X-MC-Unique: qM_ViTSNNP-9P-vgUIHBuw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id ABE3D800B35; Fri, 28 Apr 2023 08:38:37 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D40FB40C6EC4; Fri, 28 Apr 2023 08:38:36 +0000 (UTC) From: Florian Weimer To: "H.J. Lu via Libc-alpha" Cc: "H.J. Lu" Subject: Re: [PATCH] __check_pf: Add a cancellation cleanup handler [BZ #20975] References: <20230427200615.1496059-1-hjl.tools@gmail.com> Date: Fri, 28 Apr 2023 10:38:35 +0200 In-Reply-To: <20230427200615.1496059-1-hjl.tools@gmail.com> (H. J. Lu via Libc-alpha's message of "Thu, 27 Apr 2023 13:06:15 -0700") Message-ID: <87sfck9zas.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * H. J. Lu via Libc-alpha: > There are reports for hang in __check_pf: > > https://github.com/JoeDog/siege/issues/4 > > It is reproducible only under specific configurations: > > 1. Large number of cores (>= 64) and large number of threads (> 3X of > the number of cores) with long lived socket connection. > 2. Low power (frequency) mode. > 3. Power management is enabled. > > While holding lock, __check_pf calls make_request which calls __sendto > and __recvmsg. Since __sendto and __recvmsg are cancellation points, > lock held by __check_pf won't be released and can cause deadlock when > thread cancellation happens in __sendto or __recvmsg. Add a cancellation > cleanup handler for __check_pf to unlock the lock when cancelled by > another thread. This fixes BZ #20975 and the siege hang issue. It's probably easier to reproduce if the system has many network interfaces with lots of addresses. Doesn't getaddrinfo leak all kind of resources when canceled? That's more difficult to fix, though. Thanks, Florian