* [BUG] lsm= with bpf before selinux breaks fscreate with EINVAL
From: Vitaly Chikunov @ 2026-05-10 21:17 UTC (permalink / raw)
To: linux-security-module, bpf, selinux
Cc: Paul Moore, KP Singh, Matt Bobrowski, Stephen Smalley,
Ondrej Mosnacek, linux-kernel
Hi,
We have boot failure when CONFIG_LSM has "bpf" listed before "selinux"
(without bpf lsm scripts loaded). (This also happens with a boot with
"security=selinux" if selinux was not in LSM= list but bpf is.)
systemd reports on the failing boot attempt:
Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/shm: Invalid argument
Mounting tmpfs to /dev/shm of type tmpfs with options mode=01777.
Mounting tmpfs (tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777")...
Failed to mount tmpfs (type tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777"): No such file or directory
Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/pts: Invalid argument
Mounting devpts to /dev/pts of type devpts with options mode=0620,gid=5.
Mounting devpts (devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5")...
Failed to mount devpts (type devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5"): No such file or directory
No filesystem is currently mounted on /sys/fs/cgroup.
Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/cgroup: Invalid argument
Mounting cgroup2 to /sys/fs/cgroup of type cgroup2 with options nsdelegate,memory_recursiveprot.
Mounting cgroup2 (cgroup2) on /sys/fs/cgroup (MS_NOSUID|MS_NODEV|MS_NOEXEC "nsdelegate,memory_recursiveprot")...
Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/pstore: Invalid argument
Mounting pstore to /sys/fs/pstore of type pstore with options n/a.
Mounting pstore (pstore) on /sys/fs/pstore (MS_NOSUID|MS_NODEV|MS_NOEXEC "")...
Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/bpf: Invalid argument
Mounting bpf to /sys/fs/bpf of type bpf with options mode=0700.
Mounting bpf (bpf) on /sys/fs/bpf (MS_NOSUID|MS_NODEV|MS_NOEXEC "mode=0700")...
[!!!!!!] Failed to mount API filesystems.
Freezing execution
'Invalid arguments' seems from setfscreatecon_raw.
Reproducer:
Boot with lsm=lockdown,capability,landlock,yama,safesetid,bpf,selinux,ima,evm
(none):~# cat /proc/thread-self/attr/current
cat: /proc/thread-self/attr/current: Invalid argument
(none):~# echo > /proc/thread-self/attr/fscreate
bash: echo: write error: Invalid argument
This appears to be caused by security_getprocattr / security_setprocattr
iterating until the first hook defined (which is bpf) and returning with
default value -EINVAL before selinux even sees them.
Perhaps, bpf LSM should avoid registering getprocattr/setprocattr hooks
that it does not implement, or the legacy LSM_ID_UNDEF procattr dispatch
should skip LSMs that cannot handle the requested attribute and continue
to seLinux (or whatever).
Thanks,
^ permalink raw reply
* [PATCH 0/2] smack: fix incorrect task context in smack_msg_queue_msgrcv
From: Konstantin Andreev @ 2026-05-11 0:17 UTC (permalink / raw)
To: casey; +Cc: linux-security-module
The 1st patch in the set is the fix itself,
the 2nd is a followup to resolve an ambiguity in the audit log.
The patch set applies on top of:
https://github.com/cschaufler/smack-next/commits/next
commit b78fede1c69a
Konstantin Andreev (2):
smack: fix incorrect task context in smack_msg_queue_msgrcv
smack: show msgrcv() subject task in audit
security/smack/smack.h | 1 +
security/smack/smack_access.c | 9 +++++
security/smack/smack_lsm.c | 67 +++++++++++++++++++++++++----------
3 files changed, 59 insertions(+), 18 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH 2/2] smack: show msgrcv() subject task in audit
From: Konstantin Andreev @ 2026-05-11 0:17 UTC (permalink / raw)
To: casey; +Cc: linux-security-module
In-Reply-To: <20260511001717.3522345-1-andreev@swemel.ru>
When a task msgrcv()'es some message the SMACK audit log message
looks like:
fn=smk_tskacc_msq action=denied subject="bar" object="foo" requested=rw
pid=456 comm="mrcv" ipc_key=2
fn=smk_tskacc_msq action=granted subject="bar" object="foo" requested=rw
pid=519 comm="mrcv" ipc_key=2
where pid= is a pid of a “current” task which calls smk_tskacc_msq().
Usually, the caller of smk_tskacc_msq() is also a subject task
which determines its own permission. In the example above
the 'mrcv' process has label 'bar' and wants "rw" for label "foo".
However, when sender task delivers message using
ipc/msg.c`pipelined_send():
` security_msg_queue_msgrcv(,, msr->r_tsk,,)
` smp_store_release(&msr->r_msg, msg)
“current” task and “subject” task differ, and
the “subject” task is missed from the audit message.
This patch adds two fields, subj_pid and subj_comm,
into the audit message:
fn=smk_tskacc_msq action=granted subject="bar" object="foo" requested=rw
subj_pid=564 subj_comm="mrcv" pid=577 comm="msnd" ipc_key=2
Signed-off-by: Konstantin Andreev <andreev@swemel.ru>
---
security/smack/smack.h | 1 +
security/smack/smack_access.c | 9 +++++++++
security/smack/smack_lsm.c | 2 ++
3 files changed, 12 insertions(+)
diff --git a/security/smack/smack.h b/security/smack/smack.h
index 9b9eb262fe33..551fcf2a1832 100644
--- a/security/smack/smack.h
+++ b/security/smack/smack.h
@@ -261,6 +261,7 @@ struct smack_audit_data {
char *subject;
char *object;
char *request;
+ struct task_struct *subj_tsk;
int result;
};
diff --git a/security/smack/smack_access.c b/security/smack/smack_access.c
index 350b88d582b3..fb85356266e5 100644
--- a/security/smack/smack_access.c
+++ b/security/smack/smack_access.c
@@ -331,6 +331,15 @@ static void smack_log_callback(struct audit_buffer *ab, void *a)
audit_log_format(ab, " labels_differ");
else
audit_log_format(ab, " requested=%s", sad->request);
+
+ if (sad->subj_tsk) {
+ char comm[TASK_COMM_LEN];
+
+ audit_log_format(ab, " subj_pid=%d subj_comm=",
+ task_tgid_nr(sad->subj_tsk));
+ audit_log_untrustedstring(ab,
+ get_task_comm(comm, sad->subj_tsk));
+ }
}
/**
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 3146fa83c2f1..6f6ff9b20981 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -3383,6 +3383,8 @@ smk_tskacc_msq(struct task_struct *tsk, struct kern_ipc_perm *isp, int access)
#ifdef CONFIG_AUDIT
smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_IPC);
ad.a.u.ipc_id = isp->id;
+ if (!tsk_is_current)
+ ad.sad.subj_tsk = tsk;
#endif
rc = smk_tskacc(tsp, msp, access, &ad);
rc = smk_bu_tsk_to_obj(tsk, tsp, "msq", msp, access, rc);
--
2.47.3
^ permalink raw reply related
* [PATCH 1/2] smack: fix incorrect task context in smack_msg_queue_msgrcv
From: Konstantin Andreev @ 2026-05-11 0:17 UTC (permalink / raw)
To: casey; +Cc: linux-security-module
In-Reply-To: <20260511001717.3522345-1-andreev@swemel.ru>
The smack_msg_queue_msgrcv() function incorrectly checks
the permissions of the 'current' task instead of the
'target' task.
In the msgsnd() syscall path, if a receiver is already waiting,
the pipelined_send() optimization is used to push the message
directly to the receiver task:
ipc/msg.c`pipelined_send():
` smp_store_release(&msr->r_msg, msg)
In this case, the 'sender' (current) task performs the check
on behalf of the 'receiver' task (msr->r_tsk, passed as the
'target' parameter):
ipc/msg.c`pipelined_send():
` security_msg_queue_msgrcv(,, target := msr->r_tsk,,)
However, smack_msg_queue_msgrcv() ignores the 'target' and
checks 'current':
smack_msg_queue_msgrcv(…)
` smk_curacc_msq(isp, MAY_READWRITE); // current task
'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement,
but 'target' (the receiver task) might NOT;
as a result, an unauthorized receiver gets the message,
violating MAC policy.
Test:
1) create a sysv message queue with label “foo”
2) echo "bar foo r" >/smack/load2
3) msgrcv(,,,0,MSG_NOERROR) in "bar"-labeled task.
The task is waiting for the messages ...
4) msgsnd() from a "foo"-labeled task:
"bar"-labeled task gets the message.
This patch fixes the issue by checking permission on the
'target' task instead of 'current'.
(2008-02-04, Casey Schaufler)
Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel")
Signed-off-by: Konstantin Andreev <andreev@swemel.ru>
---
security/smack/smack_lsm.c | 65 +++++++++++++++++++++++++++-----------
1 file changed, 47 insertions(+), 18 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index f4ef840b203e..3146fa83c2f1 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -130,12 +130,13 @@ static int smk_bu_note(char *note, struct smack_known *sskp,
#define smk_bu_note(note, sskp, oskp, mode, RC) (RC)
#endif
-#ifdef CONFIG_SECURITY_SMACK_BRINGUP
-static int smk_bu_current(char *note, struct smack_known *oskp,
- int mode, int rc)
+static int
+smk_bu_tsk_to_obj(struct task_struct *tsk, const struct task_smack *tsp,
+ char *note, struct smack_known *oskp, int mode, int rc)
{
- struct task_smack *tsp = smack_cred(current_cred());
+#ifdef CONFIG_SECURITY_SMACK_BRINGUP
char acc[SMK_NUM_ACCESS_TYPE + 1];
+ char comm[TASK_COMM_LEN];
if (rc <= 0)
return rc;
@@ -143,14 +144,22 @@ static int smk_bu_current(char *note, struct smack_known *oskp,
rc = 0;
smk_bu_mode(mode, acc);
+
pr_info("Smack %s: (%s %s %s) %s %s\n", smk_bu_mess[rc],
- tsp->smk_task->smk_known, oskp->smk_known,
- acc, current->comm, note);
+ smk_of_task(tsp)->smk_known, oskp->smk_known,
+ acc, get_task_comm(comm, tsk), note);
return 0;
-}
#else
-#define smk_bu_current(note, oskp, mode, RC) (RC)
+ return rc;
#endif
+}
+
+static int smk_bu_current(char *note, struct smack_known *oskp,
+ int mode, int rc)
+{
+ return smk_bu_tsk_to_obj(current, smack_cred(current_cred()),
+ note, oskp, mode, rc);
+}
#ifdef CONFIG_SECURITY_SMACK_BRINGUP
static int smk_bu_task(struct task_struct *otp, int mode, int rc)
@@ -3353,14 +3362,20 @@ static int smack_sem_semop(struct kern_ipc_perm *isp, struct sembuf *sops,
}
/**
- * smk_curacc_msq : helper to check if current has access on msq
- * @isp : the msq
+ * smk_tskacc_msq : helper to check if tsk has access on msq
+ * @tsk: the task that requests access
+ * @isp : the sysv msg queue permissions
* @access : access requested
*
- * return 0 if current has access, error otherwise
+ * return 0 if tsk has access, error otherwise
*/
-static int smk_curacc_msq(struct kern_ipc_perm *isp, int access)
+static int
+smk_tskacc_msq(struct task_struct *tsk, struct kern_ipc_perm *isp, int access)
{
+ const bool tsk_is_current = (tsk == current);
+ const struct cred * const tsk_cred =
+ (tsk_is_current ? current_cred() : get_task_cred(tsk));
+ struct task_smack * const tsp = smack_cred(tsk_cred);
struct smack_known *msp = smack_of_ipc(isp);
struct smk_audit_info ad;
int rc;
@@ -3369,11 +3384,25 @@ static int smk_curacc_msq(struct kern_ipc_perm *isp, int access)
smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_IPC);
ad.a.u.ipc_id = isp->id;
#endif
- rc = smk_curacc(msp, access, &ad);
- rc = smk_bu_current("msq", msp, access, rc);
+ rc = smk_tskacc(tsp, msp, access, &ad);
+ rc = smk_bu_tsk_to_obj(tsk, tsp, "msq", msp, access, rc);
+ if (!tsk_is_current)
+ put_cred(tsk_cred);
return rc;
}
+/**
+ * smk_curacc_msq : helper to check if current has access on msq
+ * @isp : the sysv msg queue permissions
+ * @access : access requested
+ *
+ * return 0 if current has access, error otherwise
+ */
+static int smk_curacc_msq(struct kern_ipc_perm *isp, int access)
+{
+ return smk_tskacc_msq(current, isp, access);
+}
+
/**
* smack_msg_queue_associate - Smack access check for msg_queue
* @isp: the object
@@ -3441,21 +3470,21 @@ static int smack_msg_queue_msgsnd(struct kern_ipc_perm *isp, struct msg_msg *msg
}
/**
- * smack_msg_queue_msgrcv - Smack access check for msg_queue
+ * smack_msg_queue_msgrcv - check it target has r/w access to msg_queue
* @isp: the object
* @msg: unused
- * @target: unused
+ * @target: the task that msgrcv() from the queue
* @type: unused
* @mode: unused
*
- * Returns 0 if current has read and write access, error code otherwise
+ * Returns 0 if target has read and write access, error code otherwise
*/
static int smack_msg_queue_msgrcv(struct kern_ipc_perm *isp,
struct msg_msg *msg,
struct task_struct *target, long type,
int mode)
{
- return smk_curacc_msq(isp, MAY_READWRITE);
+ return smk_tskacc_msq(target, isp, MAY_READWRITE);
}
/**
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 1/3] cgroup/cpuset: Fix deadline bandwidth leak in cpuset_can_attach()
From: Waiman Long @ 2026-05-11 5:10 UTC (permalink / raw)
To: Aaron Tomlin, tsbogend, paul, jmorris, serge, mingo, peterz,
juri.lelli, vincent.guittot, stephen.smalley.work, casey, tj,
hannes, mkoutny
Cc: chenridong, dietmar.eggemann, rostedt, bsegall, mgorman, vschneid,
kprateek.nayak, omosnace, kees, neelx, sean, chjohnst, steve,
mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <20260509164847.939294-2-atomlin@atomlin.com>
On 5/9/26 12:48 PM, Aaron Tomlin wrote:
> During a cgroup migration, cpuset_can_attach() iterates over the
> provided taskset. If a task within the batch is a deadline (DL) task,
> the destination cpuset's DL metrics (i.e., nr_migrate_dl_tasks and
> sum_migrate_dl_bw) are appropriately incremented.
>
> However, if a subsequent task in the same migration batch fails the
> task_can_attach() check, the loop aborts and jumps directly to
> out_unlock. Consequently, any DL metrics accumulated from previously
> processed tasks in the batch remain permanently inflated in the
> destination cpuset. Because the migration is subsequently aborted by the
> cgroup core, cpuset_cancel_attach() is never invoked to unwind these
> specific increments.
>
> This behaviour results in a permanent leak of deadline bandwidth, which
> incorrectly restricts the admission control capacity of the destination
> cpuset.
>
> To resolve this, introduce an out_unlock_reset failure path that
> conditionally invokes reset_migrate_dl_data(). This guarantees that if a
> batch migration is aborted for any reason, the pending DL metrics are
> safely reset before returning the error.
>
> Fixes: 0a67b847e1f06 ("cpuset: Allow setscheduler regardless of manipulated task")
That is not the commit that introduced the bug. Anyway, there is already
another patch sent recently to fix this bug. See
https://lore.kernel.org/lkml/20260509102031.97608-2-zhangguopeng@kylinos.cn/
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH 1/3] cgroup/cpuset: Fix deadline bandwidth leak in cpuset_can_attach()
From: Aaron Tomlin @ 2026-05-11 11:08 UTC (permalink / raw)
To: Waiman Long
Cc: tsbogend, paul, jmorris, serge, mingo, peterz, juri.lelli,
vincent.guittot, stephen.smalley.work, casey, tj, hannes, mkoutny,
chenridong, dietmar.eggemann, rostedt, bsegall, mgorman, vschneid,
kprateek.nayak, omosnace, kees, neelx, sean, chjohnst, steve,
mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <8aaa7dd9-2426-475c-af64-85ef5f2aa855@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]
On Mon, May 11, 2026 at 01:10:02AM -0400, Waiman Long wrote:
>
> On 5/9/26 12:48 PM, Aaron Tomlin wrote:
> > During a cgroup migration, cpuset_can_attach() iterates over the
> > provided taskset. If a task within the batch is a deadline (DL) task,
> > the destination cpuset's DL metrics (i.e., nr_migrate_dl_tasks and
> > sum_migrate_dl_bw) are appropriately incremented.
> >
> > However, if a subsequent task in the same migration batch fails the
> > task_can_attach() check, the loop aborts and jumps directly to
> > out_unlock. Consequently, any DL metrics accumulated from previously
> > processed tasks in the batch remain permanently inflated in the
> > destination cpuset. Because the migration is subsequently aborted by the
> > cgroup core, cpuset_cancel_attach() is never invoked to unwind these
> > specific increments.
> >
> > This behaviour results in a permanent leak of deadline bandwidth, which
> > incorrectly restricts the admission control capacity of the destination
> > cpuset.
> >
> > To resolve this, introduce an out_unlock_reset failure path that
> > conditionally invokes reset_migrate_dl_data(). This guarantees that if a
> > batch migration is aborted for any reason, the pending DL metrics are
> > safely reset before returning the error.
> >
> > Fixes: 0a67b847e1f06 ("cpuset: Allow setscheduler regardless of manipulated task")
>
> That is not the commit that introduced the bug. Anyway, there is already
> another patch sent recently to fix this bug. See
>
> https://lore.kernel.org/lkml/20260509102031.97608-2-zhangguopeng@kylinos.cn/
>
Hi Waiman,
Thank you for the follow up.
Acknowledged. I will drop this patch in the next iteration due to [1].
Please note, the sashiko AI Review bot reported: cpuset_can_attach()
incorrectly assumes all migrating tasks originate from the same source
cpuset. At first glance, this feedback is valid. I plan to submit a patch,
if no solution was already proposed.
[1]: https://lore.kernel.org/lkml/20260509102031.97608-2-zhangguopeng@kylinos.cn/
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 00/13] ima: Introduce staging mechanism
From: Lakshmi Ramasubramanian @ 2026-05-11 17:29 UTC (permalink / raw)
To: steven chen, Roberto Sassu, corbet, skhan, zohar, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, Roberto Sassu
In-Reply-To: <99c30be6-8b0f-486a-890c-cf74c5930726@linux.microsoft.com>
On 5/7/2026 9:47 AM, steven chen wrote:
>>
>> Usage
>> =====
>>
>> The IMA staging mechanism can be enabled from the kernel configuration
>> with the CONFIG_IMA_STAGING option.
>>
>> If it is enabled, IMA duplicates the current measurements interfaces
>> (both binary and ASCII), by adding the _staged file suffix. Both the
>> original and the staging interfaces gain the write permission for the
>> root user and group, but require the process to have CAP_SYS_ADMIN set.
>>
>> The staging mechanism supports two flavors.
>>
>> Staging with prompt
>> ~~~~~~~~~~~~~~~~~~~
>>
>> The current measurements list is moved to a temporary staging area, and
>> staged measurements are deleted upon confirmation.
>>
>> This staging process is achieved with the following steps.
>>
>> 1. echo A > <original interface>: the user requests IMA to stage the
>> entire measurements list;
>> 2. cat <_staged interface>: the user reads the staged measurements;
>> 3. echo D > <_staged interface>: the user requests IMA to delete
>> staged measurements.
>>
>> Staging and deleting
>> ~~~~~~~~~~~~~~~~~~~~
>>
>> N measurements are staged to a temporary staging area, and immediately
>> deleted without further confirmation.
>>
>> This staging process is achieved with the following steps.
>>
>> 1. cat <original interface>: the user reads the current measurements
>> list and determines what the value N for staging should be;
>> 2. echo N > <original interface>: the user requests IMA to delete N
>> measurements from the current measurements list.
>
> This submission proposes two ways for log trimming:
>
> *Flavor 1:* Staging with prompt
> *Flavor 2:* stage and delete N
>
> Functionally, both approaches address the same problem, but *Favour 2
> *is the
> stronger design and should be preferred. There is no good reason to keep
> *Flavor 1.*
>
> From a kernel implementation perspective, *Flavor 2 *is more efficient
> because it
> minimizes the time spent holding the list lock (can’t be shorter). It
> also substantially
> reduces the amount of kernel-side logic, removing nearly half of the
> code required
> by the alternative approach.
>
> From a user-space perspective, *Flavor 2 *results in a much cleaner
> model. It avoids
> the need to track and reconcile both old and staged lists in user space
> as well as
> two lists (cur and staged) in the kernel space, which simplifies log
> trimming logic
> and reduces maintenance overhead. In addition, it preserves the existing
> external
> behavior by not exposing any staged list to user space.
>
> Overall, *Flavor 2 *provides the same functional result with lower
> kernel complexity,
> shorter kernel list lock hold time, and a simpler user-space interface.
> For those
> reasons, it is the preferable approach and *Favour 1* does not appear to
> offer sufficient
> justification to keep both implementations.
>
> Steven
Roberto, Mimi:
I want to add on to the point Steven has brought up.
With "Stage and Delete N" approach, we have the following sequence of
tasks for trimming the IMA log:
1. User mode locks the IMA measurement list through the "write interface".
a. While this prevents any other user mode process from updating the
IMA log, kernel can still add new IMA events to the measurement log
2. User mode reads the TPM Quote and the IMA measurement events and
sends it to the remote attestation service
3. Once the remote service has successfully processed the IMA events,
the user mode determines the number of IMA events "N" to be removed from
the measurement list maintained in the kernel
4. User mode provides the value "N" to the kernel
5. Kernel now determines the point at which to snap the IMA measurement
list using "N" - without holding a lock
6. Then, the kernel lock is held and the list is snapped at the point
determined in the previous step thus keeping the kernel lock time to the
minimum.
7. Now, user mode removes the "write" lock on the IMA measurement list
With the above, we believe "Stage and Delete N" alone is sufficient to
trim IMA log.
-lakshmi
>> .../admin-guide/kernel-parameters.txt | 4 +
>> Documentation/security/IMA-staging.rst | 163 +++++++++
>> Documentation/security/index.rst | 1 +
>> MAINTAINERS | 2 +
>> security/integrity/ima/Kconfig | 16 +
>> security/integrity/ima/ima.h | 32 +-
>> security/integrity/ima/ima_api.c | 2 +-
>> security/integrity/ima/ima_fs.c | 315 ++++++++++++++++--
>> security/integrity/ima/ima_init.c | 5 +
>> security/integrity/ima/ima_kexec.c | 53 ++-
>> security/integrity/ima/ima_queue.c | 283 ++++++++++++++--
>> 11 files changed, 803 insertions(+), 73 deletions(-)
>> create mode 100644 Documentation/security/IMA-staging.rst
>>
^ permalink raw reply
* Re: [PATCH 1/3] cgroup/cpuset: Fix deadline bandwidth leak in cpuset_can_attach()
From: Waiman Long @ 2026-05-11 17:54 UTC (permalink / raw)
To: Aaron Tomlin
Cc: tsbogend, paul, jmorris, serge, mingo, peterz, juri.lelli,
vincent.guittot, stephen.smalley.work, casey, tj, hannes, mkoutny,
chenridong, dietmar.eggemann, rostedt, bsegall, mgorman, vschneid,
kprateek.nayak, omosnace, kees, neelx, sean, chjohnst, steve,
mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <aihz6zlfmcaxwb3ef4luisfpwqibwsajpphy5vzuksy3ftfkms@whhv2ax5plpb>
On 5/11/26 7:08 AM, Aaron Tomlin wrote:
> On Mon, May 11, 2026 at 01:10:02AM -0400, Waiman Long wrote:
>> On 5/9/26 12:48 PM, Aaron Tomlin wrote:
>>> During a cgroup migration, cpuset_can_attach() iterates over the
>>> provided taskset. If a task within the batch is a deadline (DL) task,
>>> the destination cpuset's DL metrics (i.e., nr_migrate_dl_tasks and
>>> sum_migrate_dl_bw) are appropriately incremented.
>>>
>>> However, if a subsequent task in the same migration batch fails the
>>> task_can_attach() check, the loop aborts and jumps directly to
>>> out_unlock. Consequently, any DL metrics accumulated from previously
>>> processed tasks in the batch remain permanently inflated in the
>>> destination cpuset. Because the migration is subsequently aborted by the
>>> cgroup core, cpuset_cancel_attach() is never invoked to unwind these
>>> specific increments.
>>>
>>> This behaviour results in a permanent leak of deadline bandwidth, which
>>> incorrectly restricts the admission control capacity of the destination
>>> cpuset.
>>>
>>> To resolve this, introduce an out_unlock_reset failure path that
>>> conditionally invokes reset_migrate_dl_data(). This guarantees that if a
>>> batch migration is aborted for any reason, the pending DL metrics are
>>> safely reset before returning the error.
>>>
>>> Fixes: 0a67b847e1f06 ("cpuset: Allow setscheduler regardless of manipulated task")
>> That is not the commit that introduced the bug. Anyway, there is already
>> another patch sent recently to fix this bug. See
>>
>> https://lore.kernel.org/lkml/20260509102031.97608-2-zhangguopeng@kylinos.cn/
>>
> Hi Waiman,
>
> Thank you for the follow up.
>
> Acknowledged. I will drop this patch in the next iteration due to [1].
>
> Please note, the sashiko AI Review bot reported: cpuset_can_attach()
> incorrectly assumes all migrating tasks originate from the same source
> cpuset. At first glance, this feedback is valid. I plan to submit a patch,
> if no solution was already proposed.
>
> [1]: https://lore.kernel.org/lkml/20260509102031.97608-2-zhangguopeng@kylinos.cn/
Yes, it does look like the AI feedback is valid. I will take a further
look into this.
Thanks,
Longman
^ permalink raw reply
* Re: [PATCH v3 2/7] apparmor: Remove redundant MS_MGC_MSK stripping in apparmor_sb_mount
From: Paul Moore @ 2026-05-11 19:52 UTC (permalink / raw)
To: john.johansen, georgia.garcia, Song Liu, linux-security-module,
linux-fsdevel, selinux, apparmor
Cc: jmorris, serge, viro, brauner, jack, stephen.smalley.work,
omosnace, mic, gnoack, takedakn, penguin-kernel, herton,
kernel-team, Song Liu
In-Reply-To: <20260509015208.3853132-3-song@kernel.org>
On May 8, 2026 Song Liu <song@kernel.org> wrote:
>
> path_mount() already strips the magic number from flags before
> calling security_sb_mount(), so this check in apparmor_sb_mount()
> is a no-op. Remove it.
>
> Code generated with the assistance of Claude, reviewed by human.
>
> Signed-off-by: Song Liu <song@kernel.org>
> ---
> security/apparmor/lsm.c | 4 ----
> 1 file changed, 4 deletions(-)
John, Georgia, are you okay with this patch?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 3/7] apparmor: Convert from sb_mount to granular mount hooks
From: Paul Moore @ 2026-05-11 19:52 UTC (permalink / raw)
To: john.johansen, georgia.garcia, Song Liu, linux-security-module,
linux-fsdevel, selinux, apparmor
Cc: jmorris, serge, viro, brauner, jack, stephen.smalley.work,
omosnace, mic, gnoack, takedakn, penguin-kernel, herton,
kernel-team, Song Liu
In-Reply-To: <20260509015208.3853132-4-song@kernel.org>
On May 8, 2026 Song Liu <song@kernel.org> wrote:
>
> Replace AppArmor's monolithic apparmor_sb_mount() with granular
> mount hooks.
>
> Key changes:
> - mount_bind: uses the pre-resolved struct path from VFS instead of
> re-resolving dev_name via kern_path(), eliminating a TOCTOU
> vulnerability. aa_bind_mount() now takes a struct path instead of
> a string for the source.
> - mount_new, mount_remount: receive the original mount(2) flags and
> data parameters for policy matching via match_mnt_flags() and
> AA_MNT_CONT_MATCH data matching.
> - mount_reconfigure: handles MS_REMOUNT|MS_BIND (mount attribute
> reconfiguration) which was previously handled as a remount.
> - mount_move: reuses apparmor_move_mount() which already handles
> pre-resolved paths.
> - mount_change_type: propagation type changes.
>
> aa_move_mount_old() is removed since move mounts now go through
> security_mount_move() with pre-resolved struct path pointers for
> both the old mount(2) and new move_mount(2) APIs.
>
> Code generated with the assistance of Claude, reviewed by human.
>
> Signed-off-by: Song Liu <song@kernel.org>
> ---
> security/apparmor/include/mount.h | 5 +-
> security/apparmor/lsm.c | 99 ++++++++++++++++++++++++-------
> security/apparmor/mount.c | 37 ++----------
> 3 files changed, 83 insertions(+), 58 deletions(-)
John, Georgia, are you guys okay with this patch?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 5/7] landlock: Convert from sb_mount to granular mount hooks
From: Paul Moore @ 2026-05-11 19:52 UTC (permalink / raw)
To: mic, gnoack, Song Liu, linux-security-module, linux-fsdevel,
selinux, apparmor
Cc: jmorris, serge, viro, brauner, jack, john.johansen,
stephen.smalley.work, omosnace, takedakn, penguin-kernel, herton,
kernel-team, Song Liu
In-Reply-To: <20260509015208.3853132-6-song@kernel.org>
On May 8, 2026 Song Liu <song@kernel.org> wrote:
>
> Replace hook_sb_mount() with granular mount hooks. Landlock denies
> all mount operations for sandboxed processes regardless of flags,
> so all new hooks share a common hook_mount_deny() helper. The
> mount_move hook reuses hook_move_mount().
>
> Code generated with the assistance of Claude, reviewed by human.
>
> Signed-off-by: Song Liu <song@kernel.org>
> ---
> security/landlock/fs.c | 40 ++++++++++++++++++++++++++++++++++++----
> 1 file changed, 36 insertions(+), 4 deletions(-)
Mickaël, Günther, are you okay with this patch?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 6/7] tomoyo: Convert from sb_mount to granular mount hooks
From: Paul Moore @ 2026-05-11 19:52 UTC (permalink / raw)
To: penguin-kernel, Song Liu, linux-security-module, linux-fsdevel,
selinux, apparmor
Cc: jmorris, serge, viro, brauner, jack, john.johansen,
stephen.smalley.work, omosnace, mic, gnoack, takedakn, herton,
kernel-team, Song Liu
In-Reply-To: <20260509015208.3853132-7-song@kernel.org>
On May 8, 2026 Song Liu <song@kernel.org> wrote:
>
> Replace tomoyo_sb_mount() with granular mount hooks. Each hook
> reconstructs the MS_* flags expected by tomoyo_mount_permission()
> using the original flags parameter where available.
>
> Key changes:
> - mount_bind: passes the pre-resolved source path to
> tomoyo_mount_acl() via a new dev_path parameter, instead of
> re-resolving dev_name via kern_path(). This eliminates a TOCTOU
> vulnerability.
> - mount_new, mount_remount, mount_reconfigure: use the original
> mount(2) flags for policy matching.
> - mount_move: passes pre-resolved paths for both source and
> destination.
> - mount_change_type: passes raw ms_flags directly.
>
> Also removes the unused data_page parameter from
> tomoyo_mount_permission().
>
> Code generated with the assistance of Claude, reviewed by human.
>
> Signed-off-by: Song Liu <song@kernel.org>
> ---
> security/tomoyo/common.h | 2 +-
> security/tomoyo/mount.c | 31 +++++++++++++-------
> security/tomoyo/tomoyo.c | 63 ++++++++++++++++++++++++++++++----------
> 3 files changed, 70 insertions(+), 26 deletions(-)
Tetsuo, I know you had several comments on an earlier revision. Can you
either ACK this or let Song know what changes you require?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 7/7] lsm: Remove security_sb_mount and security_move_mount
From: Paul Moore @ 2026-05-11 19:52 UTC (permalink / raw)
To: Song Liu, linux-security-module, linux-fsdevel, selinux, apparmor
Cc: jmorris, serge, viro, brauner, jack, john.johansen,
stephen.smalley.work, omosnace, mic, gnoack, takedakn,
penguin-kernel, herton, kernel-team, Song Liu
In-Reply-To: <20260509015208.3853132-8-song@kernel.org>
On May 8, 2026 Song Liu <song@kernel.org> wrote:
>
> Now that all LSMs have been converted to granular mount hooks,
> remove the old hooks:
>
> - security_sb_mount(): removed from lsm_hook_defs.h, security.h,
> security.c, and its call in path_mount().
> - security_move_mount(): removed and replaced by security_mount_move()
> in do_move_mount(). All LSMs now use mount_move exclusively.
>
> Code generated with the assistance of Claude, reviewed by human.
>
> Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> Tested-by: Stephen Smalley <stephen.smalley.work@gmail.com> # for selinux only
> Signed-off-by: Song Liu <song@kernel.org>
> ---
> fs/namespace.c | 8 --------
> include/linux/lsm_hook_defs.h | 4 ----
> include/linux/security.h | 16 ---------------
> kernel/bpf/bpf_lsm.c | 2 --
> security/apparmor/lsm.c | 1 -
> security/landlock/fs.c | 1 -
> security/security.c | 38 -----------------------------------
> security/selinux/hooks.c | 2 --
> 8 files changed, 72 deletions(-)
...
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index e0a8a44c95aa..b0de7f316f51 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1705,7 +1705,6 @@ static struct security_hook_list apparmor_hooks[] __ro_after_init = {
> LSM_HOOK_INIT(capget, apparmor_capget),
> LSM_HOOK_INIT(capable, apparmor_capable),
>
> - LSM_HOOK_INIT(move_mount, apparmor_move_mount),
This should be in patch 3/7 when you convert AppArmor over to the new
hooks.
> LSM_HOOK_INIT(mount_bind, apparmor_mount_bind),
> LSM_HOOK_INIT(mount_new, apparmor_mount_new),
> LSM_HOOK_INIT(mount_remount, apparmor_mount_remount),
> diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> index 4547e736e496..7377f22a165e 100644
> --- a/security/landlock/fs.c
> +++ b/security/landlock/fs.c
> @@ -1983,7 +1983,6 @@ static struct security_hook_list landlock_hooks[] __ro_after_init = {
> LSM_HOOK_INIT(mount_reconfigure, hook_mount_reconfigure),
> LSM_HOOK_INIT(mount_change_type, hook_mount_change_type),
> LSM_HOOK_INIT(mount_move, hook_move_mount),
> - LSM_HOOK_INIT(move_mount, hook_move_mount),
This should be in patch 5/7 when you convert Landlock.
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 864a3ca772c9..c8de175bde04 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -7586,8 +7586,6 @@ static struct security_hook_list selinux_hooks[] __ro_after_init = {
> LSM_HOOK_INIT(sb_set_mnt_opts, selinux_set_mnt_opts),
> LSM_HOOK_INIT(sb_clone_mnt_opts, selinux_sb_clone_mnt_opts),
>
> - LSM_HOOK_INIT(move_mount, selinux_move_mount),
This should be in patch 4/7 when you convert SELinux.
> LSM_HOOK_INIT(dentry_init_security, selinux_dentry_init_security),
> LSM_HOOK_INIT(dentry_create_files_as, selinux_dentry_create_files_as),
>
> --
> 2.53.0-Meta
--
paul-moore.com
^ permalink raw reply
* Re: [BUG] lsm= with bpf before selinux breaks fscreate with EINVAL
From: Paul Moore @ 2026-05-11 20:19 UTC (permalink / raw)
To: Vitaly Chikunov
Cc: linux-security-module, bpf, selinux, KP Singh, Matt Bobrowski,
Stephen Smalley, Ondrej Mosnacek, linux-kernel
In-Reply-To: <agDuCdGIeM-6z-j-@altlinux.org>
On Sun, May 10, 2026 at 5:17 PM Vitaly Chikunov <vt@altlinux.org> wrote:
>
> Hi,
>
> We have boot failure when CONFIG_LSM has "bpf" listed before "selinux"
> (without bpf lsm scripts loaded). (This also happens with a boot with
> "security=selinux" if selinux was not in LSM= list but bpf is.)
>
> systemd reports on the failing boot attempt:
>
> Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/shm: Invalid argument
> Mounting tmpfs to /dev/shm of type tmpfs with options mode=01777.
> Mounting tmpfs (tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777")...
> Failed to mount tmpfs (type tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777"): No such file or directory
> Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/pts: Invalid argument
> Mounting devpts to /dev/pts of type devpts with options mode=0620,gid=5.
> Mounting devpts (devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5")...
> Failed to mount devpts (type devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5"): No such file or directory
> No filesystem is currently mounted on /sys/fs/cgroup.
> Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/cgroup: Invalid argument
> Mounting cgroup2 to /sys/fs/cgroup of type cgroup2 with options nsdelegate,memory_recursiveprot.
> Mounting cgroup2 (cgroup2) on /sys/fs/cgroup (MS_NOSUID|MS_NODEV|MS_NOEXEC "nsdelegate,memory_recursiveprot")...
> Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/pstore: Invalid argument
> Mounting pstore to /sys/fs/pstore of type pstore with options n/a.
> Mounting pstore (pstore) on /sys/fs/pstore (MS_NOSUID|MS_NODEV|MS_NOEXEC "")...
> Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/bpf: Invalid argument
> Mounting bpf to /sys/fs/bpf of type bpf with options mode=0700.
> Mounting bpf (bpf) on /sys/fs/bpf (MS_NOSUID|MS_NODEV|MS_NOEXEC "mode=0700")...
> [!!!!!!] Failed to mount API filesystems.
> Freezing execution
>
> 'Invalid arguments' seems from setfscreatecon_raw.
>
> Reproducer:
>
> Boot with lsm=lockdown,capability,landlock,yama,safesetid,bpf,selinux,ima,evm
>
> (none):~# cat /proc/thread-self/attr/current
> cat: /proc/thread-self/attr/current: Invalid argument
> (none):~# echo > /proc/thread-self/attr/fscreate
> bash: echo: write error: Invalid argument
>
> This appears to be caused by security_getprocattr / security_setprocattr
> iterating until the first hook defined (which is bpf) and returning with
> default value -EINVAL before selinux even sees them.
Thanks for the problem report, the general recommendation is to place
the BPF LSM towards the end of the list (see the CONFIG_LSM Kconfig
help text), but we're trying to ensure that the BPF LSM works properly
when placed anywhere in that list.
My apologies if you're abilities are well beyond this, but if you are
familiar with patching and building your own kernel, have you tried
changing the LSM_RET_DEFAULT value for those functions to zero/0?
Assuming userspace is happy with that, I believe it may solve this
problem.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 1/3] cgroup/cpuset: Fix deadline bandwidth leak in cpuset_can_attach()
From: Aaron Tomlin @ 2026-05-11 20:25 UTC (permalink / raw)
To: Waiman Long
Cc: tsbogend, paul, jmorris, serge, mingo, peterz, juri.lelli,
vincent.guittot, stephen.smalley.work, casey, tj, hannes, mkoutny,
chenridong, dietmar.eggemann, rostedt, bsegall, mgorman, vschneid,
kprateek.nayak, omosnace, kees, neelx, sean, chjohnst, steve,
mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <354af9fc-1c70-4ee4-a0ff-8821bebec7b8@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]
On Mon, May 11, 2026 at 01:54:37PM -0400, Waiman Long wrote:
> > Hi Waiman,
> >
> > Thank you for the follow up.
> >
> > Acknowledged. I will drop this patch in the next iteration due to [1].
> >
> > Please note, the sashiko AI Review bot reported: cpuset_can_attach()
> > incorrectly assumes all migrating tasks originate from the same source
> > cpuset. At first glance, this feedback is valid. I plan to submit a patch,
> > if no solution was already proposed.
> >
> > [1]: https://lore.kernel.org/lkml/20260509102031.97608-2-zhangguopeng@kylinos.cn/
>
> Yes, it does look like the AI feedback is valid. I will take a further look
> into this.
>
> Thanks,
> Longman
No worries, I have it. I'll submit a patch for review shortly.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] security: Expand task_setscheduler LSM hook to include CPU affinity mask
From: Paul Moore @ 2026-05-11 20:28 UTC (permalink / raw)
To: Aaron Tomlin
Cc: tsbogend, jmorris, serge, mingo, peterz, juri.lelli,
vincent.guittot, stephen.smalley.work, casey, longman, tj, hannes,
mkoutny, chenridong, dietmar.eggemann, rostedt, bsegall, mgorman,
vschneid, kprateek.nayak, omosnace, kees, neelx, sean, chjohnst,
steve, mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <20260509213803.968464-4-atomlin@atomlin.com>
On Sat, May 9, 2026 at 5:38 PM Aaron Tomlin <atomlin@atomlin.com> wrote:
>
> At present, the task_setscheduler LSM hook provides security modules
> with the opportunity to mediate changes to a task's scheduling policy.
> However, when invoked via sched_setaffinity(), the hook lacks
> visibility into the actual CPU affinity mask being requested.
> Consequently, BPF-based security modules are entirely blind to the
> target CPUs and cannot make granular access control decisions based on
> spatial isolation.
>
> In modern multi-tenant and real-time environments, CPU isolation is a
> critical boundary. The inability to audit or restrict specific CPU
> pinning requests limits the effectiveness of eBPF-driven security
> policies, particularly when attempting to shield isolated or
> cryptographic cores from unprivileged or compromised tasks.
>
> This patch expands the security_task_setscheduler() hook signature to
> include a pointer to the requested cpumask. Because this is a shared
> hook used for multiple scheduling attribute changes, call sites that do
> not modify CPU affinity are updated to safely pass NULL.
> To protect against unverified dereferences, the parameter is annotated
> with __nullable in the LSM hook definition, ensuring the BPF verifier
> mandates explicit NULL checks for attached eBPF programs.
>
> This change updates all in-tree security modules (SELinux and Smack) to
> accommodate the new parameter mechanically, whilst providing BPF LSMs
> with the necessary context to enforce strict affinity policies.
>
> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
> ---
> arch/mips/kernel/mips-mt-fpaff.c | 30 +++++++++++++++++-------------
> fs/proc/base.c | 2 +-
> include/linux/lsm_hook_defs.h | 3 ++-
> include/linux/security.h | 11 +++++++----
> kernel/cgroup/cpuset.c | 4 ++--
> kernel/sched/syscalls.c | 4 ++--
> security/commoncap.c | 7 +++++--
> security/security.c | 11 ++++++-----
> security/selinux/hooks.c | 3 ++-
> security/smack/smack_lsm.c | 11 +++++++++--
> 10 files changed, 53 insertions(+), 33 deletions(-)
I haven't looked too closely at this patch yet, but based on a quick
glance, can you help me understand why it is included with the other
two patches in one patchset? The other two patches look like stable
level kernel bug fixes, while this patch introduces functionality to
an existing LSM hook; one of these is not like the others :)
Unless there is something critical that I'm missing here, I would
suggest splitting this patch out from the other two bugfixes for
separate handling. If there is a patch dependency issue you can
always mention that in the cover letter.
--
paul-moore.com
^ permalink raw reply
* Re: [BUG] lsm= with bpf before selinux breaks fscreate with EINVAL
From: Vitaly Chikunov @ 2026-05-11 21:03 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, bpf, selinux, KP Singh, Matt Bobrowski,
Stephen Smalley, Ondrej Mosnacek, linux-kernel
In-Reply-To: <CAHC9VhQ4VyAvG-z2h2NFpPx9PcJP4Ot2Ap=MPbCRk2TosJWOTA@mail.gmail.com>
Paul,
On Mon, May 11, 2026 at 04:19:34PM -0400, Paul Moore wrote:
> On Sun, May 10, 2026 at 5:17 PM Vitaly Chikunov <vt@altlinux.org> wrote:
> >
> > Hi,
> >
> > We have boot failure when CONFIG_LSM has "bpf" listed before "selinux"
> > (without bpf lsm scripts loaded). (This also happens with a boot with
> > "security=selinux" if selinux was not in LSM= list but bpf is.)
> >
> > systemd reports on the failing boot attempt:
> >
> > Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/shm: Invalid argument
> > Mounting tmpfs to /dev/shm of type tmpfs with options mode=01777.
> > Mounting tmpfs (tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777")...
> > Failed to mount tmpfs (type tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777"): No such file or directory
> > Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/pts: Invalid argument
> > Mounting devpts to /dev/pts of type devpts with options mode=0620,gid=5.
> > Mounting devpts (devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5")...
> > Failed to mount devpts (type devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5"): No such file or directory
> > No filesystem is currently mounted on /sys/fs/cgroup.
> > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/cgroup: Invalid argument
> > Mounting cgroup2 to /sys/fs/cgroup of type cgroup2 with options nsdelegate,memory_recursiveprot.
> > Mounting cgroup2 (cgroup2) on /sys/fs/cgroup (MS_NOSUID|MS_NODEV|MS_NOEXEC "nsdelegate,memory_recursiveprot")...
> > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/pstore: Invalid argument
> > Mounting pstore to /sys/fs/pstore of type pstore with options n/a.
> > Mounting pstore (pstore) on /sys/fs/pstore (MS_NOSUID|MS_NODEV|MS_NOEXEC "")...
> > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/bpf: Invalid argument
> > Mounting bpf to /sys/fs/bpf of type bpf with options mode=0700.
> > Mounting bpf (bpf) on /sys/fs/bpf (MS_NOSUID|MS_NODEV|MS_NOEXEC "mode=0700")...
> > [!!!!!!] Failed to mount API filesystems.
> > Freezing execution
> >
> > 'Invalid arguments' seems from setfscreatecon_raw.
> >
> > Reproducer:
> >
> > Boot with lsm=lockdown,capability,landlock,yama,safesetid,bpf,selinux,ima,evm
> >
> > (none):~# cat /proc/thread-self/attr/current
> > cat: /proc/thread-self/attr/current: Invalid argument
> > (none):~# echo > /proc/thread-self/attr/fscreate
> > bash: echo: write error: Invalid argument
> >
> > This appears to be caused by security_getprocattr / security_setprocattr
> > iterating until the first hook defined (which is bpf) and returning with
> > default value -EINVAL before selinux even sees them.
>
> Thanks for the problem report, the general recommendation is to place
> the BPF LSM towards the end of the list (see the CONFIG_LSM Kconfig
> help text), but we're trying to ensure that the BPF LSM works properly
> when placed anywhere in that list.
I think if the order is important it should be handled in the code like
for capabilities and ima/evm LSMs, not by forcing the user to discover
the correct order with trial and error.
>
> My apologies if you're abilities are well beyond this, but if you are
> familiar with patching and building your own kernel, have you tried
> changing the LSM_RET_DEFAULT value for those functions to zero/0?
> Assuming userspace is happy with that, I believe it may solve this
> problem.
I can patch and test if this is useful to find the correct solution, but
the description is a bit vague. Did you mean
include/linux/lsm_hook_defs.h:301:LSM_HOOK(int, -EINVAL, getprocattr, struct task_struct *p, const char *name,
include/linux/lsm_hook_defs.h:303:LSM_HOOK(int, -EINVAL, setprocattr, const char *name, void *value, size_t size)
In these lines to replace -EINVAL with 0?
I would never try this on my own, because it looks like -EINVAL is a
meaningful value, and I would never claim to understand all the
intricacies of LSMs.
3892 int security_setprocattr(int lsmid, const char *name, void *value, size_t size)
3893 {
3894 struct lsm_static_call *scall;
3895
3896 lsm_for_each_hook(scall, setprocattr) {
3897 if (lsmid != 0 && lsmid != scall->hl->lsmid->id)
3898 continue;
3899 return scall->hl->hook.setprocattr(name, value, size);
3900 }
3901 return LSM_RET_DEFAULT(setprocattr);
3902 }
If my first hypothesis is correct, and the lsm_for_each_hook goes into
bpf before selinux, setting the default to 0 will make selinux hook
unreachable.
With all this, I conclude that I perhaps misunderstood your request.
Thanks,
>
> --
> paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 7/7] lsm: Remove security_sb_mount and security_move_mount
From: Song Liu @ 2026-05-11 21:06 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, linux-fsdevel, selinux, apparmor, jmorris,
serge, viro, brauner, jack, john.johansen, stephen.smalley.work,
omosnace, mic, gnoack, takedakn, penguin-kernel, herton,
kernel-team
In-Reply-To: <37ceb04c4c37370a2359f73a24b9c07b@paul-moore.com>
On Mon, May 11, 2026 at 12:53 PM Paul Moore <paul@paul-moore.com> wrote:
[...]
> >
> > - LSM_HOOK_INIT(move_mount, selinux_move_mount),
>
> This should be in patch 4/7 when you convert SELinux.
Good points. I applied these changes to my local v4. I will wait a bit
longer before sending v4, though.
Thanks,
Song
> > LSM_HOOK_INIT(dentry_init_security, selinux_dentry_init_security),
> > LSM_HOOK_INIT(dentry_create_files_as, selinux_dentry_create_files_as),
> >
> > --
> > 2.53.0-Meta
>
> --
> paul-moore.com
^ permalink raw reply
* Re: [BUG] lsm= with bpf before selinux breaks fscreate with EINVAL
From: Paul Moore @ 2026-05-11 21:49 UTC (permalink / raw)
To: Vitaly Chikunov
Cc: linux-security-module, bpf, selinux, KP Singh, Matt Bobrowski,
Stephen Smalley, Ondrej Mosnacek, linux-kernel
In-Reply-To: <agI9Rdi-72f8dNbB@altlinux.org>
On Mon, May 11, 2026 at 5:03 PM Vitaly Chikunov <vt@altlinux.org> wrote:
> On Mon, May 11, 2026 at 04:19:34PM -0400, Paul Moore wrote:
> > On Sun, May 10, 2026 at 5:17 PM Vitaly Chikunov <vt@altlinux.org> wrote:
> > >
> > > Hi,
> > >
> > > We have boot failure when CONFIG_LSM has "bpf" listed before "selinux"
> > > (without bpf lsm scripts loaded). (This also happens with a boot with
> > > "security=selinux" if selinux was not in LSM= list but bpf is.)
> > >
> > > systemd reports on the failing boot attempt:
> > >
> > > Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/shm: Invalid argument
> > > Mounting tmpfs to /dev/shm of type tmpfs with options mode=01777.
> > > Mounting tmpfs (tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777")...
> > > Failed to mount tmpfs (type tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777"): No such file or directory
> > > Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/pts: Invalid argument
> > > Mounting devpts to /dev/pts of type devpts with options mode=0620,gid=5.
> > > Mounting devpts (devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5")...
> > > Failed to mount devpts (type devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5"): No such file or directory
> > > No filesystem is currently mounted on /sys/fs/cgroup.
> > > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/cgroup: Invalid argument
> > > Mounting cgroup2 to /sys/fs/cgroup of type cgroup2 with options nsdelegate,memory_recursiveprot.
> > > Mounting cgroup2 (cgroup2) on /sys/fs/cgroup (MS_NOSUID|MS_NODEV|MS_NOEXEC "nsdelegate,memory_recursiveprot")...
> > > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/pstore: Invalid argument
> > > Mounting pstore to /sys/fs/pstore of type pstore with options n/a.
> > > Mounting pstore (pstore) on /sys/fs/pstore (MS_NOSUID|MS_NODEV|MS_NOEXEC "")...
> > > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/bpf: Invalid argument
> > > Mounting bpf to /sys/fs/bpf of type bpf with options mode=0700.
> > > Mounting bpf (bpf) on /sys/fs/bpf (MS_NOSUID|MS_NODEV|MS_NOEXEC "mode=0700")...
> > > [!!!!!!] Failed to mount API filesystems.
> > > Freezing execution
> > >
> > > 'Invalid arguments' seems from setfscreatecon_raw.
> > >
> > > Reproducer:
> > >
> > > Boot with lsm=lockdown,capability,landlock,yama,safesetid,bpf,selinux,ima,evm
> > >
> > > (none):~# cat /proc/thread-self/attr/current
> > > cat: /proc/thread-self/attr/current: Invalid argument
> > > (none):~# echo > /proc/thread-self/attr/fscreate
> > > bash: echo: write error: Invalid argument
> > >
> > > This appears to be caused by security_getprocattr / security_setprocattr
> > > iterating until the first hook defined (which is bpf) and returning with
> > > default value -EINVAL before selinux even sees them.
> >
> > Thanks for the problem report, the general recommendation is to place
> > the BPF LSM towards the end of the list (see the CONFIG_LSM Kconfig
> > help text), but we're trying to ensure that the BPF LSM works properly
> > when placed anywhere in that list.
>
> I think if the order is important it should be handled in the code like
> for capabilities and ima/evm LSMs, not by forcing the user to discover
> the correct order with trial and error.
Patches are always welcome, although as I mentioned to you previously
we are working towards supporting arbitrary ordering for BPF LSMs.
> > My apologies if you're abilities are well beyond this, but if you are
> > familiar with patching and building your own kernel, have you tried
> > changing the LSM_RET_DEFAULT value for those functions to zero/0?
> > Assuming userspace is happy with that, I believe it may solve this
> > problem.
>
> I can patch and test if this is useful to find the correct solution, but
> the description is a bit vague. Did you mean
>
> include/linux/lsm_hook_defs.h:301:LSM_HOOK(int, -EINVAL, getprocattr, struct task_struct *p, const char *name,
> include/linux/lsm_hook_defs.h:303:LSM_HOOK(int, -EINVAL, setprocattr, const char *name, void *value, size_t size)
>
> In these lines to replace -EINVAL with 0?
The patch below is what I had in mind (although be warned that was
just a cut-n-paste into this email so it is likely whitespace
damaged). If you are able to give that a test it would be great, if
not, I can throw it on the todo pile.
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 2b8dfb35caed..12724e259900 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -298,9 +298,9 @@ LSM_HOOK(int, -EOPNOTSUPP, getselfattr, unsigned int attr,
struct lsm_ctx __user *ctx, u32 *size, u32 flags)
LSM_HOOK(int, -EOPNOTSUPP, setselfattr, unsigned int attr,
struct lsm_ctx *ctx, u32 size, u32 flags)
-LSM_HOOK(int, -EINVAL, getprocattr, struct task_struct *p, const char *name,
+LSM_HOOK(int, 0, getprocattr, struct task_struct *p, const char *name,
char **value)
-LSM_HOOK(int, -EINVAL, setprocattr, const char *name, void *value, size_t size)
+LSM_HOOK(int, 0, setprocattr, const char *name, void *value, size_t size)
LSM_HOOK(int, 0, ismaclabel, const char *name)
LSM_HOOK(int, -EOPNOTSUPP, secid_to_secctx, u32 secid, struct lsm_context *cp)
LSM_HOOK(int, -EOPNOTSUPP, lsmprop_to_secctx, struct lsm_prop *prop,
--
paul-moore.com
^ permalink raw reply related
* Re: [BUG] lsm= with bpf before selinux breaks fscreate with EINVAL
From: Vitaly Chikunov @ 2026-05-11 21:54 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, bpf, selinux, KP Singh, Matt Bobrowski,
Stephen Smalley, Ondrej Mosnacek, linux-kernel
In-Reply-To: <CAHC9VhRWNEzYx3Xxtxv_0BBkM7skisVdnKXx3CGn3S=aoBCiyQ@mail.gmail.com>
Paul,
On Mon, May 11, 2026 at 05:49:39PM -0400, Paul Moore wrote:
> On Mon, May 11, 2026 at 5:03 PM Vitaly Chikunov <vt@altlinux.org> wrote:
> > On Mon, May 11, 2026 at 04:19:34PM -0400, Paul Moore wrote:
> > > On Sun, May 10, 2026 at 5:17 PM Vitaly Chikunov <vt@altlinux.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > We have boot failure when CONFIG_LSM has "bpf" listed before "selinux"
> > > > (without bpf lsm scripts loaded). (This also happens with a boot with
> > > > "security=selinux" if selinux was not in LSM= list but bpf is.)
> > > >
> > > > systemd reports on the failing boot attempt:
> > > >
> > > > Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/shm: Invalid argument
> > > > Mounting tmpfs to /dev/shm of type tmpfs with options mode=01777.
> > > > Mounting tmpfs (tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777")...
> > > > Failed to mount tmpfs (type tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777"): No such file or directory
> > > > Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/pts: Invalid argument
> > > > Mounting devpts to /dev/pts of type devpts with options mode=0620,gid=5.
> > > > Mounting devpts (devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5")...
> > > > Failed to mount devpts (type devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5"): No such file or directory
> > > > No filesystem is currently mounted on /sys/fs/cgroup.
> > > > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/cgroup: Invalid argument
> > > > Mounting cgroup2 to /sys/fs/cgroup of type cgroup2 with options nsdelegate,memory_recursiveprot.
> > > > Mounting cgroup2 (cgroup2) on /sys/fs/cgroup (MS_NOSUID|MS_NODEV|MS_NOEXEC "nsdelegate,memory_recursiveprot")...
> > > > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/pstore: Invalid argument
> > > > Mounting pstore to /sys/fs/pstore of type pstore with options n/a.
> > > > Mounting pstore (pstore) on /sys/fs/pstore (MS_NOSUID|MS_NODEV|MS_NOEXEC "")...
> > > > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/bpf: Invalid argument
> > > > Mounting bpf to /sys/fs/bpf of type bpf with options mode=0700.
> > > > Mounting bpf (bpf) on /sys/fs/bpf (MS_NOSUID|MS_NODEV|MS_NOEXEC "mode=0700")...
> > > > [!!!!!!] Failed to mount API filesystems.
> > > > Freezing execution
> > > >
> > > > 'Invalid arguments' seems from setfscreatecon_raw.
> > > >
> > > > Reproducer:
> > > >
> > > > Boot with lsm=lockdown,capability,landlock,yama,safesetid,bpf,selinux,ima,evm
> > > >
> > > > (none):~# cat /proc/thread-self/attr/current
> > > > cat: /proc/thread-self/attr/current: Invalid argument
> > > > (none):~# echo > /proc/thread-self/attr/fscreate
> > > > bash: echo: write error: Invalid argument
> > > >
> > > > This appears to be caused by security_getprocattr / security_setprocattr
> > > > iterating until the first hook defined (which is bpf) and returning with
> > > > default value -EINVAL before selinux even sees them.
> > >
> > > Thanks for the problem report, the general recommendation is to place
> > > the BPF LSM towards the end of the list (see the CONFIG_LSM Kconfig
> > > help text), but we're trying to ensure that the BPF LSM works properly
> > > when placed anywhere in that list.
> >
> > I think if the order is important it should be handled in the code like
> > for capabilities and ima/evm LSMs, not by forcing the user to discover
> > the correct order with trial and error.
>
> Patches are always welcome, although as I mentioned to you previously
> we are working towards supporting arbitrary ordering for BPF LSMs.
>
> > > My apologies if you're abilities are well beyond this, but if you are
> > > familiar with patching and building your own kernel, have you tried
> > > changing the LSM_RET_DEFAULT value for those functions to zero/0?
> > > Assuming userspace is happy with that, I believe it may solve this
> > > problem.
> >
> > I can patch and test if this is useful to find the correct solution, but
> > the description is a bit vague. Did you mean
> >
> > include/linux/lsm_hook_defs.h:301:LSM_HOOK(int, -EINVAL, getprocattr, struct task_struct *p, const char *name,
> > include/linux/lsm_hook_defs.h:303:LSM_HOOK(int, -EINVAL, setprocattr, const char *name, void *value, size_t size)
> >
> > In these lines to replace -EINVAL with 0?
>
> The patch below is what I had in mind (although be warned that was
> just a cut-n-paste into this email so it is likely whitespace
> damaged). If you are able to give that a test it would be great, if
> not, I can throw it on the todo pile.
>
> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> index 2b8dfb35caed..12724e259900 100644
> --- a/include/linux/lsm_hook_defs.h
> +++ b/include/linux/lsm_hook_defs.h
> @@ -298,9 +298,9 @@ LSM_HOOK(int, -EOPNOTSUPP, getselfattr, unsigned int attr,
> struct lsm_ctx __user *ctx, u32 *size, u32 flags)
> LSM_HOOK(int, -EOPNOTSUPP, setselfattr, unsigned int attr,
> struct lsm_ctx *ctx, u32 size, u32 flags)
> -LSM_HOOK(int, -EINVAL, getprocattr, struct task_struct *p, const char *name,
> +LSM_HOOK(int, 0, getprocattr, struct task_struct *p, const char *name,
> char **value)
> -LSM_HOOK(int, -EINVAL, setprocattr, const char *name, void *value, size_t size)
> +LSM_HOOK(int, 0, setprocattr, const char *name, void *value, size_t size)
> LSM_HOOK(int, 0, ismaclabel, const char *name)
> LSM_HOOK(int, -EOPNOTSUPP, secid_to_secctx, u32 secid, struct lsm_context *cp)
> LSM_HOOK(int, -EOPNOTSUPP, lsmprop_to_secctx, struct lsm_prop *prop,
We will test it and report, but this may take some time.
Thanks,
>
> --
> paul-moore.com
^ permalink raw reply
* Re: [BUG] lsm= with bpf before selinux breaks fscreate with EINVAL
From: Vitaly Chikunov @ 2026-05-11 22:43 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, bpf, selinux, KP Singh, Matt Bobrowski,
Stephen Smalley, Ondrej Mosnacek, linux-kernel
In-Reply-To: <agJPqiSKvHrrg6Qn@altlinux.org>
Paul,
On Tue, May 12, 2026 at 12:54:21AM +0300, Vitaly Chikunov wrote:
> On Mon, May 11, 2026 at 05:49:39PM -0400, Paul Moore wrote:
> > On Mon, May 11, 2026 at 5:03 PM Vitaly Chikunov <vt@altlinux.org> wrote:
> > > On Mon, May 11, 2026 at 04:19:34PM -0400, Paul Moore wrote:
> > > > On Sun, May 10, 2026 at 5:17 PM Vitaly Chikunov <vt@altlinux.org> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > We have boot failure when CONFIG_LSM has "bpf" listed before "selinux"
> > > > > (without bpf lsm scripts loaded). (This also happens with a boot with
> > > > > "security=selinux" if selinux was not in LSM= list but bpf is.)
> > > > >
> > > > > systemd reports on the failing boot attempt:
> > > > >
> > > > > Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/shm: Invalid argument
> > > > > Mounting tmpfs to /dev/shm of type tmpfs with options mode=01777.
> > > > > Mounting tmpfs (tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777")...
> > > > > Failed to mount tmpfs (type tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV|MS_STRICTATIME "mode=01777"): No such file or directory
> > > > > Failed to set SELinux security context generic_u:object_r:device:s0 for /dev/pts: Invalid argument
> > > > > Mounting devpts to /dev/pts of type devpts with options mode=0620,gid=5.
> > > > > Mounting devpts (devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5")...
> > > > > Failed to mount devpts (type devpts) on /dev/pts (MS_NOSUID|MS_NOEXEC "mode=0620,gid=5"): No such file or directory
> > > > > No filesystem is currently mounted on /sys/fs/cgroup.
> > > > > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/cgroup: Invalid argument
> > > > > Mounting cgroup2 to /sys/fs/cgroup of type cgroup2 with options nsdelegate,memory_recursiveprot.
> > > > > Mounting cgroup2 (cgroup2) on /sys/fs/cgroup (MS_NOSUID|MS_NODEV|MS_NOEXEC "nsdelegate,memory_recursiveprot")...
> > > > > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/pstore: Invalid argument
> > > > > Mounting pstore to /sys/fs/pstore of type pstore with options n/a.
> > > > > Mounting pstore (pstore) on /sys/fs/pstore (MS_NOSUID|MS_NODEV|MS_NOEXEC "")...
> > > > > Failed to set SELinux security context generic_u:object_r:def_t:s0 for /sys/fs/bpf: Invalid argument
> > > > > Mounting bpf to /sys/fs/bpf of type bpf with options mode=0700.
> > > > > Mounting bpf (bpf) on /sys/fs/bpf (MS_NOSUID|MS_NODEV|MS_NOEXEC "mode=0700")...
> > > > > [!!!!!!] Failed to mount API filesystems.
> > > > > Freezing execution
> > > > >
> > > > > 'Invalid arguments' seems from setfscreatecon_raw.
> > > > >
> > > > > Reproducer:
> > > > >
> > > > > Boot with lsm=lockdown,capability,landlock,yama,safesetid,bpf,selinux,ima,evm
> > > > >
> > > > > (none):~# cat /proc/thread-self/attr/current
> > > > > cat: /proc/thread-self/attr/current: Invalid argument
> > > > > (none):~# echo > /proc/thread-self/attr/fscreate
> > > > > bash: echo: write error: Invalid argument
> > > > >
> > > > > This appears to be caused by security_getprocattr / security_setprocattr
> > > > > iterating until the first hook defined (which is bpf) and returning with
> > > > > default value -EINVAL before selinux even sees them.
> > > >
> > > > Thanks for the problem report, the general recommendation is to place
> > > > the BPF LSM towards the end of the list (see the CONFIG_LSM Kconfig
> > > > help text), but we're trying to ensure that the BPF LSM works properly
> > > > when placed anywhere in that list.
> > >
> > > I think if the order is important it should be handled in the code like
> > > for capabilities and ima/evm LSMs, not by forcing the user to discover
> > > the correct order with trial and error.
> >
> > Patches are always welcome, although as I mentioned to you previously
> > we are working towards supporting arbitrary ordering for BPF LSMs.
> >
> > > > My apologies if you're abilities are well beyond this, but if you are
> > > > familiar with patching and building your own kernel, have you tried
> > > > changing the LSM_RET_DEFAULT value for those functions to zero/0?
> > > > Assuming userspace is happy with that, I believe it may solve this
> > > > problem.
> > >
> > > I can patch and test if this is useful to find the correct solution, but
> > > the description is a bit vague. Did you mean
> > >
> > > include/linux/lsm_hook_defs.h:301:LSM_HOOK(int, -EINVAL, getprocattr, struct task_struct *p, const char *name,
> > > include/linux/lsm_hook_defs.h:303:LSM_HOOK(int, -EINVAL, setprocattr, const char *name, void *value, size_t size)
> > >
> > > In these lines to replace -EINVAL with 0?
> >
> > The patch below is what I had in mind (although be warned that was
> > just a cut-n-paste into this email so it is likely whitespace
> > damaged). If you are able to give that a test it would be great, if
> > not, I can throw it on the todo pile.
> >
> > diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> > index 2b8dfb35caed..12724e259900 100644
> > --- a/include/linux/lsm_hook_defs.h
> > +++ b/include/linux/lsm_hook_defs.h
> > @@ -298,9 +298,9 @@ LSM_HOOK(int, -EOPNOTSUPP, getselfattr, unsigned int attr,
> > struct lsm_ctx __user *ctx, u32 *size, u32 flags)
> > LSM_HOOK(int, -EOPNOTSUPP, setselfattr, unsigned int attr,
> > struct lsm_ctx *ctx, u32 size, u32 flags)
> > -LSM_HOOK(int, -EINVAL, getprocattr, struct task_struct *p, const char *name,
> > +LSM_HOOK(int, 0, getprocattr, struct task_struct *p, const char *name,
> > char **value)
> > -LSM_HOOK(int, -EINVAL, setprocattr, const char *name, void *value, size_t size)
> > +LSM_HOOK(int, 0, setprocattr, const char *name, void *value, size_t size)
> > LSM_HOOK(int, 0, ismaclabel, const char *name)
> > LSM_HOOK(int, -EOPNOTSUPP, secid_to_secctx, u32 secid, struct lsm_context *cp)
> > LSM_HOOK(int, -EOPNOTSUPP, lsmprop_to_secctx, struct lsm_prop *prop,
>
> We will test it and report, but this may take some time.
Before trying the full system boot test, I tried to reproducer I posted
before. With this patch applied (just ensure it's correct) over v6.12.87:
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 9eca013aa5e1..b38f6194699b 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -288,9 +288,9 @@ LSM_HOOK(int, -EOPNOTSUPP, getselfattr, unsigned int attr,
struct lsm_ctx __user *ctx, u32 *size, u32 flags)
LSM_HOOK(int, -EOPNOTSUPP, setselfattr, unsigned int attr,
struct lsm_ctx *ctx, u32 size, u32 flags)
-LSM_HOOK(int, -EINVAL, getprocattr, struct task_struct *p, const char *name,
+LSM_HOOK(int, 0, getprocattr, struct task_struct *p, const char *name,
char **value)
-LSM_HOOK(int, -EINVAL, setprocattr, const char *name, void *value, size_t size)
+LSM_HOOK(int, 0, setprocattr, const char *name, void *value, size_t size)
LSM_HOOK(int, 0, ismaclabel, const char *name)
LSM_HOOK(int, -EOPNOTSUPP, secid_to_secctx, u32 secid, char **secdata,
u32 *seclen)
1. `cat /proc/thread-self/attr/current` does not report `kernel` as before.
2. `echo > /proc/thread-self/attr/fscreate` process hangs in R state, with strace
showing infinite loop of
write(1, "\n", 1) = 0
write(1, "\n", 1) = 0
write(1, "\n", 1) = 0
Thanks,
>
> Thanks,
>
> >
> > --
> > paul-moore.com
^ permalink raw reply related
* Re: [PATCH v5 00/13] ima: Introduce staging mechanism
From: Roberto Sassu @ 2026-05-12 8:17 UTC (permalink / raw)
To: Lakshmi Ramasubramanian, steven chen, corbet, skhan, zohar,
dmitry.kasatkin, eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, Roberto Sassu
In-Reply-To: <aaed52cf-26e1-4c40-812d-3788024ce5b5@linux.microsoft.com>
On Mon, 2026-05-11 at 10:29 -0700, Lakshmi Ramasubramanian wrote:
> On 5/7/2026 9:47 AM, steven chen wrote:
> > >
> > > Usage
> > > =====
> > >
> > > The IMA staging mechanism can be enabled from the kernel configuration
> > > with the CONFIG_IMA_STAGING option.
> > >
> > > If it is enabled, IMA duplicates the current measurements interfaces
> > > (both binary and ASCII), by adding the _staged file suffix. Both the
> > > original and the staging interfaces gain the write permission for the
> > > root user and group, but require the process to have CAP_SYS_ADMIN set.
> > >
> > > The staging mechanism supports two flavors.
> > >
> > > Staging with prompt
> > > ~~~~~~~~~~~~~~~~~~~
> > >
> > > The current measurements list is moved to a temporary staging area, and
> > > staged measurements are deleted upon confirmation.
> > >
> > > This staging process is achieved with the following steps.
> > >
> > > 1. echo A > <original interface>: the user requests IMA to stage the
> > > entire measurements list;
> > > 2. cat <_staged interface>: the user reads the staged measurements;
> > > 3. echo D > <_staged interface>: the user requests IMA to delete
> > > staged measurements.
> > >
> > > Staging and deleting
> > > ~~~~~~~~~~~~~~~~~~~~
> > >
> > > N measurements are staged to a temporary staging area, and immediately
> > > deleted without further confirmation.
> > >
> > > This staging process is achieved with the following steps.
> > >
> > > 1. cat <original interface>: the user reads the current measurements
> > > list and determines what the value N for staging should be;
> > > 2. echo N > <original interface>: the user requests IMA to delete N
> > > measurements from the current measurements list.
> >
> > This submission proposes two ways for log trimming:
> >
> > *Flavor 1:* Staging with prompt
> > *Flavor 2:* stage and delete N
> >
> > Functionally, both approaches address the same problem, but *Favour 2
> > *is the
> > stronger design and should be preferred. There is no good reason to keep
> > *Flavor 1.*
> >
> > From a kernel implementation perspective, *Flavor 2 *is more efficient
> > because it
> > minimizes the time spent holding the list lock (can’t be shorter). It
> > also substantially
> > reduces the amount of kernel-side logic, removing nearly half of the
> > code required
> > by the alternative approach.
> >
> > From a user-space perspective, *Flavor 2 *results in a much cleaner
> > model. It avoids
> > the need to track and reconcile both old and staged lists in user space
> > as well as
> > two lists (cur and staged) in the kernel space, which simplifies log
> > trimming logic
> > and reduces maintenance overhead. In addition, it preserves the existing
> > external
> > behavior by not exposing any staged list to user space.
> >
> > Overall, *Flavor 2 *provides the same functional result with lower
> > kernel complexity,
> > shorter kernel list lock hold time, and a simpler user-space interface.
> > For those
> > reasons, it is the preferable approach and *Favour 1* does not appear to
> > offer sufficient
> > justification to keep both implementations.
> >
> > Steven
>
> Roberto, Mimi:
>
> I want to add on to the point Steven has brought up.
>
> With "Stage and Delete N" approach, we have the following sequence of
> tasks for trimming the IMA log:
>
> 1. User mode locks the IMA measurement list through the "write interface".
> a. While this prevents any other user mode process from updating the
> IMA log, kernel can still add new IMA events to the measurement log
> 2. User mode reads the TPM Quote and the IMA measurement events and
> sends it to the remote attestation service
> 3. Once the remote service has successfully processed the IMA events,
> the user mode determines the number of IMA events "N" to be removed from
> the measurement list maintained in the kernel
> 4. User mode provides the value "N" to the kernel
> 5. Kernel now determines the point at which to snap the IMA measurement
> list using "N" - without holding a lock
> 6. Then, the kernel lock is held and the list is snapped at the point
> determined in the previous step thus keeping the kernel lock time to the
> minimum.
> 7. Now, user mode removes the "write" lock on the IMA measurement list
>
> With the above, we believe "Stage and Delete N" alone is sufficient to
> trim IMA log.
Hi Lakshmi
I'm happy to support your trimming method. Just does not fit with my
use case. I would like to keep both.
Thanks
Roberto
> -lakshmi
>
> > > .../admin-guide/kernel-parameters.txt | 4 +
> > > Documentation/security/IMA-staging.rst | 163 +++++++++
> > > Documentation/security/index.rst | 1 +
> > > MAINTAINERS | 2 +
> > > security/integrity/ima/Kconfig | 16 +
> > > security/integrity/ima/ima.h | 32 +-
> > > security/integrity/ima/ima_api.c | 2 +-
> > > security/integrity/ima/ima_fs.c | 315 ++++++++++++++++--
> > > security/integrity/ima/ima_init.c | 5 +
> > > security/integrity/ima/ima_kexec.c | 53 ++-
> > > security/integrity/ima/ima_queue.c | 283 ++++++++++++++--
> > > 11 files changed, 803 insertions(+), 73 deletions(-)
> > > create mode 100644 Documentation/security/IMA-staging.rst
> > >
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Leon Romanovsky @ 2026-05-12 8:51 UTC (permalink / raw)
To: Paul Moore
Cc: Jason Gunthorpe, Roberto Sassu, KP Singh, Matt Bobrowski,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Stanislav Fomichev, Hao Luo, Jiri Olsa, Shuah Khan,
Saeed Mahameed, Itay Avraham, Dave Jiang, Jonathan Cameron, bpf,
linux-kernel, linux-kselftest, linux-rdma, Chiara Meiohas,
Maher Sanalla, linux-security-module
In-Reply-To: <CAHC9VhTsx6cpKMP8nVgK4F=drXTFJtK3_D9k9pmKr56+ZFUu9w@mail.gmail.com>
On Mon, May 04, 2026 at 06:33:45PM -0400, Paul Moore wrote:
> On Fri, Apr 24, 2026 at 6:13 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > ... I wonder if we are even speaking the same language.
>
> Let's reset the conversation.
>
> As I understand it, based on our discussion in this thread and Leon's
> previous patchsets, the basic idea is to enable LSMs to enforce access
> control over fwctl requests/commands sent from userspace. I'm going
> to start with that as a basis.
Yes, we proposed two users: FWCTL and RDMA DevX. Both are relevant, but
FWCTL is the higher priority.
>
> Using the kernel's docs on fwctl, the userspace API appears to consist
> mostly of ioctls with some basic sysfs interfaces. It looks like we
> can mostly ignore the sysfs interface and focus on the ioctl side of
> the API, do you agree?
Yes, all FW commands are routed through ioctls.
>
> https://docs.kernel.org/userspace-api/fwctl/fwctl.html
>
> While normally I would suggest simply using the existing
> security_file_ioctl() hook, Leon previously mentioned that the hook is
> too early for fwctl as the userspace copy happens much later.
I talked about general verbs interface in RDMA.
Thanks
^ permalink raw reply
* [PATCH RFC 0/5] memcg: dma-buf per-cgroup accounting via pid_fd
From: Albert Esteve @ 2026-05-12 9:10 UTC (permalink / raw)
To: Tejun Heo, Johannes Weiner, Michal Koutný, Jonathan Corbet,
Shuah Khan, Sumit Semwal, Christian König, Michal Hocko,
Roman Gushchin, Shakeel Butt, Muchun Song, Andrew Morton,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian Brauner, Paul Moore, James Morris, Serge E. Hallyn,
Stephen Smalley, Ondrej Mosnacek, Shuah Khan
Cc: cgroups, linux-doc, linux-kernel, linux-media, dri-devel,
linaro-mm-sig, linux-mm, linux-security-module, selinux,
linux-kselftest, Albert Esteve, mripard, echanude
This RFC builds on T.J. Mercier's earlier series [1] which added
a memory.stat counter for exported dma-bufs and a binder-backed
mechanism to transfer charges between cgroups.
The first commit is taken almost verbatim from TJ's series:
it introduces MEMCG_DMABUF as a dedicated per-cgroup stat, so that
the total exported dma-buf footprint is visible both system-wide
(via the root cgroup) and per-application (via per-process cgroups).
This avoids the overhead of DMABUF_SYSFS_STATS and integrates
naturally into the existing cgroup memory hierarchy.
The rest of the series departs from TJ's approach. While the first
commit introduces the memcg stat infrastructure for dmabufs, the
export-time charging it introduces in dma_buf_export() is then
superseded: we charge at dma_heap_ioctl_allocate() time, using a
new charge_pid_fd field in struct dma_heap_allocation_data. The
allocator opens a pidfd for its client (e.g., from binder's
sender_pid), passes it to the ioctl, and the kernel charges the
buffer directly to the client's cgroup at allocation time, so no
transfer step is needed.
This decouples the accounting path from binder entirely:
any allocator that knows its client's PID can use the pid_fd
mechanism regardless of the IPC transport in use.
The cross-cgroup charging capability requires access control.
Patches #3 and #4 add a generic LSM hook (security_dma_heap_alloc)
and an SELinux implementation based on a new dma_heap object class
with a charge_to permission, so policy authors can express which
domains are allowed to charge memory to another domain's cgroup.
Last patch adds some tests to verify the new charge_pid_fd field.
We are sending it as an RFC to spark broader discussion. It may or
may not be the right path forward, and we welcome feedback on the
trade-offs.
Collision note: Eric Chanudet's series [2] adds __GFP_ACCOUNT to
system_heap page allocations as an opt-in module parameter. That
approach charges pages to the allocator's own kmem, which overlaps with
MEMCG_DMABUF. This series explicitly removes __GFP_ACCOUNT from system
heap allocations and routes all accounting through the MEMCG_DMABUF
path to avoid double-counting.
[1] https://lore.kernel.org/cgroups/20230109213809.418135-1-tjmercier@google.com/
[2] https://lore.kernel.org/r/20260113-dmabuf-heap-system-memcg-v2-0-e85722cc2f24@redhat.com
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
Albert Esteve (4):
dma-heap: charge dma-buf memory via explicit memcg
security: dma-heap: Add dma_heap_alloc LSM hook
selinux: Restrict cross-cgroup dma-heap charging
selftests/dmabuf-heaps: Add dma-buf memcg accounting tests
T.J. Mercier (1):
memcg: Track exported dma-buffers
Documentation/admin-guide/cgroup-v2.rst | 5 +
drivers/dma-buf/dma-buf.c | 7 +
drivers/dma-buf/dma-heap.c | 54 +++++-
drivers/dma-buf/heaps/system_heap.c | 2 -
include/linux/dma-buf.h | 4 +
include/linux/lsm_hook_defs.h | 1 +
include/linux/memcontrol.h | 37 ++++
include/linux/security.h | 7 +
include/uapi/linux/dma-heap.h | 6 +
mm/memcontrol.c | 19 ++
security/security.c | 16 ++
security/selinux/hooks.c | 7 +
security/selinux/include/classmap.h | 1 +
tools/testing/selftests/cgroup/Makefile | 2 +-
tools/testing/selftests/cgroup/test_memcontrol.c | 143 +++++++++++++-
tools/testing/selftests/dmabuf-heaps/config | 1 +
tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 126 ++++++++++++-
tools/testing/selftests/dmabuf-heaps/vmtest.sh | 205 +++++++++++++++++++++
18 files changed, 633 insertions(+), 10 deletions(-)
---
base-commit: 74fe02ce122a6103f207d29fafc8b3a53de6abaf
change-id: 20260508-v2_20230123_tjmercier_google_com-f44fcfb16530
Best regards,
--
Albert Esteve <aesteve@redhat.com>
^ permalink raw reply
* [PATCH RFC 1/5] memcg: Track exported dma-buffers
From: Albert Esteve @ 2026-05-12 9:10 UTC (permalink / raw)
To: Tejun Heo, Johannes Weiner, Michal Koutný, Jonathan Corbet,
Shuah Khan, Sumit Semwal, Christian König, Michal Hocko,
Roman Gushchin, Shakeel Butt, Muchun Song, Andrew Morton,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian Brauner, Paul Moore, James Morris, Serge E. Hallyn,
Stephen Smalley, Ondrej Mosnacek, Shuah Khan
Cc: cgroups, linux-doc, linux-kernel, linux-media, dri-devel,
linaro-mm-sig, linux-mm, linux-security-module, selinux,
linux-kselftest, Albert Esteve, mripard, echanude
In-Reply-To: <20260512-v2_20230123_tjmercier_google_com-v1-0-6326701c3691@redhat.com>
From: "T.J. Mercier" <tjmercier@google.com>
When a buffer is exported to userspace, use memcg to attribute the
buffer to the allocating cgroup until all buffer references are
released.
Unlike the dmabuf sysfs stats implementation, this memcg accounting
avoids contention over the kernfs_rwsem incurred when creating or
removing nodes.
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
Documentation/admin-guide/cgroup-v2.rst | 4 ++++
drivers/dma-buf/dma-buf.c | 13 ++++++++++++
include/linux/dma-buf.h | 4 ++++
include/linux/memcontrol.h | 37 +++++++++++++++++++++++++++++++++
mm/memcontrol.c | 19 +++++++++++++++++
5 files changed, 77 insertions(+)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 6efd0095ed995..8bdbc2e866430 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1635,6 +1635,10 @@ The following nested keys are defined.
Amount of memory used for storing in-kernel data
structures.
+ dmabuf (npn)
+ Amount of memory used for exported DMA buffers allocated by the cgroup.
+ Stays with the allocating cgroup regardless of how the buffer is shared.
+
workingset_refault_anon
Number of refaults of previously evicted anonymous pages.
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 71f37544a5c61..ce02377f48908 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -14,6 +14,7 @@
#include <linux/fs.h>
#include <linux/slab.h>
#include <linux/dma-buf.h>
+#include <linux/memcontrol.h>
#include <linux/dma-fence.h>
#include <linux/dma-fence-unwrap.h>
#include <linux/anon_inodes.h>
@@ -180,6 +181,9 @@ static void dma_buf_release(struct dentry *dentry)
*/
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
+ mem_cgroup_uncharge_dmabuf(dmabuf->memcg, PAGE_ALIGN(dmabuf->size) / PAGE_SIZE);
+ mem_cgroup_put(dmabuf->memcg);
+
dmabuf->ops->release(dmabuf);
if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
@@ -760,6 +764,13 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
dmabuf->resv = resv;
}
+ dmabuf->memcg = get_mem_cgroup_from_mm(current->mm);
+ if (!mem_cgroup_charge_dmabuf(dmabuf->memcg, PAGE_ALIGN(dmabuf->size) / PAGE_SIZE,
+ GFP_KERNEL)) {
+ ret = -ENOMEM;
+ goto err_memcg;
+ }
+
file->private_data = dmabuf;
file->f_path.dentry->d_fsdata = dmabuf;
dmabuf->file = file;
@@ -770,6 +781,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
return dmabuf;
+err_memcg:
+ mem_cgroup_put(dmabuf->memcg);
err_file:
fput(file);
err_module:
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index d1203da56fc5f..d9f1ccb51c60e 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -27,6 +27,7 @@
struct device;
struct dma_buf;
struct dma_buf_attachment;
+struct mem_cgroup;
/**
* struct dma_buf_ops - operations possible on struct dma_buf
@@ -429,6 +430,9 @@ struct dma_buf {
__poll_t active;
} cb_in, cb_out;
+
+ /** @memcg: the cgroup to which this buffer is currently attributed */
+ struct mem_cgroup *memcg;
};
/**
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index dc3fa687759b4..10068a833ad9e 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -39,6 +39,7 @@ enum memcg_stat_item {
MEMCG_ZSWAP_B,
MEMCG_ZSWAPPED,
MEMCG_ZSWAP_INCOMP,
+ MEMCG_DMABUF,
MEMCG_NR_STAT,
};
@@ -649,6 +650,24 @@ int mem_cgroup_charge_hugetlb(struct folio* folio, gfp_t gfp);
int mem_cgroup_swapin_charge_folio(struct folio *folio, struct mm_struct *mm,
gfp_t gfp, swp_entry_t entry);
+/**
+ * mem_cgroup_charge_dmabuf - Charge dma-buf memory to a cgroup and update stat counter
+ * @memcg: memcg to charge
+ * @nr_pages: number of pages to charge
+ * @gfp_mask: reclaim mode
+ *
+ * Charges @nr_pages to @memcg. Returns %true if the charge fit within
+ * @memcg's configured limit, %false if it doesn't.
+ */
+bool __mem_cgroup_charge_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages, gfp_t gfp_mask);
+static inline bool mem_cgroup_charge_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages,
+ gfp_t gfp_mask)
+{
+ if (mem_cgroup_disabled())
+ return true;
+ return __mem_cgroup_charge_dmabuf(memcg, nr_pages, gfp_mask);
+}
+
void __mem_cgroup_uncharge(struct folio *folio);
/**
@@ -664,6 +683,14 @@ static inline void mem_cgroup_uncharge(struct folio *folio)
__mem_cgroup_uncharge(folio);
}
+void __mem_cgroup_uncharge_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages);
+static inline void mem_cgroup_uncharge_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages)
+{
+ if (mem_cgroup_disabled())
+ return;
+ __mem_cgroup_uncharge_dmabuf(memcg, nr_pages);
+}
+
void __mem_cgroup_uncharge_folios(struct folio_batch *folios);
static inline void mem_cgroup_uncharge_folios(struct folio_batch *folios)
{
@@ -1142,10 +1169,20 @@ static inline int mem_cgroup_swapin_charge_folio(struct folio *folio,
return 0;
}
+static inline bool mem_cgroup_charge_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages,
+ gfp_t gfp_mask)
+{
+ return true;
+}
+
static inline void mem_cgroup_uncharge(struct folio *folio)
{
}
+static inline void mem_cgroup_uncharge_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages)
+{
+}
+
static inline void mem_cgroup_uncharge_folios(struct folio_batch *folios)
{
}
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index c03d4787d4668..15cee13d3ccd6 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -433,6 +433,7 @@ static const unsigned int memcg_stat_items[] = {
MEMCG_ZSWAP_B,
MEMCG_ZSWAPPED,
MEMCG_ZSWAP_INCOMP,
+ MEMCG_DMABUF,
};
#define NR_MEMCG_NODE_STAT_ITEMS ARRAY_SIZE(memcg_node_stat_items)
@@ -1580,6 +1581,7 @@ static const struct memory_stat memory_stats[] = {
#ifdef CONFIG_HUGETLB_PAGE
{ "hugetlb", NR_HUGETLB },
#endif
+ { "dmabuf", MEMCG_DMABUF },
/* The memory events */
{ "workingset_refault_anon", WORKINGSET_REFAULT_ANON },
@@ -5399,6 +5401,23 @@ void mem_cgroup_flush_workqueue(void)
flush_workqueue(memcg_wq);
}
+bool __mem_cgroup_charge_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages, gfp_t gfp_mask)
+{
+ if (try_charge(memcg, gfp_mask, nr_pages) == 0) {
+ mod_memcg_state(memcg, MEMCG_DMABUF, nr_pages);
+ return true;
+ }
+
+ return false;
+}
+
+void __mem_cgroup_uncharge_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages)
+{
+ mod_memcg_state(memcg, MEMCG_DMABUF, -nr_pages);
+ if (!mem_cgroup_is_root(memcg))
+ refill_stock(memcg, nr_pages);
+}
+
static int __init cgroup_memory(char *s)
{
char *token;
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox