From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (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 2286F4A07 for ; Thu, 20 Nov 2025 08:48:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763628536; cv=none; b=ieg9w75uvg+XaFfXBVXVOrWBARzPtaRNXiJIM50OT95VY+d/D7DdNJlxKn01ewyhbvgxdGRwX6BY++ulCoYg+eiTlj7lut2x3CTLsbRDYlWfZtw2uc/K2kFEeBHaa6jcvA7Rdlrdf3tiX+AEncBpzIbNSOFLQr24+a8EeBNLFm4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763628536; c=relaxed/simple; bh=UYCeCV7SxF7B0ZWoXeB/kdyuO5q1rOnca4ZTppc0z8o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MPgGPjjgVLP70vW5+P50rcJDGOa7w13hhdH3lWhKBuTZwdrBqfOuMHoZNneqRD0aCWC1y3zFOOW9P8C5/ONk6jCNZ1oBXjStzyx+7Sfde0ARC02Ql4je4FBMb/on/kT8/f4rkZ/Rg6QE9ItZdOcvWORb8nTXZP9lQSSlDuO0I84= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=V3IHK2bF; arc=none smtp.client-ip=209.85.208.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="V3IHK2bF" Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-640c6577120so1022765a12.1 for ; Thu, 20 Nov 2025 00:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763628531; x=1764233331; 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=eudORTV3HI7IXmvYPGw5oPoaS+974F6g5e+0qgd+ufw=; b=V3IHK2bFuO5uWqbGkq3QcRTsQK6zqSS4OI5APcEblAOrnDIg0YbeyvKkHPi+z39juM oS4+VO4EWwDlkqDNe4jKlkhfQJuk8wkbu4A4G4Ekg8EANECGdw0Ux5rZCLzeZrLdMfJn 3HNUCg9ENyQQHjPRGC33hJAaI6PEIzB/wPazVHbJ2ZwnINfCmrHvMuag6lSI695ZhTsF J0uuUweIS8weJHGixtrWtluKPWB/kRnEWhHipM+vdDXyCuaQyE+uAnPM7rIdpnZ89vkL IY5xLqJ/Bz8Ga6htdtGDRcfmnjYkxnqCzbpCBGxZAvVUimlkaB6osuwPxxsSzvuU91yg uXRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763628531; x=1764233331; 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=eudORTV3HI7IXmvYPGw5oPoaS+974F6g5e+0qgd+ufw=; b=cchhxFsVSmHX5GcVggWNb58rRi/fEZXLIM2BUwtlFvGyQHRo0VF2TuzE70VQfOFdTm zOfdfd7kixpembhrLZwcGLLclHJMpCYuZnXOqi4yck23+MYSAPVwko9ur86jDFN9TQhX xwDFXTjVDanEC9xTwg2Yy6UAPmXQkyXlS68zd9j532Q9H3kXV0nHKRgObgaK8PF/yUxX PTC2lnvFA3aGPY3evc7JxbbQ1S32L0eyB0r/DzC/Md5v6Jv+yPJvb6mR2H5TLsntp4YS jK9/ORWNOw0S4RDYnkXxoLyWh7sOvMsUDhAuJcm90jO2zi9QQIaIT3VtMNitwpQZ5qc+ hyuQ== X-Gm-Message-State: AOJu0Yx9eY6Z13MX0JdRl7G8uh3cJr8uLb/rXcG+uzYZP4LxjSi9y8cw 46PMWaANnjgamc362suDH3fGxMbof8KgP9NaXs7Wf91mINgTWrDAhZiq X-Gm-Gg: ASbGnctQB0LXkTizurgd6f8irt7zEtg44Lmcfy7AQnSl6OKtKgLwkqzaOrQ0bhyf5Fw +uYP8YJxImpgU0vB8F/1gVMeR40lKnZhBtng0L4G7+uzGVW8C3w9otajAXgdEfvZefjyeB1Dlia FG8L6PhsARn/g3oKrAQ8IwEMuQHYL0U1EA5Dc55ZGjgmZIMVXEj76tc5j+Nab4c+O6OvUgrusa2 hqpLHFr46fxrEEqQ+fxT7ElMPgPdvDqsrwrDPoXoHq5z5K8sQyaQoHghr4PsZvU3KV8GUff+Sas 0C8JYW8nFyuxUCOiTdBBGwczYI2TSlQGv77uIHwycXhVKu3StpfvWc8v0rDXDQJe5mZmgOTw9nW he4S6bDhahLqWhsza5TVAtejNLyyp8QKoHC55t0TIHylVBqNiXEHRE2ZKkSoYYhY+jeNpzI+EsF oK8Zo0Edg= X-Google-Smtp-Source: AGHT+IEkRkLNFDvdfRty02CSpceZRVXP0vj7VQbkZjvo/RAJBZ7oofMhULkTmpVfn0lYCGNaJSGyWg== X-Received: by 2002:a17:906:dc91:b0:b71:df18:9fb6 with SMTP id a640c23a62f3a-b76554f2f8emr217731166b.26.1763628531095; Thu, 20 Nov 2025 00:48:51 -0800 (PST) Received: from localhost ([2a02:168:59f0:1:6ea:56ff:fe21:bea7]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b7654d7cafdsm156312966b.30.2025.11.20.00.48.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Nov 2025 00:48:50 -0800 (PST) Date: Thu, 20 Nov 2025 09:48:43 +0100 From: =?iso-8859-1?Q?G=FCnther?= Noack To: =?utf-8?B?6K645L2z5Yev?= Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, =?iso-8859-1?Q?G=FCnther?= Noack , "Serge E. Hallyn" , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Subject: Re: [BUG] landlock: sleeping function called from invalid context in hook_sb_delete() Message-ID: <20251120.c5c17c664315@gnoack.org> References: <20dd8187.9d18.19a75eadc43.Coremail.xujiakai24@mails.ucas.ac.cn> 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: <20dd8187.9d18.19a75eadc43.Coremail.xujiakai24@mails.ucas.ac.cn> Hello! Thanks for the report! CC-ing Mickaël, who authored that code On Wed, Nov 12, 2025 at 10:35:17AM +0800, 许佳凯 wrote: > The call trace indicates that hook_sb_delete() holds s_inode_list_lock (a spinlock) while invoking operations that may eventually call iput(), which can sleep. > This violates the locking context expectations and triggers __might_sleep() warnings. > The issue seems to be related to how Landlock handles superblock cleanup during security_sb_delete(). > > > I’m currently only reporting this issue to the community; the exact fix will likely need to be confirmed and implemented by the Landlock and filesystem maintainers. This looks like a false positive to me. There are three places where iput() is being called in hook_sb_delete, two of them are in places where it is *not* holding the s_inode_list_lock. The one that *is* holding the s_inode_list_lock has the following comment: /* * At this point, we own the ihold() reference that was * originally set up by get_inode_object() and the * __iget() reference that we just set in this loop * walk. Therefore the following call to iput() will * not sleep nor drop the inode because there is now at * least two references to it. */ That seems to indicate that the sleepability concern was taken into consideration. iput() only sleeps if the refcount reaches zero, and if you can exclude that, it won't sleep. —Günther --