Should calls to mmap/brk handle EINTR?

Should calls to mmap/brk handle EINTR?

[Nicholas Wilson]

Hi,

I've noticed that in Linux 4.7, there's a change compared to the Linux 4.6 code. The mmap and brk syscalls are protected by semaphores, and previously, those syscalls did an uninterruptible wait on the semaphore. Since Linux 4.7, those syscalls can now return EINTR if the semaphore is under contention, and a signal is received while waiting on it.

I've checked glibc, and they don't seem to have any handling for EINTR either on these calls.

I know it's very unlikely, but should the calls to mmap be changed to do a retry loop? If malloc fails, it can cause very unpleasant behaviour in an application - and yet memory isn't exhausted, it's simply caused by contention. If lots of threads are concurrently doing malloc/free on large regions, it *might* be possible for the malloc to fail spuriously?

I just wondered if it had been noticed/considered. Maybe ask the glibc people if they've noticed the change?

All the best,
Nick

Re: Should calls to mmap/brk handle EINTR?

[Florian Weimer]

On 11/28/2017 01:51 PM, Nicholas Wilson wrote:

> I've noticed that in Linux 4.7, there's a change compared to the Linux 4.6 code. The mmap and brk syscalls are protected by semaphores, and previously, those syscalls did an uninterruptible wait on the semaphore. Since Linux 4.7, those syscalls can now return EINTR if the semaphore is under contention, and a signal is received while waiting on it.

Is this really true?  How is this not a kernel bug?

Commit dc0ef0df7b6a90892ec41933212ac701152a254c says this:

“
…
Most of the patches are really trivial because the lock is help from a
shallow syscall paths where we can return EINTR trivially and allow the
current task to die (note that EINTR will never get to the userspace as
the task has fatal signal pending). …
”

Those EINTRs really have to be invisible from userspace.  If you can 
reproduce EINTR returns to userspace, then something is very wrong.

Thanks,
Florian

Re: Should calls to mmap/brk handle EINTR?

[Nicholas Wilson]

Ah, thanks very much!

I hadn't dug that deep, I just jumped to a conclusion when I saw "return -EINTR", without realising that was just a dummy return value.

Thanks for checking that, I haven't managed to reproduce it, I just guessed from seeing the code that it was possible.

Nick

________________________________________
From: Florian Weimer <fweimer@redhat.com>
Sent: 28 November 2017 14:29:00
To: Nicholas Wilson
Cc: musl@lists.openwall.com
Subject: Re: [musl] Should calls to mmap/brk handle EINTR?

On 11/28/2017 01:51 PM, Nicholas Wilson wrote:

> I've noticed that in Linux 4.7, there's a change compared to the Linux 4.6 code. The mmap and brk syscalls are protected by semaphores, and previously, those syscalls did an uninterruptible wait on the semaphore. Since Linux 4.7, those syscalls can now return EINTR if the semaphore is under contention, and a signal is received while waiting on it.

Is this really true?  How is this not a kernel bug?

Commit dc0ef0df7b6a90892ec41933212ac701152a254c says this:

“
…
Most of the patches are really trivial because the lock is help from a
shallow syscall paths where we can return EINTR trivially and allow the
current task to die (note that EINTR will never get to the userspace as
the task has fatal signal pending). …
”

Those EINTRs really have to be invisible from userspace.  If you can
reproduce EINTR returns to userspace, then something is very wrong.

Thanks,
Florian