From patchwork Fri Jan 13 12:56:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adhemerval Zanella Netto X-Patchwork-Id: 91396 Delivered-To: patch@linaro.org Received: by 10.140.20.99 with SMTP id 90csp176029qgi; Fri, 13 Jan 2017 04:57:21 -0800 (PST) X-Received: by 10.84.241.129 with SMTP id b1mr29608764pll.135.1484312241879; Fri, 13 Jan 2017 04:57:21 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id d10si4797096pln.27.2017.01.13.04.57.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 04:57:21 -0800 (PST) Received-SPF: pass (google.com: domain of libc-alpha-return-76765-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org; spf=pass (google.com: domain of libc-alpha-return-76765-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=libc-alpha-return-76765-patch=linaro.org@sourceware.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:subject:to:references:cc:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=OqOlUFxw+dq2zaFl K7Qh/VJNr77h+yipL4xrrZ/lmt1WAOPIPBeTu28a4FwmrxI23p1j7Atit7NKEiNl Mifdso5/d9NUSeqnGtjXUVBi+L5JT/hV6ctuAKrWgtficsiZNw1+mIaS1e5xxOww HXnHLScE8G7v4jteaN4pzs8H1Ew= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:subject:to:references:cc:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=yoBuJsV+fStVv752ETY1Co n936Q=; b=sSlplRgdDbHGGuIt8h4YudXfsFdk8mL2ZMWV8bQJzakV0EWBQSETVj eWT+lkED2OzBUFqQ1Ub95h2bGtFFYvT/7lA5tQ9tn5Tx0OJnDDItGGgbVd6+TeBZ Jz2hb0U0Ms+DiqeCt6AjuDnQ36LVXuaVRk14jfkc/W9GWVAuWrPg8= Received: (qmail 109005 invoked by alias); 13 Jan 2017 12:57:09 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 108354 invoked by uid 89); 13 Jan 2017 12:57:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-ua0-f182.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SEk4SB1PA0hJ4g3y2apAYkBISFa3nvCUiNHEdb+PMZc=; b=oYvR58V13j0urwiO8us4utoBSQXa7h6eXsMHcHMusAetrtrcPSmuuYXV/tsYXJqdri oTcv1Y7W0lEzMAorqzsiGhHYAfdb4F0BzgSKFFHie4Lj5HI8RTcp02AMfJMursc41NJG mclGMUvyQKoL7x+l1XpuojeESRBMdlpEAQopbRSOiTTp9WEfM2mRkQbiGo0z3i8f5gnD 4AOca4DmC+64xz+E0uwvkyIDY+XVLmyxn4vd6IG9VKPVpimL1R3X3xDRfG2AoCrTtQ9B iIj+XuQIV/Oxy3MS4dxuQi3CfSzOktK8KstQMre4UpjZ1hI25WklH/gVK3DAg5WfG8Sy HD+w== X-Gm-Message-State: AIkVDXLK4S5N7B6NL0WRwR5ZuV0LFdFx/VhFPpfzkiuJ9iyFW1oBse+Jq7aYZ3J5kmS4HSeA X-Received: by 10.176.81.97 with SMTP id f30mr10381162uaa.55.1484312216779; Fri, 13 Jan 2017 04:56:56 -0800 (PST) From: Adhemerval Zanella Subject: Re: Fix MIPS o32 posix_fadvise [committed] To: Joseph Myers References: <226e0f33-bae5-f2d1-013d-53fccede21b3@linaro.org> Cc: libc-alpha@sourceware.org Message-ID: <1637af6e-0355-4f1c-90e3-b677809c9693@linaro.org> Date: Fri, 13 Jan 2017 10:56:52 -0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: On 12/01/2017 12:08, Joseph Myers wrote: > On Thu, 12 Jan 2017, Adhemerval Zanella wrote: > >> Thanks for fixing it Joseph and I although I agree this fix should be the >> most straightforward one for 2.25, I would like to get back on it on 2.26. >> If arm behavior for posix_advise is not an outliner (as I wrongly supposed) >> I think we can incorporate it on generic code an get rid of both arch >> specific implementations. > > Note that at the syscall level ARM and MIPS are different; it's just using > __posix_fadvise64_l64 that works for both. > > ARM defines only __NR_arm_fadvise64_64. That syscall has permuted > arguments (__ASSUME_FADVISE64_64_6ARG defined in kernel-features.h for > ARM). kernel-features.h then defines __NR_fadvise64_64 to > __NR_arm_fadvise64_64 so that generic code can work for ARM. I suspect > the generic C version of posix_fadvise should work for ARM, given those > definitions and care about avoiding the alignment argument. (Why does > posix_fadvise64.c do > > #ifdef __ASSUME_FADVISE64_64_6ARG > int ret = INTERNAL_SYSCALL_CALL (fadvise64_64, err, fd, advise, > SYSCALL_LL64 (offset), SYSCALL_LL64 (len)); > #else > > with the alignment argument never used in that case, but posix_fadvise.c > do > > # ifdef __ASSUME_FADVISE64_64_6ARG > int ret = INTERNAL_SYSCALL_CALL (fadvise64_64, err, fd, advise, > __ALIGNMENT_ARG SYSCALL_LL (offset), > SYSCALL_LL (len)); > # else > > which does use an alignment argument with the same syscall and argument > order?) Indeed this __ALIGNMENT_ARG on posix_fadvise.c code for __NR_fadvise64_64 with __ASSUME_FADVISE64_64_6ARG seems wrong. We are not hitting it because no architecture actually uses this syscall issue option. On posix_fadvise.c powerpc32 will use the first option (__NR_fadvise64). Tile 32-bits will use the third, _NR_fadvise64_64 with __ASSUME_FADVISE64_64_NO_ALIGN, so a 6 argument call with advise as last argument. So with fix below, ARM can use the generic code since it will use the 2 option (__NR_fadvise64 with __ASSUME_FADVISE64_64_6ARG): > > MIPS defines only __NR_fadvise64, but it has the fadvise64_64 semantics > (and does not permute arguments, so uses a 7-argument syscall for o32). > To use generic C code for o32, you'd need to e.g. have a macro that says > to prefer fadvise64_64 to fadvise64 (and then define __NR_fadvise64_64 to > __NR_fadvise64 if not already defined, as done in posix_fadvise64.c). > The only missing ABI that defines __ASSUME_ALIGNED_REGISTER_PAIRS is mips32 and as you noted we can't use default code as is. I have a local patch that add this mips behaviour on posix_fadvise and I will send upstream. diff --git a/sysdeps/unix/sysv/linux/posix_fadvise.c b/sysdeps/unix/sysv/linux/posix_fadvise.c index 15d72d4..f3b5d22 100644 --- a/sysdeps/unix/sysv/linux/posix_fadvise.c +++ b/sysdeps/unix/sysv/linux/posix_fadvise.c @@ -46,8 +46,7 @@ posix_fadvise (int fd, off_t offset, off_t len, int advise) # else # ifdef __ASSUME_FADVISE64_64_6ARG int ret = INTERNAL_SYSCALL_CALL (fadvise64_64, err, fd, advise, - __ALIGNMENT_ARG SYSCALL_LL (offset), - SYSCALL_LL (len)); + SYSCALL_LL (offset), SYSCALL_LL (len)); # else # ifdef __ASSUME_FADVISE64_64_NO_ALIGN