From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6BBE11EA84; Fri, 20 Mar 2026 17:24:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774027479; cv=none; b=Zk2FTJypRW44SdRqZhZEY+77CvLCUMkIfOrsMFIbCzbjtz9OIgqVjjHkk19hpGA55k2aWJYszT3cZzIqaES2oHZ5V+KrRNrxiaBoyalas7XGgDChIk5B7rvNB8PRlUO9lFrNXlJwk1rqpbF8yMQ+RXwzWlknV7fTqVVdxY+vAWE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774027479; c=relaxed/simple; bh=9CdwoiZKIF6Qqocl6+Gs6gl4DIsicE2nhb+fS/oX7vc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uWVdibD2cSxor/xNOx56T46T/Q0NfyoGoLzwlP4NUoQy+y3anmzor5bvrFohKRZmewe5dPSn5HJbLAYBaRkEVfSguosuy0wsZ4umq/cWuA2S/4sSS7ykOiHhKCdR4cukGObgmv+xmTwN4J9+0ptMGUAbQJ/DZpvQu2maWreCnOg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=Xr0S5k11; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="Xr0S5k11" Received: from [192.168.1.10] (c-67-168-176-124.hsd1.wa.comcast.net [67.168.176.124]) by linux.microsoft.com (Postfix) with ESMTPSA id 2501E20B6F01; Fri, 20 Mar 2026 10:24:37 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 2501E20B6F01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1774027477; bh=e2sbO8DDbRt/3/I7TQWPjBVS7u7GzWT+lf4DDW28raQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Xr0S5k11/J+JAEBiFmuc/knYVgBvRyFxqVeGd8dm5sbL+6Fzeo0zC8rO1UYUpJ6vp WEQRYVMgtn2Fe6imK9OcnVC8C85PUkn5vcsl06Cjp9LHt/EAv+sTu+ifz3yHU4mWl1 /vv8w5RHrnKGVQgIiqagaoxo54CjOYxAhrXnAyrQ= Message-ID: <8f66014c-d7c8-4a33-be7b-cfd945af4a3a@linux.microsoft.com> Date: Fri, 20 Mar 2026 10:24:37 -0700 Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/3] ima: Add support for staging measurements for deletion To: Roberto Sassu , Mimi Zohar , corbet@lwn.net, skhan@linuxfoundation.org, dmitry.kasatkin@gmail.com, eric.snowberg@oracle.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, gregorylumen@linux.microsoft.com, nramas@linux.microsoft.com, Roberto Sassu , steven chen References: <20260311171956.2317781-1-roberto.sassu@huaweicloud.com> <20260311171956.2317781-3-roberto.sassu@huaweicloud.com> <587e11bf4d29552bbbfc029f716146e8ebfca1eb.camel@linux.ibm.com> <25e0a273-9044-4e0d-9812-0171ec99e1b7@linux.microsoft.com> <332fc1447c03893988620189a40501cccaa8b4c5.camel@huaweicloud.com> Content-Language: en-US From: steven chen In-Reply-To: <332fc1447c03893988620189a40501cccaa8b4c5.camel@huaweicloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/20/2026 10:10 AM, Roberto Sassu wrote: > On Fri, 2026-03-20 at 09:58 -0700, steven chen wrote: >> On 3/20/2026 5:41 AM, Mimi Zohar wrote: >>> On Thu, 2026-03-19 at 14:31 -0700, steven chen wrote: >>> >>>>> - Support for deleting N measurement records (and pre-pending the remaining >>>>> measurement records) >>>> Is there any problem to bring work of "stage" step together to the >>>> deletion step? >>>> >>>> "Trim N" method does everything that "staged" method can do, right? >>>> what's the "stage" method can do but "trim N" method can't do? >>>> >>>> in user space, if in "staged" state, no other user space agent can >>>> access the IMA measure list, right? >>>> >>>> Could you explain the benefit of bringing the "stage" step? >>> The performance improvement is because "staging" the IMA measurement list takes >>> the lock in order to move the measurement list pointer and then releases it. >>> New measurements can then be appended to a new measurement list. Deleting >>> records is done without taking the lock to walk the staged measurement list. >>> >>> Without staging the measurement list, walking the measurement list to trim N >>> records requires taking and holding the lock. The performance is dependent on >>> the size of the measurement list. >>> >>> Your question isn't really about "staging" the measurement list records, but >>> requiring a userspace signal to delete them. To answer that question, deleting >>> N records (third patch) could imply staging all the measurement records and >>> immediately deleting N records without an explicit userspace signal. >>> >>> I expect the requested "documentation" patch will provide the motivation for the >>> delayed deletion of the measurement list. >>> >>> Mimi >> "Staging" is great on reducing kernel IMA measurement list locking time. >> >> How about just do "stage N" entries and then delete the staged list in >> one shot? >> It means merge two APIs into one API >>     int ima_queue_stage(void) >>     int ima_queue_delete_staged(unsigned long req_value) >> >> The kernel lock time will be the same. And user space lock time will be >> reduced. > It is not the same. The walk on the staged list is done without holding > ima_extend_list_mutex. > > Roberto Is it possible to merge two APIs work into one API?     int ima_queue_stage(void)     int ima_queue_delete_staged(unsigned long req_value) Thank, Steven