picnoir/Systemd
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
Systemd/src/test/test-cpu-set-util.c

171 lines
7.3 KiB
C
Raw Normal View History

Add SPDX license identifiers to source files under the LGPL This follows what the kernel is doing, c.f. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fd54ace4721fc5ce2bb5aef6318fcf17f421460.
2017-11-18 17:09:20 +01:00
/* SPDX-License-Identifier: LGPL-2.1+ */
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
#include "alloc-util.h"
#include "cpu-set-util.h"
#include "macro.h"
static void test_parse_cpu_set(void) {
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
CPUSet c = {};
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
_cleanup_free_ char *str = NULL;
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
int cpu;
/* Simple range (from CPUAffinity example) */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("1 2", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.set);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_ISSET_S(1, c.allocated, c.set));
assert_se(CPU_ISSET_S(2, c.allocated, c.set));
assert_se(CPU_COUNT_S(c.allocated, c.set) == 2);
assert_se(str = cpu_set_to_string(&c));
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* A more interesting range */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0 1 2 3 8 9 10 11", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 8);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 0; cpu < 4; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 8; cpu < 12; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
assert_se(str = cpu_set_to_string(&c));
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Quoted strings */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("8 '9' 10 \"11\"", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 4);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 8; cpu < 12; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
assert_se(str = cpu_set_to_string(&c));
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Use commas as separators */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0,1,2,3 8,9,10,11", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 8);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 0; cpu < 4; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 8; cpu < 12; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
assert_se(str = cpu_set_to_string(&c));
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Commas with spaces (and trailing comma, space) */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0, 1, 2, 3, 4, 5, 6, 7, ", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 8);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 0; cpu < 8; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
assert_se(str = cpu_set_to_string(&c));
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Ranges */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0-3,8-11", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 8);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 0; cpu < 4; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 8; cpu < 12; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
assert_se(str = cpu_set_to_string(&c));
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Ranges with trailing comma, space */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0-3 8-11, ", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 8);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 0; cpu < 4; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 8; cpu < 12; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
assert_se(str = cpu_set_to_string(&c));
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Negative range (returns empty cpu_set) */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("3-0", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 0);
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Overlapping ranges */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0-7 4-11", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 12);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 0; cpu < 12; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
assert_se(str = cpu_set_to_string(&c));
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Mix ranges and individual CPUs */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0,1 4-11", &c, true, NULL, "fake", 1, "CPUAffinity") >= 0);
assert_se(c.allocated >= sizeof(__cpu_mask) / 8);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 10);
assert_se(CPU_ISSET_S(0, c.allocated, c.set));
assert_se(CPU_ISSET_S(1, c.allocated, c.set));
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
for (cpu = 4; cpu < 12; cpu++)
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(CPU_ISSET_S(cpu, c.allocated, c.set));
assert_se(str = cpu_set_to_string(&c));
shared/cpu-set-util: move the part to print cpu-set into a separate function Also avoid unnecessary asprintf() when we can write to the output area directly.
2019-05-19 18:02:38 +02:00
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Garbage */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0 1 2 3 garbage", &c, true, NULL, "fake", 1, "CPUAffinity") == -EINVAL);
assert_se(!c.set);
assert_se(c.allocated == 0);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Range with garbage */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0-3 8-garbage", &c, true, NULL, "fake", 1, "CPUAffinity") == -EINVAL);
assert_se(!c.set);
assert_se(c.allocated == 0);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
/* Empty string */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("", &c, true, NULL, "fake", 1, "CPUAffinity") == 0);
assert_se(!c.set); /* empty string returns NULL */
assert_se(c.allocated == 0);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
test-cpu-set-util.c: fix typo in comment (#6916)
2017-09-26 13:50:31 +02:00
/* Runaway quoted string */
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
assert_se(parse_cpu_set_full("0 1 2 3 \"4 5 6 7 ", &c, true, NULL, "fake", 1, "CPUAffinity") == -EINVAL);
assert_se(!c.set);
assert_se(c.allocated == 0);
/* Maximum allocation */
assert_se(parse_cpu_set_full("8000-8191", &c, true, NULL, "fake", 1, "CPUAffinity") == 0);
assert_se(CPU_COUNT_S(c.allocated, c.set) == 192);
assert_se(str = cpu_set_to_string(&c));
log_info("cpu_set_to_string: %s", str);
str = mfree(str);
cpu_set_reset(&c);
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
}
int main(int argc, char *argv[]) {
Rework cpu affinity parsing The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size of the array, but operations which take two (CPU_EQUAL_S) or even three arrays (CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must be of the same size, or buffer overruns will occur. This is exactly what our code would do, if it received an array of unexpected size over the network. ("Unexpected" here means anything different from what cpu_set_malloc() detects as the "right" size.) Let's rework this, and store the size in bytes of the allocated storage area. The code will now parse any number up to 8191, independently of what the current kernel supports. This matches the kernel maximum setting for any architecture, to make things more portable. Fixes #12605.
2019-05-21 08:45:19 +02:00
log_info("CPU_ALLOC_SIZE(1) = %zu", CPU_ALLOC_SIZE(1));
log_info("CPU_ALLOC_SIZE(9) = %zu", CPU_ALLOC_SIZE(9));
log_info("CPU_ALLOC_SIZE(64) = %zu", CPU_ALLOC_SIZE(64));
log_info("CPU_ALLOC_SIZE(65) = %zu", CPU_ALLOC_SIZE(65));
log_info("CPU_ALLOC_SIZE(1024) = %zu", CPU_ALLOC_SIZE(1024));
log_info("CPU_ALLOC_SIZE(1025) = %zu", CPU_ALLOC_SIZE(1025));
log_info("CPU_ALLOC_SIZE(8191) = %zu", CPU_ALLOC_SIZE(8191));
tests: move cpu-set-util related tests to test-cpu-set-util.c
2016-03-02 23:29:49 +01:00
test_parse_cpu_set();
return 0;
}
Reference in a new issue Copy permalink