From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (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 093A011CA9 for ; Fri, 12 Jun 2026 18:03:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781287387; cv=none; b=nxA2i7FTD94G+h7P1ykOpV8++yS0KtifNgfQgRh5HktsOngUPb87DlSG8ZHbvoRti0m/ZOOUT2E4CEHMtKJ/MDG0Yu31TW51/ExNpjw0prZ1aUW2g26t4vWvN2MFrlNweq3QW6zhXg5LJtTGevTtS6/MPCUWnv7rNEURU08Dj/w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781287387; c=relaxed/simple; bh=mn3yVOv7qKPFWYBvFnk75CZs9rsQ7cExwWlUYRYxI2M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GHJZQiFRiL5vd+AHwRu844tcqYJ/t+UgZvSdXvD3ZBvIUmfhFiowNCcp2yubGjGSj7HfoiPkW3A+oCyNiWxH1WXsmoZbAam1rsbYhS98YgSf+vQ9Qs+TuaLReKHr8X6aJiYrUym/1IYT+ND53+r9nIp/6dj9zwOfodS1sxhySlQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=GFCuv9/M; arc=none smtp.client-ip=209.85.221.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="GFCuv9/M" Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-59d6e44e5c8so850568e0c.2 for ; Fri, 12 Jun 2026 11:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1781287385; x=1781892185; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=fTSufejrrgKqac3GQqcQTlYgn8yTYKUBIBFNWIyXYbU=; b=GFCuv9/MxwRxfP95Inyu3fNIBEX27sdNAe3/K8nXKUmspbdrV4IZpME/g1rGGh42m+ oZKpy3NGBoXg69bCHAbkbW/zwhQUaswxR3RIqnou4ojG/VvO256pNTJNfTLCYjUM2z0g P4t5uKRozfuIdQPZ7JvSp15UI/GqaWsyBWEaNjNHVpJHzrgirjXV+Kq6T8J7DL6gPxkm ACN7wMZKmLvShLfV+F2Cz7Y6N190dKjIijFfqgUhv8U2bbDj+2dya0+zOLIB0vJxNfh4 ID7bk+TRjWZucRzeHw5n4y1jtVwUd70KDL/xkm9LlTu39pHNsVOnbnS0DHwkOaGipoQV Jk1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781287385; x=1781892185; h=in-reply-to: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=fTSufejrrgKqac3GQqcQTlYgn8yTYKUBIBFNWIyXYbU=; b=eg4CmNyf0ME5FDX/VxBca/rCiKDSRAnFrkNjJZJJQPle5JumkW7ofMQDkaVrtksFdM xY+KojlGZIX6aLJIsi38ki0c/uUUk6f8iek6+Z5FHRa92oSXHQVCl84V0LUs+to0RgwN ldjsGbXdod+VZjgVFvM7ty2ot4BxyTRQe0u6/Tpcl8RB0eZr0xve4d82H3a+qkCNbDRB /3idwx8CWXbS3EwekDouQExH3pMviJQYTMmJfP9dCyaMN3Bqryn9wXuZnexOj5Ig2nUX 0PnQRczTzpSUx+l0s8Gl/QUkhx8udmDfa1AQ+IhomEuTLJithyY52yp/B5UlKtiQTDzo S2XA== X-Forwarded-Encrypted: i=1; AFNElJ/Y+/sSAkl3ZagFgD5kFZ6e8qEmtqAd1Hjc+LEHYpkKUYB63xtmkpJPyvXm8CUKxfXpDbAOmN9D8YBQbvM=@vger.kernel.org X-Gm-Message-State: AOJu0YzL40PY2pIS6NvqqsmTZ8YFHHljTDpcPcU+bqHY+szQyPJrChxX 5WrVqhn6IqtJQxA7EhpKzJai50Z2+XlUrjN+doNCgGWUuSwxlYA7+XaDzRlyx8zF6Ic= X-Gm-Gg: Acq92OF6o1Foenwsq3BclJxD9J9ePXwHjB4EDbHjHSQWgPmGBYOB331aCPz9kJeWtjw /DDgko/IjEL42MtZVrfVSd5CrrF/QNdJRJ6jW/ysHoL6334kK7Wu9A+EjY2IfuIPBp+DnPtE9Cs a5kJSjNRlA1sLbWaKDYSUYyzGMgXCiJRBw49GbJwINO5kOAipGIZ74LOpeclSPqjCNjxT6zuPYv mR5nrkhV1UanzzE9fH0JcuwtOo1PDgaaG2uqQarprceQ1YLSYv51AzzKRVSjwjsiliWgLXblnaj gwk6oOK0Bf3qu/7oHnhDyE/12fSfQimOk9TZaBwP04KsajOP5TsY5J7DgR+CPGCNTHeahUAyjt/ Ah5O6qhiJfakOihAVEO8eHRIt88WL5JeLTOm7/ppxMvwz/DnHg9bQ+IEbTQhAuoANdqcmNlmmU3 mw+RXHpephMf7kGsGfswCCxeExJqJCgaIZD5rcUcfUrUEq33EHGDlqGP4Tf9/FfICecJaCK4FRb 3sUuQ== X-Received: by 2002:a05:6122:3c4c:b0:5a0:9ad4:700e with SMTP id 71dfb90a1353d-5bb6bfaae71mr2720111e0c.3.1781287384899; Fri, 12 Jun 2026 11:03:04 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8d304b5f833sm28994906d6.38.2026.06.12.11.03.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2026 11:03:04 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wY6Df-00000008DO2-3Bki; Fri, 12 Jun 2026 15:03:03 -0300 Date: Fri, 12 Jun 2026 15:03:03 -0300 From: Jason Gunthorpe To: Rik van Riel Cc: "Liam R. Howlett" , linux-kernel@vger.kernel.org, kernel-team@meta.com, robin.murphy@arm.com, joro@8bytes.org, will@kernel.org, iommu@lists.linux.dev, kyle@mcmartin.ca, Rik van Riel Subject: Re: [PATCH v3 3/3] iova: defer maple tree erase on GFP_ATOMIC failure Message-ID: <20260612180303.GO1066031@ziepe.ca> References: <20260603033653.4144138-1-riel@surriel.com> <20260603033653.4144138-4-riel@surriel.com> <20260609130418.GI2764304@ziepe.ca> <61d51d4b5779d80145ceb38e9632a7cc8a79dbec.camel@surriel.com> <20260612164852.GL1066031@ziepe.ca> 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-Disposition: inline In-Reply-To: On Fri, Jun 12, 2026 at 01:23:58PM -0400, Rik van Riel wrote: > On Fri, 2026-06-12 at 13:48 -0300, Jason Gunthorpe wrote: > > On Fri, Jun 12, 2026 at 12:02:55PM -0400, Rik van Riel wrote: > > > > > > The mas_erase() function calls mas_nomem(mas, GFP_KERNEL), > > > which is not safe to call while holding a spinlock. > > > > Oh, the kdoc doesn't say that, it doesn't return any error code if it > > can't allocate memory, and not a single caller checks for erase > > failures. > > > > I assumed internally it "somehow worked out" even though there are > > allocations in the callchains.. > > > > This is probably a better question for Liam? Can mtree_erase actually > > fail ENOMEM? Is it safe to call it in an atomic context? > > Yes, it can fail. Currently it never returns a failure to the caller. Look at mas_erase(): entry = mas_state_walk(mas); if (!entry) return NULL; [..] if (mas_is_err(mas)) goto out; [..] out: mas_destroy(mas); return entry; There is no propogation of ENOMEM, it returns success. No caller checks for any error here either. So I think the intention is that it cannot fail, yet it does have the memory allocations and busted failure path. Hence asking Liam what it should be, and what about an atomic context. Perhaps this might be relying on the modern kernels "small allocations never fail", meaning mas_erase never fails, but then you can't call it from an atomic context.. In any case, it does look like you can't use mas_erase from an atomic context anyhow so your prior option with the mas_store_gfp() and failure handling seems reasonable. Jason