From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) (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 B7F381A2392 for ; Sat, 3 Jan 2026 20:06:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767470809; cv=none; b=PpWfamx7Pzddk9G2SxPSE6vEqH2whSAOExXe3IMzGTgir3eYjFmwOsf8OhLFhXF5SnhoTRdn3K8x0Vz0/+Q97kK3LYCfiHOeciLeSe1tgfQ9fAYB78ar/h8Q9jgCuNOzWCnK7XT5nWlLyHU9gipA4/Ft0Ksr1CN6X+5Qwl1MB9M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767470809; c=relaxed/simple; bh=AeqTIJCAFxsdqg6qk9pUNJAGp4Hwrs6AgLtfSWXB4Es=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=I1lFMaOrhTyJC+meFG87xXxU4n0XU2bZy2vujwBOPkXRUPIh8HD1JQqYy86DzOJDWltVF8k7PYOUkIN+tAMzwufK0RNtFMeBpD5cmHoSnGqmhb+n1q2hZBYftXeVii0tksCq9Mfq9bjYKeBDqyyQHcQBdztwReDVYT+nBUjoxf0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=delta-utec.com; spf=none smtp.mailfrom=delta-utec.com; dkim=pass (2048-bit key) header.d=delta-utec-com.20230601.gappssmtp.com header.i=@delta-utec-com.20230601.gappssmtp.com header.b=HeGMmpf+; arc=none smtp.client-ip=209.85.218.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=delta-utec.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=delta-utec.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=delta-utec-com.20230601.gappssmtp.com header.i=@delta-utec-com.20230601.gappssmtp.com header.b="HeGMmpf+" Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-b7ce5d6627dso2363352666b.2 for ; Sat, 03 Jan 2026 12:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delta-utec-com.20230601.gappssmtp.com; s=20230601; t=1767470805; x=1768075605; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=FxoKlL/Oxj8cjXiUa8fJQ0+WnkWJvGDujzcDraVgeM0=; b=HeGMmpf+i6zBAaEQosodTZck+SDdRvcfqJVsxirzpH1CjeUTYLlkf0bGm+LnNH9j/b NTvbkzhU0inVh1WC+yVidr0z7HGlfF8fsB5gsM4JSTpvTjF80EG9d4qJ2xOmKEsn2ayH JIiCwPb4OniUn7pShNHKwmsq/w1Np/kPw2q96XfkDgXf8RLNvmEBel2r+mQDDjRWhJp0 0evOgu4sVUyOsvMxPhbXIpRo5d1oqcU3XzN/s+Zwwxmfe54qQzNoXHmQllRpkr9DSjvl H8IYFEmz1jSVXCfTsoTJtZU3BdaEQW6/Z06IcloVAUs2d3ZcRED2ImTMWAgELxhd8Jdc aGMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767470805; x=1768075605; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=FxoKlL/Oxj8cjXiUa8fJQ0+WnkWJvGDujzcDraVgeM0=; b=bHefu1fBho+c6NKjlqIS7WgqWD1Yr7L+mnfVmS1RSuA4tNfPKJpYFKoA/t4/ppRspX 9DmbtqO/5AIkSTIZn9xg7dYKF27BBWlQsORdMwQqVHMeoPUFs/gWalU1TJdwt4/x99sh 8APJcyWDY7WkAp1KBUsVzCaeDWXA2fNOjewO78tUIdX7HzDfUySgSA8mPWuTEq9H02Pc spvCq2GCZNmrbcwazsPOW0ojtMVajyRderuqoAW6pDbfI1CstVz5d9YnnYOLFEtdO7Yq Jv5hzGiwok4pDWff/vWG6hMFKs6mqVL/Fux/jhZdo0t6HFwWyBXethlc1NVHHZ2y80vv 6tmw== X-Forwarded-Encrypted: i=1; AJvYcCWcrr0KUHuGMSZzOXXdzbKIHt/6Rv5+O85FMuLTnVGkooUtKDicF9msTdYwolsRmgN17dNFMASeJr1322g=@vger.kernel.org X-Gm-Message-State: AOJu0YzkMQI+SL5mX9U1IAqWJ5EhHFsQPRtIbaEmUOuAM9yFyL7msICB dHvKVke4Os6aPspyXdvwTIg3jW5A+Wmx2mUjTEwts/lT2VLjnCipJ6I9opQ7jgj1AQ== X-Gm-Gg: AY/fxX4iHUtoBNIvorns6KXaLCMieOw8mYK7MPYZxOR5ZV1HT1r7PB2p91L1VCzZR3X s8D0mvbGy5fts7EkWUi+uEhocW6knLRgavJU8okWq/t1wKPpbzAph/CPARiwWfAsuLaTX9XhjD7 eRHH0CD/kOL8pI2RZIl17XwRN17I2dcOxGSJYgF3wNG3N81O9GxeRrL6v2SpF1lS9ZOIkOXgIK6 1onwKBtfNc0SBtVEFIb+8NZGX/H3b/aJRveuau5AYQYauCXPRSDwh0CBDrdqiIIcoJSfMqiGWAi oV5tMMLrEd8qENnoKlmIXEOw000O6moO8q+GTZJ+Z/wLVN3AOEErqBMijiItyCqlDbK7BFHBf6i WwuQ85JRoRLrv8gjkqH11oJAZRDHNsZDZz0QV/OPqblNUIkgxG2roCsWml6cjUZPyfdYr4yJwSX R5vcVEu1TbsI8jqkoHFELzOvlwgRyTS7poYPf7iFBV5XGqlfx9jLXfbCq+FvDBUTmVDtzotMVJJ hRvR1eEyauO86fbL3sNReCcrqQnRvFoYA9RXOZh X-Google-Smtp-Source: AGHT+IHfoggmh0JhJoli31xUldbGfugvSYOe/aHV2oGOtcQp4I/Qk05UR5/AmmfkN/yM1X0DIZGwgw== X-Received: by 2002:a17:907:9347:b0:b79:f4e4:b544 with SMTP id a640c23a62f3a-b8036f5bb20mr4565488666b.21.1767470804883; Sat, 03 Jan 2026 12:06:44 -0800 (PST) Received: from localhost.localdomain (2001-1c00-3405-d100-e1ff-2c8c-c190-2ee3.cable.dynamic.v6.ziggo.nl. [2001:1c00:3405:d100:e1ff:2c8c:c190:2ee3]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8037de11dasm4948022466b.35.2026.01.03.12.06.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 03 Jan 2026 12:06:44 -0800 (PST) From: Boudewijn van der Heide To: akpm@linux-foundation.org Cc: Liam.Howlett@oracle.com, aliceryhl@google.com, andrewjballance@gmail.com, boudewijn@delta-utec.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, maple-tree@lists.infradead.org Subject: Re: [PATCH] maple_tree: Add dead node check in mas_dup_alloc() Date: Sat, 3 Jan 2026 21:06:31 +0100 Message-ID: <20260103200633.246006-1-boudewijn@delta-utec.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260103103247.9140cb2556280927b09f59d3@linux-foundation.org> References: <20260103103247.9140cb2556280927b09f59d3@linux-foundation.org> 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-Transfer-Encoding: 8bit On Sat, 3 Jan 2026, Andrew Morton wrote: > What are the worst-case userspace-visible runtime effects when this > happens? Worst case: if __mt_dup() is invoked without the required external locking and the source tree is concurrently modified, a node can transition to the “dead” RCU layout while mas_dup_alloc() is still traversing it. In that case the code may interpret the rcu_head contents as slot pointers. Practically, this could lead to invalid pointer dereferences (kernel oops) or corruption of the duplicated tree. Depending on how that duplicated tree is later used (e.g. in mm/VMA paths), the effects could be userspace-visible, such as fork() failures, process crashes, or broader system instability. My understanding is that current in-tree users hold the appropriate locks and should not hit this, as triggering it requires violating the __mt_dup() synchronization contract. The risk primarily comes from the fact that __mt_dup() is exported (EXPORT_SYMBOL), making it reachable by out-of-tree modules or future callers which may not follow the locking rules. > If they're bad then presumably we'll want to backport this fix into > earlier kernels with a Cc: and, very > preferably a Fixes: line. The function was introduced without the check here: Fixes: fd32e4e9b764 ("maple_tree: introduce interfaces __mt_dup() and mtree_dup()") If you think this warrants stable backporting as a safety fix, I’m happy to send a v2 with the Fixes: tag and Cc: stable@vger.kernel.org added. Thanks, Boudewijn