[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <VI1PR0502MB38854C05D6B32D9A63C56F1EE73A0@VI1PR0502MB3885.eurprd05.prod.outlook.com>
Date: Tue, 28 Nov 2017 14:44:00 +0000
From: Nicholas Wilson <nicholas.wilson@...lvnc.com>
To: Florian Weimer <fweimer@...hat.com>
CC: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Should calls to mmap/brk handle EINTR?
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@...hat.com>
Sent: 28 November 2017 14:29:00
To: Nicholas Wilson
Cc: musl@...ts.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
