apparmor: global buffers spin lock may get contended

Hi,

We've notices that apparmor has switched from using per-CPU buffer pool
and per-CPU spin_lock to a global spin_lock in df323337e507a0009d3db1ea.

This seems to be causing some contention on our build machines (with
quite a bit of cores). Because that global spin lock is a part of the
stat() sys call (and perhaps some other)

E.g.

-    9.29%     0.00%  clang++          [kernel.vmlinux]                        
   - 9.28% entry_SYSCALL_64_after_hwframe                                      
      - 8.98% do_syscall_64                                                    
         - 7.43% __do_sys_newlstat                                            
            - 7.43% vfs_statx                                                  
               - 7.18% security_inode_getattr                                  
                  - 7.15% apparmor_inode_getattr                              
                     - aa_path_perm                                            
                        - 3.53% aa_get_buffer                                  
                           - 3.47% _raw_spin_lock                              
                                3.44% native_queued_spin_lock_slowpath        
                        - 3.49% aa_put_buffer.part.0                          
                           - 3.45% _raw_spin_lock                              
                                3.43% native_queued_spin_lock_slowpath   

Can we fix this contention?

On 7/13/21 6:19 AM, Sergey Senozhatsky wrote:

Hi,

We've notices that apparmor has switched from using per-CPU buffer pool
and per-CPU spin_lock to a global spin_lock in df323337e507a0009d3db1ea.

This seems to be causing some contention on our build machines (with
quite a bit of cores). Because that global spin lock is a part of the
stat() sys call (and perhaps some other)

E.g.

-    9.29%     0.00%  clang++          [kernel.vmlinux]                        
   - 9.28% entry_SYSCALL_64_after_hwframe                                      
      - 8.98% do_syscall_64                                                    
         - 7.43% __do_sys_newlstat                                            
            - 7.43% vfs_statx                                                  
               - 7.18% security_inode_getattr                                  
                  - 7.15% apparmor_inode_getattr                              
                     - aa_path_perm                                            
                        - 3.53% aa_get_buffer                                  
                           - 3.47% _raw_spin_lock                              
                                3.44% native_queued_spin_lock_slowpath        
                        - 3.49% aa_put_buffer.part.0                          
                           - 3.45% _raw_spin_lock                              
                                3.43% native_queued_spin_lock_slowpath   

Can we fix this contention?

sorry this got filtered to a wrong mailbox. Yes this is something that can
be improved, and was a concern when the switch was made from per-CPU buffers
to the global pool.

We can look into doing a hybrid approach where we can per cpu cache a buffer
from the global pool. The trick will be coming up with when the cached buffer
can be returned so we don't run into the problems that lead to
df323337e507a0009d3db1ea

On 7/13/21 06:19, Sergey Senozhatsky wrote:

Hi,

We've notices that apparmor has switched from using per-CPU buffer pool
and per-CPU spin_lock to a global spin_lock in df323337e507a0009d3db1ea.

This seems to be causing some contention on our build machines (with
quite a bit of cores). Because that global spin lock is a part of the
stat() sys call (and perhaps some other)

E.g.

-    9.29%     0.00%  clang++          [kernel.vmlinux]
    - 9.28% entry_SYSCALL_64_after_hwframe
       - 8.98% do_syscall_64
          - 7.43% __do_sys_newlstat
             - 7.43% vfs_statx
                - 7.18% security_inode_getattr
                   - 7.15% apparmor_inode_getattr
                      - aa_path_perm
                         - 3.53% aa_get_buffer
                            - 3.47% _raw_spin_lock
                                 3.44% native_queued_spin_lock_slowpath
                         - 3.49% aa_put_buffer.part.0
                            - 3.45% _raw_spin_lock
                                 3.43% native_queued_spin_lock_slowpath

Can we fix this contention?

sorry for the delay on this. Below is a proposed patch that I have been testing
to deal with this issue.


