Bug 2137584

Summary:	bus_poll() can fail with EINTR, which doesn't seem handled by callers at all
Product:	Red Hat Enterprise Linux 9	Reporter:	Renaud Métrich <rmetrich>
Component:	systemd	Assignee:	David Tardon <dtardon>
Status:	CLOSED ERRATA	QA Contact:	Frantisek Sumsal <fsumsal>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9.0	CC:	dtardon, jamacku, systemd-maint-list
Target Milestone:	rc	Keywords:	Improvement, Triaged
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	systemd-252-2.el9	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-05-09 08:21:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Renaud Métrich 2022-10-25 15:02:07 UTC

Description of problem:

This is a continuation of RHEL7 BZ #2137579.

It's possible that ppoll() syscall fails with EINTR or EAGAIN, per poll(2) manpage:
~~~
ERRORS

       EINTR  A signal occurred before any requested event; see signal(7).

NOTES

       On some other UNIX systems, poll() can fail with the error EAGAIN if the system fails to allocate kernel-in‐
       ternal  resources,  rather  than  ENOMEM as Linux does.  POSIX permits this behavior.  Portable programs may
       wish to check for EAGAIN and loop, just as with EINTR.
~~~ 

Experiencing EINTR is definitely possible, as shows on RHEL7 with BZ #2137579.
(On RHEL8 the reproducer doesn't work because sshd just doesn't go through PAM stack upon client disconnection).

Looking at the code, I can see these special cases are not handled:
~~~
3000 static int bus_poll(sd_bus *bus, bool need_more, uint64_t timeout_usec) {
 :
3059         r = ppoll(p, n, m == USEC_INFINITY ? NULL : timespec_store(&ts, m), NULL);
3060         if (r < 0)
3061                 return -errno;
 :
~~~

I think this call has to be robust and loop on getting such errno, at least for EINTR.


Version-Release number of selected component (if applicable):

systemd-239

How reproducible:

Don't know yet.

Comment 1 David Tardon 2022-10-26 14:05:50 UTC

If I understand the code correctly, EINTR is supposed to be handled by callers of bus_poll() (because it's almost always called from a loop anyway), but the check is missing at a few places. In particular, I think that sd_bus_call() is the culprit in the case of bug 2137579.

EAGAIN is not interesting because systemd doesn't support "some other UNIX systems", only Linux.

Comment 2 David Tardon 2022-10-26 14:14:46 UTC

(In reply to David Tardon from comment #1)
> If I understand the code correctly, EINTR is supposed to be handled by
> callers of bus_poll() (because it's almost always called from a loop
> anyway), but the check is missing at a few places. In particular, I think
> that sd_bus_call() is the culprit in the case of bug 2137579.

Eh, actually I was looking at how EINTR is typically handled, not specifically just places that call bus_poll(). But I still think that the error should be handled by callers of bus_poll().

Comment 3 Renaud Métrich 2022-10-26 15:14:01 UTC

I think specifically for bus_poll() we should just retry immediately.
But maybe there are other places to look at indeed.
I tried producing some EINTR on RHEL8 this morning but couldn't.

Comment 4 David Tardon 2022-10-27 08:45:30 UTC

(In reply to Renaud Métrich from comment #3)
> I tried producing some EINTR on RHEL8 this morning but couldn't.

Just to simulate the situation to see what happens should be relatively simple using a gdb script that breaks on bus_poll() and returns -EINTR. Something like (untested):

# cat > eintr.gdb <<EOF
break bus_poll
commands
    disable
    return -EINTR
end
continue
EOF

# gdb -nx -x eintr.gdb --pid=1

Comment 5 David Tardon 2022-11-24 09:24:49 UTC

Given that there's no known reproducer for the issue on RHEL-8, do we need to backport the fix(es) there? Maybe RHEL-9 is enough?

Comment 6 Renaud Métrich 2022-11-24 10:50:11 UTC

Yes RHEL9 is good enough.

Comment 7 Plumber Bot 2022-12-08 20:37:34 UTC

fix merged to github main branch -> https://github.com/redhat-plumbers/systemd-rhel9/pull/123

Comment 12 errata-xmlrpc 2023-05-09 08:21:58 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (systemd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2531