mmap not async-signal-safe?

[Oleg Goldshmidt]

Shachar Shemesh <shachar at shemesh.biz> writes:

> Hi all,
>
> As we all know, from a signal handler it is only safe to call
> functions that are "async signal safe". I have a couple of questions
> (three, actually), if anyone happens to know the answer to:
>
> First, why the name? The list contains functions that are obviously
> not async. Does that mean these functions are only safe in
> non-blocking mode? (make sense, but you'd expect it to be better
> documented)
>
> The second is why isn't mmap and munmap on this list? These are
> functions that are handled entirely by the kernel, and will, therefor,
> never block on something that is up to the program that is currently
> halted by the signal. Mmap is, in fact, marked as async-signal-safe on
> Solaris[1]. And yet, Posix decided not to include it in its list. On a
> related note - is mmap async-signal-safe on Linux?

Hi Shachar,

I suspect you misinterpret the intent of the standard a bit. The
standard specifies that the implementation of the functions on the list
must guarantee that they are safe. Other functions may also be safe in
particular implementations (mmap on Solaris is an example, apparently),
but the standard does not require it.

"Safe" in the context means the following: if an "unsafe" function is
interrupted by the signal and the handler calls the function, too, the
resulting behaviour is undefined. Once again, if I understand it
correctly all that POSIX requires is that the functions on the list
should be "safe" in this sense. It does not say that other functions are
not safe.

[Source: "man 7 signal"]

Adding a general note: I have been under the impression that safe signal
handling normally involved setting some flag in the handler and
returning control to the main flow as soon as possible. There one can
check the flag and do whatever needs to be done.

Note that POSIX is actually a generalization of the ISO C standard that
says that only abort(), _Exit(), and signal() are safe to call in
handlers.

Adding an uncertain note on mmap: I do not know if it is
async-signal-safe on Linux. At least one danger is a deadlock: if a
function locks something, gets interrupted by a signal, and gets called
by a handler, you are in trouble. Apparently on Solaris mmap is
guaranteed not to lock anything. On Linux - dunno: is MAP_LOCKED
relevant? I'd handle with care...
  
> And, lastly, what is the signal delivery flow in the kernel? What
> happens when a signal arrives in the middle of a blocking system call?
> Is the signal handler really called before the system call code has
> finished? The prospect seems so absurd to me that it defies all logic,
> as well as my understanding of the process, but that is the only
> explanation I have for why mmap should not be signal handler safe.

Isn't it also described in "man 7 signal", in the section called
"Interruption of System Calls and Library Functions by Signal Handlers"?
[Also in "Interruption of System Calls and Library Functions by Stop
Signals" right after that.]

I may be misreading your question here.

Hope it helps, anyway,

-- 
Oleg Goldshmidt | pub at goldshmidt.org