lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ffd13862-bc57-45ae-9fd0-454ee2d30fc2@canonical.com>
Date:   Tue, 17 Oct 2023 02:21:01 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>
Cc:     Anil Altinay <aaltinay@...gle.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        LKLM <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Tomasz Figa <tfiga@...omium.org>,
        linux-security-module@...r.kernel.org,
        John Johansen <john.johansen@...onical.com>
Subject: [PATCH v5 0/4] apparmor: cache buffers on percpu list if there is
 lock, contention

On 10/5/23 21:18, Sergey Senozhatsky wrote:
> On (23/06/26 17:31), John Johansen wrote:
>> On 6/26/23 16:33, Anil Altinay wrote:
>>> 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.
>>>
>>
>> yeah, testing help is always much appreciated. I have a v4, and I am
>> working on 3 alternate version to compare against, to help give a better
>> sense if we can get away with simplifying or tweak the scaling.
>>
>> I should be able to post them out some time tonight.
> 
> Hi John,
> 
> Did you get a chance to post v4? I may be able to give it some testing
> on our real-life case.

sorry yes, how about a v5. That is simplified with 3 follow on patches
that aren't strictly necessary, but some combination of them might be
better than just the base patch, but splitting them out makes the
individual changes easier to review.

---


df323337e507 ("apparmor: Use a memory pool instead per-CPU caches")
changed buffer allocation to use a memory pool, however 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.

v5:
- simplify base patch by removing: improvements can be added later
   - MAX_LOCAL and must lock
   - contention scaling.
v4:
- fix percpu ->count buffer count which had been spliced across a
   debug patch.
- introduce define for MAX_LOCAL_COUNT
- rework count check and locking around it.
- update commit message to reference commit that introduced the
   memory.
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

Reported-by: Sergey Senozhatsky <senozhatsky@...omium.org>
Signed-off-by: John Johansen <john.johansen@...onical.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