Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

(#1713159) rules: skip memory hotplug on ppc64 #5

Merged
merged 1 commit into from
Jul 26, 2019
Merged

(#1713159) rules: skip memory hotplug on ppc64 #5

merged 1 commit into from
Jul 26, 2019

Conversation

jsynacek
Copy link
Contributor

@jsynacek jsynacek commented Jun 6, 2019

Resolves (#1713159)

haraldh
haraldh reviewed Jun 6, 2019
View reviewed changes
Copy link
Contributor

@haraldh haraldh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't that better be in an architecture dependent separate rules file, to be ifdef'ed in the spec file?

msekletar
msekletar approved these changes Jun 14, 2019
View reviewed changes
Copy link
Member

@msekletar msekletar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@msekletar
Copy link
Member

And I agree with Harald that we should start splitting 40-redhat.rules (we tried in the past and it didn't quite work out though).

Memory on-lining policy should be a separate rule file and we would include it only on architectures where we want on-lining to happen automatically.

@systemd-rhel-bot systemd-rhel-bot changed the title rules: skip memory hotplug on ppc64 (#1713159) rules: skip memory hotplug on ppc64 Jul 8, 2019
@systemd-rhel-bot systemd-rhel-bot added the tracker/unapproved Formerly needs-acks label Jul 8, 2019
@systemd-rhel-bot systemd-rhel-bot added pr/needs-ci Formerly needs-ci and removed pr/needs-ci Formerly needs-ci tracker/unapproved Formerly needs-acks labels Jul 15, 2019
@systemd-rhel-bot systemd-rhel-bot added tracker/missing Formerly needs-bz null and removed tracker/missing Formerly needs-bz pr/needs-review Formerly needs-review labels Jul 22, 2019
@systemd-rhel-bot systemd-rhel-bot merged commit 99e2090 into redhat-plumbers:rhel-8.1.0 Jul 26, 2019
mrc0mmand pushed a commit to mrc0mmand/rhel-8 that referenced this pull request Nov 27, 2019
@evverx @mrc0mmand
test: initialize syslog_fd in fuzz-journald-kmsg too
541dec0 
This is a follow-up to 8857fb9 that prevents the fuzzer from crashing with
```
==220==ERROR: AddressSanitizer: ABRT on unknown address 0x0000000000dc (pc 0x7ff4953c8428 bp 0x7ffcf66ec290 sp 0x7ffcf66ec128 T0)
SCARINESS: 10 (signal)
    #0 0x7ff4953c8427 in gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35427)
    redhat-plumbers#1 0x7ff4953ca029 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x37029)
    redhat-plumbers#2 0x7ff49666503a in log_assert_failed_realm /work/build/../../src/systemd/src/basic/log.c:805:9
    redhat-plumbers#3 0x7ff496614ecf in safe_close /work/build/../../src/systemd/src/basic/fd-util.c:66:17
    redhat-plumbers#4 0x548806 in server_done /work/build/../../src/systemd/src/journal/journald-server.c:2064:9
    redhat-plumbers#5 0x5349fa in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journald-kmsg.c:26:9
    redhat-plumbers#6 0x592755 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15
    redhat-plumbers#7 0x590627 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:480:3
    redhat-plumbers#8 0x594432 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:708:19
    redhat-plumbers#9 0x5973c6 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:839:5
    redhat-plumbers#10 0x574541 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6
    redhat-plumbers#11 0x5675fc in main /src/libfuzzer/FuzzerMain.cpp:20:10
    redhat-plumbers#12 0x7ff4953b382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    redhat-plumbers#13 0x420f58 in _start (/out/fuzz-journald-kmsg+0x420f58)
```

(cherry picked from commit cc55ac0)

Resolves: #1764560
systemd-rhel-bot pushed a commit that referenced this pull request Dec 3, 2019
@evverx @systemd-rhel-bot
test: initialize syslog_fd in fuzz-journald-kmsg too
af471e7 
This is a follow-up to 8857fb9 that prevents the fuzzer from crashing with
```
==220==ERROR: AddressSanitizer: ABRT on unknown address 0x0000000000dc (pc 0x7ff4953c8428 bp 0x7ffcf66ec290 sp 0x7ffcf66ec128 T0)
SCARINESS: 10 (signal)
    #0 0x7ff4953c8427 in gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35427)
    #1 0x7ff4953ca029 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x37029)
    #2 0x7ff49666503a in log_assert_failed_realm /work/build/../../src/systemd/src/basic/log.c:805:9
    #3 0x7ff496614ecf in safe_close /work/build/../../src/systemd/src/basic/fd-util.c:66:17
    #4 0x548806 in server_done /work/build/../../src/systemd/src/journal/journald-server.c:2064:9
    #5 0x5349fa in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journald-kmsg.c:26:9
    #6 0x592755 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15
    #7 0x590627 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:480:3
    #8 0x594432 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:708:19
    #9 0x5973c6 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:839:5
    #10 0x574541 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6
    #11 0x5675fc in main /src/libfuzzer/FuzzerMain.cpp:20:10
    #12 0x7ff4953b382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #13 0x420f58 in _start (/out/fuzz-journald-kmsg+0x420f58)
```

(cherry picked from commit cc55ac0)

Resolves: #1764560
@mergify mergify bot added the pr/needs-ci Formerly needs-ci label Jan 20, 2023
msekletar pushed a commit to msekletar/systemd-rhel8 that referenced this pull request Dec 22, 2023
@keszybz @msekletar
basic/fd-util: refuse "infinite" loop in close_all_fds()
40cf67e 
I had a test machine with ulimit -n set to 1073741816 through pam
("session required pam_limits.so set_all", which copies the limits from PID 1,
left over from testing of #10921).

test-execute would "hang" and then fail with a timeout when running
exec-inaccessiblepaths-proc.service. It turns out that the problem was in
close_all_fds(), which would go to the fallback path of doing close()
1073741813 times. Let's just fail if we hit this case. This only matters
for cases where both /proc is inaccessible, and the *soft* limit has been
raised.

  (gdb) bt
  #0  0x00007f7e2e73fdc8 in close () from target:/lib64/libc.so.6
  redhat-plumbers#1  0x00007f7e2e42cdfd in close_nointr ()
     from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
  redhat-plumbers#2  0x00007f7e2e42d525 in close_all_fds ()
     from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
  redhat-plumbers#3  0x0000000000426e53 in exec_child ()
  redhat-plumbers#4  0x0000000000429578 in exec_spawn ()
  redhat-plumbers#5  0x00000000004ce1ab in service_spawn ()
  redhat-plumbers#6  0x00000000004cff77 in service_enter_start ()
  redhat-plumbers#7  0x00000000004d028f in service_enter_start_pre ()
  redhat-plumbers#8  0x00000000004d16f2 in service_start ()
  redhat-plumbers#9  0x00000000004568f4 in unit_start ()
  redhat-plumbers#10 0x0000000000416987 in test ()
  redhat-plumbers#11 0x0000000000417632 in test_exec_inaccessiblepaths ()
  redhat-plumbers#12 0x0000000000419362 in run_tests ()
  redhat-plumbers#13 0x0000000000419632 in main ()

(cherry picked from commit 6a461d1)

Related: RHEL-18302
msekletar pushed a commit to msekletar/systemd-rhel8 that referenced this pull request Dec 22, 2023
@keszybz @msekletar
basic/fd-util: refuse "infinite" loop in close_all_fds()
6e205f3 
I had a test machine with ulimit -n set to 1073741816 through pam
("session required pam_limits.so set_all", which copies the limits from PID 1,
left over from testing of #10921).

test-execute would "hang" and then fail with a timeout when running
exec-inaccessiblepaths-proc.service. It turns out that the problem was in
close_all_fds(), which would go to the fallback path of doing close()
1073741813 times. Let's just fail if we hit this case. This only matters
for cases where both /proc is inaccessible, and the *soft* limit has been
raised.

  (gdb) bt
  #0  0x00007f7e2e73fdc8 in close () from target:/lib64/libc.so.6
  redhat-plumbers#1  0x00007f7e2e42cdfd in close_nointr ()
     from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
  redhat-plumbers#2  0x00007f7e2e42d525 in close_all_fds ()
     from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
  redhat-plumbers#3  0x0000000000426e53 in exec_child ()
  redhat-plumbers#4  0x0000000000429578 in exec_spawn ()
  redhat-plumbers#5  0x00000000004ce1ab in service_spawn ()
  redhat-plumbers#6  0x00000000004cff77 in service_enter_start ()
  redhat-plumbers#7  0x00000000004d028f in service_enter_start_pre ()
  redhat-plumbers#8  0x00000000004d16f2 in service_start ()
  redhat-plumbers#9  0x00000000004568f4 in unit_start ()
  redhat-plumbers#10 0x0000000000416987 in test ()
  redhat-plumbers#11 0x0000000000417632 in test_exec_inaccessiblepaths ()
  redhat-plumbers#12 0x0000000000419362 in run_tests ()
  redhat-plumbers#13 0x0000000000419632 in main ()

(cherry picked from commit 6a461d1)

Related: RHEL-18302
msekletar pushed a commit to msekletar/systemd-rhel8 that referenced this pull request Dec 22, 2023
@keszybz @msekletar
basic/fd-util: refuse "infinite" loop in close_all_fds()
922bd45 
I had a test machine with ulimit -n set to 1073741816 through pam
("session required pam_limits.so set_all", which copies the limits from PID 1,
left over from testing of #10921).

test-execute would "hang" and then fail with a timeout when running
exec-inaccessiblepaths-proc.service. It turns out that the problem was in
close_all_fds(), which would go to the fallback path of doing close()
1073741813 times. Let's just fail if we hit this case. This only matters
for cases where both /proc is inaccessible, and the *soft* limit has been
raised.

  (gdb) bt
  #0  0x00007f7e2e73fdc8 in close () from target:/lib64/libc.so.6
  redhat-plumbers#1  0x00007f7e2e42cdfd in close_nointr ()
     from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
  redhat-plumbers#2  0x00007f7e2e42d525 in close_all_fds ()
     from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
  redhat-plumbers#3  0x0000000000426e53 in exec_child ()
  redhat-plumbers#4  0x0000000000429578 in exec_spawn ()
  redhat-plumbers#5  0x00000000004ce1ab in service_spawn ()
  redhat-plumbers#6  0x00000000004cff77 in service_enter_start ()
  redhat-plumbers#7  0x00000000004d028f in service_enter_start_pre ()
  redhat-plumbers#8  0x00000000004d16f2 in service_start ()
  redhat-plumbers#9  0x00000000004568f4 in unit_start ()
  redhat-plumbers#10 0x0000000000416987 in test ()
  redhat-plumbers#11 0x0000000000417632 in test_exec_inaccessiblepaths ()
  redhat-plumbers#12 0x0000000000419362 in run_tests ()
  redhat-plumbers#13 0x0000000000419632 in main ()

(cherry picked from commit 6a461d1)

Related: RHEL-18302
github-actions bot pushed a commit that referenced this pull request Jan 8, 2024
@keszybz @github-actions
basic/fd-util: refuse "infinite" loop in close_all_fds()
957edb0 
I had a test machine with ulimit -n set to 1073741816 through pam
("session required pam_limits.so set_all", which copies the limits from PID 1,
left over from testing of #10921).

test-execute would "hang" and then fail with a timeout when running
exec-inaccessiblepaths-proc.service. It turns out that the problem was in
close_all_fds(), which would go to the fallback path of doing close()
1073741813 times. Let's just fail if we hit this case. This only matters
for cases where both /proc is inaccessible, and the *soft* limit has been
raised.

  (gdb) bt
  #0  0x00007f7e2e73fdc8 in close () from target:/lib64/libc.so.6
  #1  0x00007f7e2e42cdfd in close_nointr ()
     from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
  #2  0x00007f7e2e42d525 in close_all_fds ()
     from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
  #3  0x0000000000426e53 in exec_child ()
  #4  0x0000000000429578 in exec_spawn ()
  #5  0x00000000004ce1ab in service_spawn ()
  #6  0x00000000004cff77 in service_enter_start ()
  #7  0x00000000004d028f in service_enter_start_pre ()
  #8  0x00000000004d16f2 in service_start ()
  #9  0x00000000004568f4 in unit_start ()
  #10 0x0000000000416987 in test ()
  #11 0x0000000000417632 in test_exec_inaccessiblepaths ()
  #12 0x0000000000419362 in run_tests ()
  #13 0x0000000000419632 in main ()

(cherry picked from commit 6a461d1)

Related: RHEL-18302
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@haraldh haraldh haraldh left review comments

@msekletar msekletar msekletar approved these changes

Assignees
No one assigned
Labels
pr/needs-ci Formerly needs-ci released rhel-8.1.0
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@jsynacek @msekletar @haraldh @jamacku @systemd-rhel-bot