otherwise we end up with more than one job with the same identifier in
one run, causing some of them to get cancelled unexpectedly.
A quick follow-up to 85bd394df5.
Follow-up for 7d85383edb.
Apparently the previous limit set on the max number of inodes for /dev was too
small as a system with 4096 LUNs attached can consume up to 95k inodes for
symlinks:
# /bin/df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
devtmpfs 49274377 95075 49179302 1% /dev
Hence this patch bumps the limit from 64k to 128k although the new limit is
still pretty arbitrary (that said, not sure if it really makes sense to put
such absolute limit number).
In 9cf75222f2 the conf.get() statements for `bpf-framework` and
`valgrind` were dropped, which causes the respective features to always
show as disabled (since they don't follow the "standard" naming scheme
with HAVE_/ENABLE_ prefixes).
This is a slightly modified version of the original
`cpp/uninitialized-local` CodeQL query which focuses only on variables
using the cleanup macros. Since this has proven to cause issues in the
past, let's panic on every uninitialized variable using any of the
cleanup macros (as long as they're written using the __cleanup__
attribute).
Some test results from a test I used when writing the query:
```
#define _cleanup_foo_ __attribute__((__cleanup__(foo)))
#define _cleanup_(x) __attribute__((__cleanup__(x)))
static inline void freep(void *p) {
*(void**)p = mfree(*(void**) p);
}
#define _cleanup_free_ _cleanup_(freep)
static inline void foo(char **p) {
if (*p)
*p = free(*p);
}
int main(void) {
__attribute__((__cleanup__(foo))) char *a;
char *b;
_cleanup_foo_ char *c;
char **d;
_cleanup_free_ char *e;
int r;
r = fun(&e);
if (r < 0)
return 1;
puts(a);
puts(b);
puts(c);
puts(*d);
puts(e);
return 0;
}
```
```
+| test.c:23:14:23:14 | e | The variable $@ may not be initialized here, but has a cleanup handler. | test.c:20:26:20:26 | e | e |
+| test.c:27:10:27:10 | a | The variable $@ may not be initialized here, but has a cleanup handler. | test.c:16:45:16:45 | a | a |
+| test.c:29:10:29:10 | c | The variable $@ may not be initialized here, but has a cleanup handler. | test.c:18:25:18:25 | c | c |
```
Get the cgroup root path from the current PID, so that when
ran by the user manager we can get to the right path.
Eg: foo.slice:10% will check under:
/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/foo.slice/cpu.pressure
Follow-up for 81513b382b
It could work, but it doesn't make much sense. If we already have openssl as
the cryptolib that provides the necessary support, let's not bring in another
library. Disallowing this simplifies things and reduces our support matrix.
