From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113605 invoked by alias); 1 Jun 2018 21:48:42 -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 113588 invoked by uid 89); 1 Jun 2018 21:48:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=suspend X-HELO: mail-qt0-f196.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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=byI32D+O1zZ95SrwyI+y8guThcRnOKjqR4nnDg5vGnw=; b=a+We02MSy7WkHZU6da9F2fd48QWxTBur/BPFpmtLNek3fsyscocA0vlnEEmM6k4uzq WIPOWA6amsmQXnMRbvE4mD3abzvYal1ULBDN4XwtY2rdIRpXuTlXGzxG0NIXZzMfBdhL gOUBx2iFS096pyoFluoQggOV+Dd0GDPP/hG9ESATln2RLRZWyaMeV9A4GmYhS2PHFgHU iSzc2pTWlnnfL0qlsVQ2DqXW84SnP54IyOPaWsGlQAqkyTBgKmmcQnmUcukrIU9y3Rz+ 3QJLs+iNmAHRMkt+nev6HzvL3T5D2YSihVRqaHqe9h+xt2nrmXKTHCfeEj5cr4y+n4Jd EFPw== X-Gm-Message-State: APt69E1JRUcbWvCjwA5IozAgUWoZOW0Xw8Fia7AigTJIzRbAe3mdYqSz 2WjjzcSsN8xcMWSGzBUYNNK5k15yvuY= X-Google-Smtp-Source: ADUXVKIqR8nffJWdy96pCS9PPaXSvZiT+uIQrSVgPfLIzhi5/FrqrhaOGrvIrPm68cLdWs0jc6/Xjw== X-Received: by 2002:ac8:164d:: with SMTP id x13-v6mr7868013qtk.378.1527889718539; Fri, 01 Jun 2018 14:48:38 -0700 (PDT) Subject: Re: [PATCH] Fix Linux fcntl OFD locks for non-LFS architectures (BZ#20251) To: Florian Weimer , libc-alpha@sourceware.org References: <1522877210-27934-1-git-send-email-adhemerval.zanella@linaro.org> <36d1d0db-8661-5476-7e42-1a7015f4c766@redhat.com> <20db2200-24d5-fc2d-1b30-ce5b274ff5a6@redhat.com> From: Adhemerval Zanella Openpgp: preference=signencrypt Message-ID: Date: Fri, 01 Jun 2018 21:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20db2200-24d5-fc2d-1b30-ce5b274ff5a6@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-06/txt/msg00023.txt.bz2 On 01/06/2018 18:07, Florian Weimer wrote: > On 06/01/2018 10:38 PM, Adhemerval Zanella wrote: >>> I think you should mention somewhere that this introduces new cancellation points. > >> It is not really new, since for architectures with default LFS support this is >> transparent and for architectures with non-default LFS my understanding is >> functions with *64 suffix are expected to handle cancellation as the non-LFS. > > The old condition was: > > -  if (cmd == F_SETLKW || cmd == F_SETLKW64) > -    return SYSCALL_CANCEL (fcntl64, fd, cmd, (void *) arg); > > The new code calls SYSCALL_CANCEL for many more cases, some of which probably are bugs. Indeed the F_{OFD}_GETLK* case is not the case for cancellation (since the lock won't be enforced by kernel). My understanding is both POSIX and Linux OFD locks have similar code path which may suspend process execution (the case for cancellation syscall). Do you have any reservation about making F_OFD_GETLK a cancellation entrypoint as well? > > I'm also a bit worried about this: > > +      case F_GETLK64: > +      case F_OFD_GETLK: > +    { > +      struct flock *flk = (struct flock *) arg; > +      struct flock64 flk64 = > +      { > +        .l_type = flk->l_type, > +        .l_whence = flk->l_whence, > +        .l_start = flk->l_start, > +        .l_len = flk->l_len, > +        .l_pid = flk->l_pid > +      }; > > Should we really perform translation for F_GETLK64?  That looks like a bug. My understanding is Linux expects a 'struct flock64' for both F_OFD_GETLK and F_GETLK64 (fs/fcntl.c:493) and with the patch fcntl on non-LFS mode will only be called with 'struct fcntl'. So we need to transform to avoid the same issue as for OFD locks.