From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 843412036E9 for ; Sat, 6 Jun 2026 14:51:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780757491; cv=none; b=TDTs0RSpanyGmBUHsyLs++Of0b/9K/Xzrk+CUPUnYzBmrM++89564R86PHs+AgRiw/V2NHgQlfBvEDNYQKrX68I1EbqotCfG/ZMCqyMvFuoBjExa/xbhTalLuZhkIFbnWffG4g5b7s0RY94nH23PT2gfWMA+dq7keawgEmW2Sqg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780757491; c=relaxed/simple; bh=sWf4wkTLH789FhDJhKwyO+AP6oz1ciEMmywSF3k68cM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Do8ggvNeS2dGbyCLGRhDFM38mVbl+PYAtuTGmpPCpJf0SkJKlWxrbUDKC0Gr58Qh7EqvLINAr0f0QZ9vYkcK/76cx5DIAAcInqXyr7qRidBnT/+zndANnq+RPJ9aAjtuAWHGe0zUIxe4yrMd7G2GcWOMywwOoAPwDeBadloKrEA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=mwTpoKTL; arc=none smtp.client-ip=209.85.214.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="mwTpoKTL" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2bf22c18ad3so222165ad.0 for ; Sat, 06 Jun 2026 07:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780757490; x=1781362290; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=djjDHCNu5izfnOxL/0uU9FKY3th5OUnw0j8EdOmNhFQ=; b=mwTpoKTLoJLk4UCLenX+wB1Nuhrce9itZ5uqLvTXdWL8exy+PjvB1/H7Fee/YocHxI ON8efXursaDiWLN9nVRIHMEOi+QbZ87A9B7dwHVLEK5V4AqOFn8ytBxVNlCh0rSzQZWS zTU7DX8uZMfm69SlKLwzEgqLO+TF69xf4J7j9YTswnMBENMm6hLNtNzXWrty1qUCmUeX pGxm9cdzNvLDrZWKyNReepD2caMxC2UA7/I1ApI3Ns42G5j7bSRDIrCWHooyK7RQDc1K M44a5yMZfAEaB00qvHuJ55rf7p3+4m6DHG0EPOXwqeoVNrNn0vk9c/0wPGLCQvmgCn/L 1Iyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780757490; x=1781362290; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=djjDHCNu5izfnOxL/0uU9FKY3th5OUnw0j8EdOmNhFQ=; b=J44dx/mIX7Z0d53nVzcdfm0UHDZyCH4DKQhEzPgrVN8mT3qo1866qIXyjQaMd6wtYB tfmjiTFGt0xgtnE2dw3K+7ebxgliVGzIi8IBfsTTWtscOBZkEy1mLdWkQuA9ITPHn1qB kzLYN5H4WQqI5Wstjc1hHVcLc27lbMKarWr5ZDN7aNR4TI6Wc8ua/5m1SVwrJD+iq4fw 1IkhIwX6BVdsOuLThdpjUU1YTzC3EjnHH7Oz4Mtb+LhRNNn26sS1DWD9Byy1/Ukv2XYp bnGuDTxHtWFgtgmfwXmuJiemRCuGk5dxTntXfErb54uJ5iqv4dJdP7tlePVQiasQZTZm iC7g== X-Forwarded-Encrypted: i=1; AFNElJ9prQaCrtTP1oHqrs255vQRQS/Dmbao3CIEt0M2icI9OzExLlN3BnyKTmEXgZhi26ecp6S1kit7Oesyjx8=@vger.kernel.org X-Gm-Message-State: AOJu0YzN674mCCcfA2F1oYkES9IMFTXCIQlbdtsx3xlnoxvYQkcsavvr T3ItQc289Lh0qIA4cbBbOvAx3xwBNXegJzpww01d++jy7IuDsxsQH0hgC5Bl5hHzyQ== X-Gm-Gg: Acq92OEA3NdWaXznwinSdjlJa9uVrlsj1rP6qPOREUJoygeh9hXd8wsMAI/YJ401PH9 eh+66uCx21RQWHNAqqY+1kAHUCNW9JS1Tq9hFVvLZMMPcmkFX7c225oYXrHbmU4e5F70fq9lutz K7FrjBkSeFQB+2FSIt4d0kU+21pgKvpp+FWqmysYRGROY13mnlsSuL4pIGyWOIWmHULoG48eoSG jo8IRWkKqWAn01bgmYSk2FbGb0DgQO8+dmFJ1sZQ7BF9dPISHC70U91vPZMSTd1GL8VrcRaATmp x16XB66k8LfFHbRXvgcP3f/zUnWgBjpAQAWaE3AWuK0rTekR7n8q9s8iT1/mnht6uwi8G9/u0y2 tRGpd/psNWH4J90+oA2QUcxJOShr3bqu/s61pcyNjcwcW0iaknoVEL0weNXDht7JqLvuGuy20bJ uEvZYVQRdRLgrRfhQasBzuDwfCWgM7QIgQgpgCjkESBMjzV0vxHHPV3AJqAPO4zFA5ugLom9aB8 H4Tqwgqo2oh9v7n0GMB2D1pyqh9wQVpP4UtS7iPZ3TLCTnVRYNS7TyY/DEoo+zNUbU= X-Received: by 2002:a17:903:46ce:b0:2bf:749:55c with SMTP id d9443c01a7336-2c1eb72eca7mr3563915ad.21.1780757489421; Sat, 06 Jun 2026 07:51:29 -0700 (PDT) Received: from google.com (112.174.16.34.bc.googleusercontent.com. [34.16.174.112]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c85df0b26bbsm10870423a12.23.2026.06.06.07.51.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 07:51:27 -0700 (PDT) Date: Sat, 6 Jun 2026 14:51:23 +0000 From: Carlos Llamas To: Alice Ryhl Cc: Yunseong Kim , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Christian Brauner , Brian Swetland , Miguel Ojeda , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Yunseong Kim Subject: Re: [PATCH 0/4] binder: cap max_threads and reject duplicate looper entry Message-ID: References: <20260603-b4-binder-hardening-v1-0-d0aae3556c9b@est.tech> <0dd33a00-8fe9-49e1-a32f-565c4a312429@est.tech> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Jun 05, 2026 at 09:55:07AM +0000, Alice Ryhl wrote: > On Thu, Jun 04, 2026 at 10:27:19PM +0200, Yunseong Kim wrote: > > Hi Alice, > > > > On 6/3/26 20:57, Alice Ryhl wrote: > > > On Wed, Jun 3, 2026 at 8:02 PM Yunseong Kim wrote: > > > > > > My understanding is that the only thing BINDER_SET_MAX_THREADS does is > > > cause the kernel to tell userspace "please spawn more threads" when > > > all threads are in use and there are incoming transactions. I don't > > > understand how it helps by pass ulimit. Did you try running your test Correct. SET_MAX_THREADS is simply the threshold at which the kernel will stop pinging userspace to "please spawn more threads". Nothing more. Userspace can choose to ignore that or not. It's got complete control (as it should) to spawn more threads, and it would still be bounded by its system-level limits (RLIMIT_NPROC). > > I think accepting 0xFFFFFFFF for a thread pool size is arguably poor input > > validation. no sane userspace would request 4 billion threads. > > > > Would a separate patch (without Fixes tag) that caps max_threads at a > > reasonable upper bound be welcome, or is it not worth the churn? this is > > hardening, not a security fix. > > I don't think that's useful. Right. Please let userspace decide it's own threshold. Let's instead use the appropriate means to limit the thread creation. There is no need to duplicate that in binder. Cheers, -- Carlos Llamas