musl - Should calls to mmap/brk handle EINTR?

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <VI1PR0502MB388524B97F2D582B51BC066AE73A0@VI1PR0502MB3885.eurprd05.prod.outlook.com>
Date: Tue, 28 Nov 2017 12:51:07 +0000
From: Nicholas Wilson <nicholas.wilson@...lvnc.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Should calls to mmap/brk handle EINTR?

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.