From d026988196fdbda7234fb87bc3e4aea22edcbaf9 Mon Sep 17 00:00:00 2001
From: John Johansen <john.johansen@canonical.com>
Date: Tue, 25 Oct 2022 01:18:41 -0700
Subject: [PATCH] apparmor: cache buffers on percpu list if there is lock
 contention

On a heavily loaded machine there can be lock contention on the
global buffers lock. Add a percpu list to cache buffers on when
lock contention is encountered.

When allocating buffers attempt to use cached buffers first,
before taking the global buffers lock. When freeing buffers
try to put them back to the global list but if contention is
encountered, put the buffer on the percpu list.

The length of time a buffer is held on the percpu list is dynamically
adjusted based on lock contention.  The amount of hold time is rapidly
increased and slow ramped down.

Signed-off-by: John Johansen <john.johansen@canonical.com>
---
 security/apparmor/lsm.c | 74 ++++++++++++++++++++++++++++++++++++++---
 1 file changed, 69 insertions(+), 5 deletions(-)

diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 25114735bc11..0ab70171bdb6 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c

@@ -49,12 +49,19 @@ union aa_buffer {
 	char buffer[1];
 };
 
+struct aa_local_cache {
+	unsigned int contention;
+	unsigned int hold;
+	struct list_head head;
+};
+
 #define RESERVE_COUNT 2
 static int reserve_count = RESERVE_COUNT;
 static int buffer_count;
 
 static LIST_HEAD(aa_global_buffers);
 static DEFINE_SPINLOCK(aa_buffers_lock);
