Received: by 2002:a05:7412:5112:b0:fa:6e18:a558 with SMTP id fm18csp175092rdb; Mon, 22 Jan 2024 16:26:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IE/1yJCbuHItmgYQDmtmHryUrF/GxOT4o2zg0tUzW5UB4UnU/BnOuxjZuLstdl2LXWskayy X-Received: by 2002:a17:90a:4212:b0:290:6b49:e686 with SMTP id o18-20020a17090a421200b002906b49e686mr1594420pjg.88.1705969592871; Mon, 22 Jan 2024 16:26:32 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705969592; cv=pass; d=google.com; s=arc-20160816; b=1Ei4rcInP/MVAQhl3ivpHzVFdpduAdPViHFgFGHXPpcbmhxHkaI2emG/uvuXJcJ9MO bxUGDtHRDCVV/BtExFH6HiZvgdtVQGX/+IxOBFuThzL+HdXAgWirL0FogIcBn4J/9Wo6 MadhqsNaZU4O4xOyBQUYgsxR4bbswFBajnY/mx/6c4YXGS2TdCUaKs2dI9RD3kPCVp0q bfHV5OI6yTv8oeya7OUkfwuisgy0qggwHnXFeGNoY366XPpMfL83VZ+jbIOi3E4tik6J ObUkcyYSGvs8a6dxQiU/umd6rntJvVBeGqK28CGLYh+IfUBZZFhAe2uuOBOnTlhqHa8R PYyg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=k1TmPbPwU6yeDSqCOG4dxDOtGcazP+3v1K2l4T5Vv4o=; fh=dL0nEdyHUy8dT6mhiYomDkaH/NPJHGlycW1PV73LCrE=; b=CnjhhQQ6RJVSwl/LQbf5tkxwVEC+Gj/Nemf0wrAJu3SYNYsQjrAyrNCzh4PIgJBsYr MecYToBD4NCVo1uScImmgtG99te5clDAT+j9ReYQITRXBrO1VgjbD8Zk7siMeZC8ZQGF 7tDKiYqgwTIjlqSogwLZ2/aUCsp3adSIu0FheNzcTbzXdtVxDvODGUJiYvf+FGsrsC2J am2u/DPuARiTo2Q3t6K0WZcCGGIzA5LvFPUdnHmnUfHai2ST1ZXNp9hMQvuf1p4r+QkQ K1QPbauU302LGcafq0PW2LoBlzLWa7AQN4Kq93SQmzhxH6hyOBpx4esdej7e84+adYX4 MFiw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=W8zg10XY; arc=pass (i=1 dkim=pass dkdomain=linux-foundation.org); spf=pass (google.com: domain of linux-kernel+bounces-34431-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-34431-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id e7-20020a17090a630700b002900e52586fsi8780334pjj.20.2024.01.22.16.26.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 16:26:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-34431-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=W8zg10XY; arc=pass (i=1 dkim=pass dkdomain=linux-foundation.org); spf=pass (google.com: domain of linux-kernel+bounces-34431-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-34431-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 5536228BB87 for ; Tue, 23 Jan 2024 00:23:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 54F2E1292CC; Mon, 22 Jan 2024 23:57:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="W8zg10XY" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 632811292C3 for ; Mon, 22 Jan 2024 23:57:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705967848; cv=none; b=hIPe1Q++6CDIgVdWK/jEO3LLwqbO4lJCeXfFNfKa2QYMF4PiQtqYnWfRpX1WlP5dMPuhDC10SyNqICmFsB6PIAVMypQbnmnAHRMge6DTx7259MoAgOftNWtG9W+2rtQELNWW+M7Z3z447tL0LUPOepoLlO63dt1G1qJcsi2RNCU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705967848; c=relaxed/simple; bh=k1TmPbPwU6yeDSqCOG4dxDOtGcazP+3v1K2l4T5Vv4o=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=IrITeC+/tH7Sk5FqO4Lxxrmv3tHo4Fapvlf9R+nzfgD6HXvwsZ1A54RJzXE5a7Qek/yYOtV5KneWyUHESBYTwkCxxA/OD8xYl95xRifn9wuX2V/7gazNH/oHFYcIAXM0dqH1qC9QAF/2YmPLYE2JK2IXh3chceqV553nS89mMIE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=W8zg10XY; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73836C43390; Mon, 22 Jan 2024 23:57:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1705967847; bh=k1TmPbPwU6yeDSqCOG4dxDOtGcazP+3v1K2l4T5Vv4o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=W8zg10XYmZrWD6rDIQR10e5E7FsGiKAcGYHluuUhIShwArN3LGVSIivHSEwa7oIOr ys7O7tnIQ9SgyJliz/wCOu78XjKWkKAhhJX9igdJWSX8+o2wJ0fPtSZTgQ8IAfOByT GDK9XLbif4Mf/TczJ+UfQpnxfXZ4ZBfG8Sww6wB4= Date: Mon, 22 Jan 2024 15:57:23 -0800 From: Andrew Morton To: Oleg Nesterov Cc: "Eric W. Biederman" , Dylan Hatch , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] getrusage: use sig->stats_lock rather than lock_task_sighand() Message-Id: <20240122155723.149081552c9a9e122b1f783b@linux-foundation.org> In-Reply-To: <20240122155053.GA26214@redhat.com> References: <20240122155023.GA26169@redhat.com> <20240122155053.GA26214@redhat.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 22 Jan 2024 16:50:53 +0100 Oleg Nesterov wrote: > lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call > getrusage() at the same time and the process has NR_THREADS, spin_lock_irq > will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. It would be super interesting to see Dylan's original report. Is it possible for carefully-crafted unprivileged userspace to deliberately trigger this?