From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78811 invoked by alias); 19 Apr 2017 14:18:03 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 78724 invoked by uid 89); 19 Apr 2017 14:18:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=chips, 211, SMP, smp X-HELO: mail-qk0-f173.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lhBIpI8PdP4wXG723DmonEbLr/khA89Qr7eTeZ/KzkA=; b=LhTI8UPvQK0mMV40E+4dyHy1KlG0KOfyNyuuT1a9aMKcItnJ2mwyUsP+vTQU03YKKv +J1v1hvZ1tEix4l8JlkW2jrxVVnH/ttV82TEkf6p1riOwE4RWstZML+YPWkSvOVT9XP6 V5x13msK1SL7t6Tj8cq9bL2AiCVcPso0XCEsWilL/azWCJ6DKVXYhMgdG54qerlutLBh khuIgveH0HJ67FQYMfpLc96pWk8ZWIIE1S8h+GMwsFhmvNin8qNSgZ6VATJWHtMjAmk7 CmMaTvT013bmekceq2MhEikhz/JSsKote/rj/y/ILixRc8ON2yA4t4QqEYHmxHtevUoL 2rag== X-Gm-Message-State: AN3rC/4NorrGoV2GiuEqp7UQaZ7FtODIVFHhw404+3nnSsfSPMxVZKfZ B5tVWy5riqsihPe0 X-Received: by 10.55.74.215 with SMTP id x206mr2574866qka.57.1492611480301; Wed, 19 Apr 2017 07:18:00 -0700 (PDT) Subject: Re: [PATCH 1/2] nptl: Remove __ASSUME_SET_ROBUST_LIST To: Florian Weimer , libc-alpha@sourceware.org References: <1492550000-31374-1-git-send-email-adhemerval.zanella@linaro.org> <35b8a72e-dfce-6cd1-0998-a3866239da30@redhat.com> From: Adhemerval Zanella Message-ID: <85636314-6928-361f-234b-badec623b5a5@linaro.org> Date: Wed, 19 Apr 2017 14:18:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <35b8a72e-dfce-6cd1-0998-a3866239da30@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-04/txt/msg00369.txt.bz2 On 19/04/2017 02:36, Florian Weimer wrote: > On 04/18/2017 11:13 PM, Adhemerval Zanella wrote: >> This patch removes the __ASSUME_SET_ROBUST_LIST usage on nptl generic >> code. The set_robust_list availability is defined by '__set_robust_list_avail' >> which is now defined regardless. Its initial value is set to -1 and >> defined to a positive value if both __NR_set_robust_list is defined >> and the syscall returns correctly. > > I think we should drop support for kernels without set_robust_list. We really need something like robust mutex support for liveness detection of the nscd mappings. Making POSIX robust mutexes conditionally supported is awkward, and the fact that some architectures may lack support for them is undocumented. Application programmers will not expect this. > The problem is kernel supports for some architecture depends of kernel config and the underlying hardware revision/model. * ARM we have: arch/arm/include/asm/futex.h v3.0-rc1 #if defined(CONFIG_CPU_USE_DOMAINS) && defined(CONFIG_SMP) /* ARM doesn't provide unprivileged exclusive memory accessors */ #include #else And it was unconditionally define only on v3.15-rc1. It means that for some ARMv6 configure the futex_atomic_cmpxchg_inatomic may return ENOSYS. * Microblaze have a nasty bug that was fixed only on 3.10-rc4 (f6a12a7d0b): microblaze: Reversed logic in futex cmpxchg futex_atomic_cmpxchg_inatomic exchanged if the values were unequal rather than equal. This caused incorrect behavior of robust futexes. * MIPS still lacks proper supports depending of the underlying hardware: arch/mips/include/asm/futex.h 142 static inline int 143 futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr, 144 u32 oldval, u32 newval) 145 { 146 int ret = 0; 147 u32 val; 148 149 if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32))) 150 return -EFAULT; 151 152 if (cpu_has_llsc && R10000_LLSC_WAR) { [...] 181 } else if (cpu_has_llsc) { 182 __asm__ __volatile__( [...] 210 } else 211 return -ENOSYS; And kernel still have support for some architecture that lacks 'cpu_has_llsc' (although I am not sure if glibc also have support for this kind of cpu as well). * sh4 lacks proper SMP support (although not sure how common it is) and it was implemented on v4.8-rc1 (00b73d8d1b71). * m68k Uses the default include/asm-generic/futex.h which only has support for uniprocessors. That's why I think best option would to simplify glibc build to avoid multiple config depending of the underlying kernel config and query robust support at runtime. It is indeed awkward that some kernel option lacks robust support and we can check with hardware mantainers how often or if it desirable to support such config/chips.