This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: NPTL futex error handling
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 28 Jan 2014 10:08:17 +0530
- Subject: Re: NPTL futex error handling
- Authentication-results: sourceware.org; auth=none
- References: <52E66CD1 dot 5030402 at redhat dot com> <CAAHN_R2bBH_xLA7dB_4zDXZyLURb6Euvcpni3GWFU2wY1Mvb0Q at mail dot gmail dot com> <52E672E2 dot 3010907 at redhat dot com>
On Mon, Jan 27, 2014 at 03:53:22PM +0100, Florian Weimer wrote:
> On 01/27/2014 03:38 PM, Siddhesh Poyarekar wrote:
> >On 27 January 2014 19:57, Florian Weimer <fweimer@redhat.com> wrote:
> >>Looking at the kernel code, I believe that FUTEX_LOCK_PI and FUTEX_WAKE (in
> >>the case of cross-process mutexes, it seems) can fail with ENOMEM, in
> >>addition to the more-or-less expected failure cases.
> >>
> >>Is the ENOMEM return value due to kernel changes after the initial futex
> >>implementation, or has this already been evaluated and deemed not be
> >>necessary for correctness?
> >
> >I guess you're referring to the return from refill_pi_state_cache?
>
> Yes, and the call to get_user_pages in the cross-process case.
Hmmm, I (incorrectly) assumed that get_user_pages would only return
EFAULT. get_user_pages failing with ENOMEM will impact everything,
even regular FUTEX_WAIT. In fact, it doesn't look like
pthread_mutex_lock is supposed to return EFAULT either.
Siddhesh