[PATCH] Mark syslog as MT-unsafe (bug 26100)

[Carlos O'Donell]

On 6/15/20 2:51 PM, Zack Weinberg wrote:
> On Mon, Jun 15, 2020 at 2:07 PM Carlos O'Donell <carlos@redhat.com> wrote:
>> On 6/15/20 10:18 AM, Zack Weinberg wrote:
>>> Messages to syslog need to be serialized over the whole process
>>> _anyway_, so I don't see a problem with having
>>> syslog/openlog/closelog/setlogmask take an internal mutex around the
>>> shared global state.
>>
>> When we add new locks we also have to consider MT-fork issues and if
>> any existing semi-legitimate uses may be impacted by the locks taken
>> by these functions.
> 
> Hmm.  I can think of two scenarios where that could be a problem.
> First, if one thread is calling syslog at the same time as another
> thread calls fork, so the syslog lock is locked in the child process,
> and then the child tries to call syslog, it will deadlock.  This seems
> like something that could easily happen and people would want it to
> work, but we could deal with it with another internal fork handler.

Yes, this is the "seim-legitimate uses" I was thinking of, and in the
standard it says you should only call AS-safe functions e.g. "Consequently,
to avoid errors, the child process may only execute async-signal-safe
operations until such time as one of the exec functions is called."

However, looking at bugzilla, I see Florian discovered this was non-working:
Bug 19429 - syslog unusable after fork from a multi-threaded program
https://sourceware.org/bugzilla/show_bug.cgi?id=19429

This is not a bug, and given that it doesn't work today, I don't want
to suggest we make syslog AS-Safe. I was only suggesting we double check
there wasn't any latent expectations from already existing user code.

It seems that because of bug 19429 there can't really be any such
expectations.

> Second, if fork is called from an async signal handler that
> interrupted the guts of syslog, syslog will again be unusable in the
> child; but in that case the child is required to use only AS-safe
> functions, so maybe we can get away with it?

This is the same as the other case, an MT-fork'd child must always
use only AS-safe functions.
 
> Can you think of any others?

No, those are the cases I was thinking about. However, for me, the
fact that bug 19429 exists, settles it for me, we just need to fix
the MT-safe case.

-- 
Cheers,
Carlos.