+static DEFINE_PER_CPU(struct aa_local_cache, aa_local_buffers);
 
 /*
  * LSM hook functions

@@ -1622,14 +1629,44 @@ static int param_set_mode(const char *val, const struct kernel_param *kp)
 	return 0;
 }
 
+static void update_contention(struct aa_local_cache *cache)
+{
+	cache->contention += 3;
+	if (cache->contention > 9)
+		cache->contention = 9;
+	cache->hold += 1 << cache->contention;		/* 8, 64, 512 */
+}
+
 char *aa_get_buffer(bool in_atomic)
 {
 	union aa_buffer *aa_buf;
+	struct aa_local_cache *cache;
 	bool try_again = true;
 	gfp_t flags = (GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
 
+	/* use per cpu cached buffers first */
+	cache = get_cpu_ptr(&aa_local_buffers);
+	if (!list_empty(&cache->head)) {
+		aa_buf = list_first_entry(&cache->head, union aa_buffer, list);
+		list_del(&aa_buf->list);
+		cache->hold--;
+		put_cpu_ptr(&aa_local_buffers);
+		return &aa_buf->buffer[0];
+	}
+	put_cpu_ptr(&aa_local_buffers);
+
+	if (!spin_trylock(&aa_buffers_lock)) {
+		cache = get_cpu_ptr(&aa_local_buffers);
+		update_contention(cache);
+		put_cpu_ptr(&aa_local_buffers);
+		spin_lock(&aa_buffers_lock);
+	} else {
+		cache = get_cpu_ptr(&aa_local_buffers);
+		if (cache->contention)
+			cache->contention--;
+		put_cpu_ptr(&aa_local_buffers);
+	}
 retry:
-	spin_lock(&aa_buffers_lock);
 	if (buffer_count > reserve_count ||
 	    (in_atomic && !list_empty(&aa_global_buffers))) {
 		aa_buf = list_first_entry(&aa_global_buffers, union aa_buffer,

@@ -1655,6 +1692,7 @@ char *aa_get_buffer(bool in_atomic)
 	if (!aa_buf) {
 		if (try_again) {
 			try_again = false;
+			spin_lock(&aa_buffers_lock);
 			goto retry;
 		}
 		pr_warn_once("AppArmor: Failed to allocate a memory buffer.\n");

@@ -1666,15 +1704,32 @@ char *aa_get_buffer(bool in_atomic)
 void aa_put_buffer(char *buf)
 {
 	union aa_buffer *aa_buf;
+	struct aa_local_cache *cache;
 
 	if (!buf)
 		return;
 	aa_buf = container_of(buf, union aa_buffer, buffer[0]);
 
-	spin_lock(&aa_buffers_lock);
-	list_add(&aa_buf->list, &aa_global_buffers);
-	buffer_count++;
-	spin_unlock(&aa_buffers_lock);
+	cache = get_cpu_ptr(&aa_local_buffers);
+	if (!cache->hold) {
+		put_cpu_ptr(&aa_local_buffers);
+		if (spin_trylock(&aa_buffers_lock)) {
+			list_add(&aa_buf->list, &aa_global_buffers);
+			buffer_count++;
+			spin_unlock(&aa_buffers_lock);
+			cache = get_cpu_ptr(&aa_local_buffers);
+			if (cache->contention)
+				cache->contention--;
+			put_cpu_ptr(&aa_local_buffers);
+			return;
+		}
+		cache = get_cpu_ptr(&aa_local_buffers);
+		update_contention(cache);
+	}
+
+	/* cache in percpu list */
+	list_add(&aa_buf->list, &cache->head);
+	put_cpu_ptr(&aa_local_buffers);
 }
 
 /*

@@ -1716,6 +1771,15 @@ static int __init alloc_buffers(void)
 	union aa_buffer *aa_buf;
 	int i, num;
 
+	/*
+	 * per cpu set of cached allocated buffers used to help reduce
+	 * lock contention
+	 */
+	for_each_possible_cpu(i) {
+		per_cpu(aa_local_buffers, i).contention = 0;
+		per_cpu(aa_local_buffers, i).hold = 0;
+		INIT_LIST_HEAD(&per_cpu(aa_local_buffers, i).head);
+	}
 	/*
 	 * A function may require two buffers at once. Usually the buffers are
 	 * used for a short period of time and are shared. On UP kernel buffers

-- 
2.34.1

On (22/10/28 02:34), John Johansen wrote:

From d026988196fdbda7234fb87bc3e4aea22edcbaf9 Mon Sep 17 00:00:00 2001
From: John Johansen <john.johansen@canonical.com>
Date: Tue, 25 Oct 2022 01:18:41 -0700
Subject: [PATCH] apparmor: cache buffers on percpu list if there is lock
 contention

On a heavily loaded machine there can be lock contention on the
global buffers lock. Add a percpu list to cache buffers on when
lock contention is encountered.

When allocating buffers attempt to use cached buffers first,
before taking the global buffers lock. When freeing buffers
try to put them back to the global list but if contention is
encountered, put the buffer on the percpu list.

The length of time a buffer is held on the percpu list is dynamically
adjusted based on lock contention.  The amount of hold time is rapidly
increased and slow ramped down.

Signed-off-by: John Johansen <john.johansen@canonical.com>

Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org>

On 10/30/22 20:52, Sergey Senozhatsky wrote:

On (22/10/28 02:34), John Johansen wrote:

quoted

 From d026988196fdbda7234fb87bc3e4aea22edcbaf9 Mon Sep 17 00:00:00 2001
From: John Johansen <john.johansen@canonical.com>
Date: Tue, 25 Oct 2022 01:18:41 -0700
Subject: [PATCH] apparmor: cache buffers on percpu list if there is lock
  contention

On a heavily loaded machine there can be lock contention on the
global buffers lock. Add a percpu list to cache buffers on when
lock contention is encountered.

When allocating buffers attempt to use cached buffers first,
before taking the global buffers lock. When freeing buffers
try to put them back to the global list but if contention is
encountered, put the buffer on the percpu list.

The length of time a buffer is held on the percpu list is dynamically
adjusted based on lock contention.  The amount of hold time is rapidly
increased and slow ramped down.

Signed-off-by: John Johansen <john.johansen@canonical.com>

Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org>

yep, thanks for catching that

On (22/10/30 20:55), John Johansen wrote:

On 10/30/22 20:52, Sergey Senozhatsky wrote:

quoted

On (22/10/28 02:34), John Johansen wrote:

quoted

 From d026988196fdbda7234fb87bc3e4aea22edcbaf9 Mon Sep 17 00:00:00 2001
From: John Johansen <john.johansen@canonical.com>
Date: Tue, 25 Oct 2022 01:18:41 -0700
Subject: [PATCH] apparmor: cache buffers on percpu list if there is lock
  contention

On a heavily loaded machine there can be lock contention on the
global buffers lock. Add a percpu list to cache buffers on when
lock contention is encountered.

When allocating buffers attempt to use cached buffers first,
before taking the global buffers lock. When freeing buffers
try to put them back to the global list but if contention is
encountered, put the buffer on the percpu list.

The length of time a buffer is held on the percpu list is dynamically
adjusted based on lock contention.  The amount of hold time is rapidly
increased and slow ramped down.

Signed-off-by: John Johansen <john.johansen@canonical.com>

Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org>

yep, thanks for catching that

Thanks for the patch! Unfortunately it'll be a bit difficult to test
it right now; I'll probably have to wait until corp pushes new kernel
(with the patch) to build boxes.

I have sent up a new version of this patch that caps a situation where buffer lists could grow unbounded (at theoretically).

From f44dee132b0b55386b7ea31e68c80d367b073ee0 Mon Sep 17 00:00:00 2001
From: John Johansen <john.johansen@canonical.com>
Date: Tue, 25 Oct 2022 01:18:41 -0700
Subject: [PATCH] apparmor: cache buffers on percpu list if there is lock
 contention

On a heavily loaded machine there can be lock contention on the
global buffers lock. Add a percpu list to cache buffers on when
lock contention is encountered.

When allocating buffers attempt to use cached buffers first,
before taking the global buffers lock. When freeing buffers
try to put them back to the global list but if contention is
encountered, put the buffer on the percpu list.

The length of time a buffer is held on the percpu list is dynamically
adjusted based on lock contention.  The amount of hold time is rapidly
increased and slow ramped down.

v3:
- limit number of buffers that can be pushed onto the percpu
  list. This avoids a problem on some kernels where one percpu
  list can inherit buffers from another cpu after a reschedule,
  causing more kernel memory to used than is necessary. Under
  normal conditions this should eventually return to normal
  but under pathelogical conditions the extra memory consumption
  may have been unbouanded
v2:
- dynamically adjust buffer hold time on percpu list based on
  lock contention.
v1:
- cache buffers on percpu list on lock contention

Signed-off-by: John Johansen <john.johansen@canonical.com>
---
 security/apparmor/lsm.c | 81 ++++++++++++++++++++++++++++++++++++++---
 1 file changed, 76 insertions(+), 5 deletions(-)

diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 25114735bc11..21f5ea20e715 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c

@@ -49,12 +49,19 @@ union aa_buffer {
 	char buffer[1];
 };
 
+struct aa_local_cache {
+	unsigned int contention;
+	unsigned int hold;
+	struct list_head head;
+};
+
 #define RESERVE_COUNT 2
 static int reserve_count = RESERVE_COUNT;
 static int buffer_count;
 
 static LIST_HEAD(aa_global_buffers);
 static DEFINE_SPINLOCK(aa_buffers_lock);
+static DEFINE_PER_CPU(struct aa_local_cache, aa_local_buffers);
 
 /*
  * LSM hook functions

@@ -1622,14 +1629,44 @@ static int param_set_mode(const char *val, const struct kernel_param *kp)
 	return 0;
 }
 
+static void update_contention(struct aa_local_cache *cache)
+{
+	cache->contention += 3;
+	if (cache->contention > 9)
+		cache->contention = 9;
+	cache->hold += 1 << cache->contention;		/* 8, 64, 512 */
+}
+
 char *aa_get_buffer(bool in_atomic)
 {
 	union aa_buffer *aa_buf;
+	struct aa_local_cache *cache;
 	bool try_again = true;
 	gfp_t flags = (GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
 
+	/* use per cpu cached buffers first */
+	cache = get_cpu_ptr(&aa_local_buffers);
+	if (!list_empty(&cache->head)) {
+		aa_buf = list_first_entry(&cache->head, union aa_buffer, list);
+		list_del(&aa_buf->list);
+		cache->hold--;
+		put_cpu_ptr(&aa_local_buffers);
+		return &aa_buf->buffer[0];
+	}
+	put_cpu_ptr(&aa_local_buffers);
+
+	if (!spin_trylock(&aa_buffers_lock)) {
+		cache = get_cpu_ptr(&aa_local_buffers);
+		update_contention(cache);
+		put_cpu_ptr(&aa_local_buffers);
+		spin_lock(&aa_buffers_lock);
+	} else {
+		cache = get_cpu_ptr(&aa_local_buffers);
+		if (cache->contention)
+			cache->contention--;
+		put_cpu_ptr(&aa_local_buffers);
+	}
 retry:
-	spin_lock(&aa_buffers_lock);
 	if (buffer_count > reserve_count ||
 	    (in_atomic && !list_empty(&aa_global_buffers))) {
 		aa_buf = list_first_entry(&aa_global_buffers, union aa_buffer,

@@ -1655,6 +1692,7 @@ char *aa_get_buffer(bool in_atomic)
 	if (!aa_buf) {
 		if (try_again) {
 			try_again = false;
+			spin_lock(&aa_buffers_lock);
 			goto retry;
 		}
 		pr_warn_once("AppArmor: Failed to allocate a memory buffer.\n");

@@ -1666,15 +1704,39 @@ char *aa_get_buffer(bool in_atomic)
 void aa_put_buffer(char *buf)
 {
 	union aa_buffer *aa_buf;
+	struct aa_local_cache *cache;
 
 	if (!buf)
 		return;
 	aa_buf = container_of(buf, union aa_buffer, buffer[0]);
 
-	spin_lock(&aa_buffers_lock);
-	list_add(&aa_buf->list, &aa_global_buffers);
-	buffer_count++;
-	spin_unlock(&aa_buffers_lock);
+	cache = get_cpu_ptr(&aa_local_buffers);
+	if (!cache->hold || cache->count >= 2) {
+		put_cpu_ptr(&aa_local_buffers);
+		if (spin_trylock(&aa_buffers_lock)) {
+		locked:
+			list_add(&aa_buf->list, &aa_global_buffers);
+			buffer_count++;
+			spin_unlock(&aa_buffers_lock);
+			cache = get_cpu_ptr(&aa_local_buffers);
+			if (cache->contention)
+				cache->contention--;
+			put_cpu_ptr(&aa_local_buffers);
+			return;
+		}
+		cache = get_cpu_ptr(&aa_local_buffers);
+		update_contention(cache);
+		if (cache->count >= 2) {
+			put_cpu_ptr(&aa_local_buffers);
+			spin_lock(&aa_buffers_lock);
+			/* force putting the buffer to global */
+			goto locked;
+		}
+	}
+
+	/* cache in percpu list */
+	list_add(&aa_buf->list, &cache->head);
+	put_cpu_ptr(&aa_local_buffers);
 }
 
 /*

@@ -1716,6 +1778,15 @@ static int __init alloc_buffers(void)
 	union aa_buffer *aa_buf;
 	int i, num;
 
+	/*
+	 * per cpu set of cached allocated buffers used to help reduce
+	 * lock contention
+	 */
+	for_each_possible_cpu(i) {
+		per_cpu(aa_local_buffers, i).contention = 0;
+		per_cpu(aa_local_buffers, i).hold = 0;
+		INIT_LIST_HEAD(&per_cpu(aa_local_buffers, i).head);
+	}
 	/*
 	 * A function may require two buffers at once. Usually the buffers are
 	 * used for a short period of time and are shared. On UP kernel buffers

-- 
2.34.1

On 2023-02-16 16:08:10 [-0800], John Johansen wrote:

if you stick a local_lock_t into that struct, then you could replace
	cache = get_cpu_ptr(&aa_local_buffers);
with
	local_lock(&aa_local_buffers.lock);
	cache = this_cpu_ptr(&aa_local_buffers);

You would get the preempt_disable() based locking for the per-CPU
variable (as with get_cpu_ptr()) and additionally some lockdep
validation which would warn if it is used outside of task context (IRQ).

I didn't parse completely the hold/contention logic but it seems to work
;)
You check "cache->count >=  2" twice but I don't see an inc/ dec of it
nor is it part of aa_local_cache.

I can't parse how many items can end up on the local list if the global
list is locked. My guess would be more than 2 due the ->hold parameter.

Do you have any numbers on the machine and performance it improved? It
sure will be a good selling point.

Sebastian

On 2/17/23 02:44, Sebastian Andrzej Siewior wrote:

On 2023-02-16 16:08:10 [-0800], John Johansen wrote:

quoted

--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c

@@ -49,12 +49,19 @@ union aa_buffer {
  	char buffer[1];
  };
+struct aa_local_cache {
+	unsigned int contention;
+	unsigned int hold;
+	struct list_head head;
+};

if you stick a local_lock_t into that struct, then you could replace
	cache = get_cpu_ptr(&aa_local_buffers);
with
	local_lock(&aa_local_buffers.lock);
	cache = this_cpu_ptr(&aa_local_buffers);

You would get the preempt_disable() based locking for the per-CPU
variable (as with get_cpu_ptr()) and additionally some lockdep
validation which would warn if it is used outside of task context (IRQ).

I did look at local_locks and there was a reason I didn't use them. I
can't recall as the original iteration of this is over a year old now.
I will have to dig into it again.

I didn't parse completely the hold/contention logic but it seems to work
;)
You check "cache->count >=  2" twice but I don't see an inc/ dec of it
nor is it part of aa_local_cache.

sadly I messed up the reordering of this and the debug patch. This will be
fixed in v4.

I can't parse how many items can end up on the local list if the global
list is locked. My guess would be more than 2 due the ->hold parameter.

So this iteration, forces pushing back to global list if there are already
two on the local list. The hold parameter just affects how long the
buffers remain on the local list, before trying to place them back on
the global list.

Originally before the count was added more than 2 buffers could end up
on the local list, and having too many local buffers is a waste of
memory. The count got added to address this. The value of 2 (which should
be switched to a define) was chosen because no mediation routine currently
uses more than 2 buffers.

Note that this doesn't mean that more than two buffers can be allocated
to a tasks on a cpu. Its possible in some cases to have a task have
allocated buffers and to still have buffers on the local cache list.

Do you have any numbers on the machine and performance it improved? It
sure will be a good selling point.

I can include some supporting info, for a 16 core machine. But it will
take some time to for me to get access to a bigger machine, where this
is much more important. Hence the call for some of the other people
on this thread to test.

thanks for the feedback

I can test the patch with 5.10 and 5.15 kernels in different machines.
Just let me know which machine types you would like me to test.

On Mon, Feb 20, 2023 at 12:42 AM John Johansen
[off-list ref] wrote:

On 2/17/23 02:44, Sebastian Andrzej Siewior wrote:

quoted

On 2023-02-16 16:08:10 [-0800], John Johansen wrote:

quoted

--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c

@@ -49,12 +49,19 @@ union aa_buffer {
     char buffer[1];
  };
+struct aa_local_cache {
+    unsigned int contention;
+    unsigned int hold;
+    struct list_head head;
+};

if you stick a local_lock_t into that struct, then you could replace
      cache = get_cpu_ptr(&aa_local_buffers);
with
      local_lock(&aa_local_buffers.lock);
      cache = this_cpu_ptr(&aa_local_buffers);

You would get the preempt_disable() based locking for the per-CPU
variable (as with get_cpu_ptr()) and additionally some lockdep
validation which would warn if it is used outside of task context (IRQ).

I did look at local_locks and there was a reason I didn't use them. I
can't recall as the original iteration of this is over a year old now.
I will have to dig into it again.

quoted

I didn't parse completely the hold/contention logic but it seems to work
;)
You check "cache->count >=  2" twice but I don't see an inc/ dec of it
nor is it part of aa_local_cache.

sadly I messed up the reordering of this and the debug patch. This will be
fixed in v4.

quoted

I can't parse how many items can end up on the local list if the global
list is locked. My guess would be more than 2 due the ->hold parameter.

So this iteration, forces pushing back to global list if there are already
two on the local list. The hold parameter just affects how long the
buffers remain on the local list, before trying to place them back on
the global list.

Originally before the count was added more than 2 buffers could end up
on the local list, and having too many local buffers is a waste of
memory. The count got added to address this. The value of 2 (which should
be switched to a define) was chosen because no mediation routine currently
uses more than 2 buffers.

Note that this doesn't mean that more than two buffers can be allocated
to a tasks on a cpu. Its possible in some cases to have a task have
allocated buffers and to still have buffers on the local cache list.

quoted

Do you have any numbers on the machine and performance it improved? It
sure will be a good selling point.

I can include some supporting info, for a 16 core machine. But it will
take some time to for me to get access to a bigger machine, where this
is much more important. Hence the call for some of the other people
on this thread to test.

thanks for the feedback

Hi John,

I was wondering if you get a chance to work on patch v4. Please let me
know if you need help with testing.

Best,
Anil


On Tue, Feb 21, 2023 at 1:27 PM Anil Altinay [off-list ref] wrote:

I can test the patch with 5.10 and 5.15 kernels in different machines.
Just let me know which machine types you would like me to test.

On Mon, Feb 20, 2023 at 12:42 AM John Johansen
[off-list ref] wrote:

quoted

On 2/17/23 02:44, Sebastian Andrzej Siewior wrote:

quoted

On 2023-02-16 16:08:10 [-0800], John Johansen wrote:

quoted

--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c

@@ -49,12 +49,19 @@ union aa_buffer {
     char buffer[1];
  };
+struct aa_local_cache {
+    unsigned int contention;
+    unsigned int hold;
+    struct list_head head;
+};

if you stick a local_lock_t into that struct, then you could replace
      cache = get_cpu_ptr(&aa_local_buffers);
with
      local_lock(&aa_local_buffers.lock);
      cache = this_cpu_ptr(&aa_local_buffers);

You would get the preempt_disable() based locking for the per-CPU
variable (as with get_cpu_ptr()) and additionally some lockdep
validation which would warn if it is used outside of task context (IRQ).

I did look at local_locks and there was a reason I didn't use them. I
can't recall as the original iteration of this is over a year old now.
I will have to dig into it again.

quoted

I didn't parse completely the hold/contention logic but it seems to work
;)
You check "cache->count >=  2" twice but I don't see an inc/ dec of it
nor is it part of aa_local_cache.

sadly I messed up the reordering of this and the debug patch. This will be
fixed in v4.

quoted

I can't parse how many items can end up on the local list if the global
list is locked. My guess would be more than 2 due the ->hold parameter.

So this iteration, forces pushing back to global list if there are already
two on the local list. The hold parameter just affects how long the
buffers remain on the local list, before trying to place them back on
the global list.

Originally before the count was added more than 2 buffers could end up
on the local list, and having too many local buffers is a waste of
memory. The count got added to address this. The value of 2 (which should
be switched to a define) was chosen because no mediation routine currently
uses more than 2 buffers.

Note that this doesn't mean that more than two buffers can be allocated
to a tasks on a cpu. Its possible in some cases to have a task have
allocated buffers and to still have buffers on the local cache list.

quoted

Do you have any numbers on the machine and performance it improved? It
sure will be a good selling point.

I can include some supporting info, for a 16 core machine. But it will
take some time to for me to get access to a bigger machine, where this
is much more important. Hence the call for some of the other people
on this thread to test.

thanks for the feedback