You have been subscribed to a public bug by Ioanna Alifieraki (joalif):

[IMPACT]
There is a known and patched issue with version 2.4 of libseccomp where certain 
operations have a large performance regression. This is causing some packages 
that use libseccomp such as container orchestration systems to occasionally 
time out or otherwise fail under certain workloads.

Please consider porting the patch into the various Ubuntu versions that
have version 2.4 of libseccomp and into the backports. The performance
patch from version 2.5 (yet to be released) applies cleanly on top of
the 2.4 branch of libseccomp.

For more information, and for a copy of the patch (which can also be
cherry picked from the upstream libseccomp repos) see the similar Debian
issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913

Upstream issue : https://github.com/seccomp/libseccomp/issues/153
Upstream fix : https://github.com/seccomp/libseccomp/pull/180/

[Test Case]

For this test case we use Docker on Ubuntu Groovy (20.10) :

--> Current libseccomp version
#dpkg -l | grep libseccomp
ii  libseccomp2:amd64                          2.4.3-1ubuntu3                   
   amd64        high level interface to Linux seccomp filter

## pull ubuntu image
# docker pull ubuntu
## create a container
# docker run --name test_seccomp -it 74435f89ab78 /bin/bash

## run test case
# for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done
...
MAX TIME :
real    0m10,319s
user    0m0,018s
sys     0m0,033s


--> Patched libseccomp version

# dpkg -l | grep libseccomp
ii  libseccomp2:amd64                          2.4.3-1ubuntu4                   
   amd64        high level interface to Linux seccomp filter

# docker start test_seccomp
## run test case
# for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done
...
MAX TIME :
real    0m3,650s
user    0m0,025s
sys     0m0,028s

[Regression Potential]

The first of the 2 patches cleans up the code that adds rules to a
single filter without changing the logic of the code. The second patch
introduces the idea of shadow transactions. On a successful transaction
commit the old transaction checkpoint is preserved and is brought up to
date with the current filter. The next time a new transaction starts, it
checks is the a shadow transaction exist and if so the shadow is used
instead of creating a new checkpoint from scratch [1]. This is the patch
that mitigates the performance regression. Any potential regression will
involve the parts of the code that add rules to filters and/or the code
that creates and checks the shadow transactions.


[Other]

Affected releases : Groovy, Focal, Eoan, Bionic, Xenial.

[1]
https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d

** Affects: snapd
     Importance: Medium
         Status: Invalid

** Affects: libseccomp (Ubuntu)
     Importance: Medium
     Assignee: Ioanna Alifieraki (joalif)
         Status: In Progress

** Affects: libseccomp (Ubuntu Xenial)
     Importance: Medium
     Assignee: Ioanna Alifieraki (joalif)
         Status: In Progress

** Affects: libseccomp (Ubuntu Bionic)
     Importance: Medium
     Assignee: Ioanna Alifieraki (joalif)
         Status: In Progress

** Affects: libseccomp (Ubuntu Eoan)
     Importance: Medium
     Assignee: Ioanna Alifieraki (joalif)
         Status: In Progress

** Affects: libseccomp (Ubuntu Focal)
     Importance: Medium
     Assignee: Ioanna Alifieraki (joalif)
         Status: In Progress

** Affects: libseccomp (Ubuntu Groovy)
     Importance: Medium
     Assignee: Ioanna Alifieraki (joalif)
         Status: In Progress


** Tags: patch
-- 
seccomp_rule_add is very slow
https://bugs.launchpad.net/bugs/1861177
You received this bug notification because you are a member of STS Sponsors, 
which is subscribed to the bug report.

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

Reply via email to