From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102136 invoked by alias); 28 Nov 2017 13:38:47 -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 102126 invoked by uid 89); 28 Nov 2017 13:38:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=HCc:U*mtk.manpages, Hx-languages-length:2649, 3 X-HELO: mail-qt0-f195.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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k/kiFGYPv3BBY1fhFFc22c1kDTQJ587ePofq4xrkgs8=; b=THlsCzMSzAHkLq/zWpZRBw0QnqAfR+avoyu7VxXTHYepJai3uBVYuiasvbZoiBJE5t wrs+3dIP/OSoGNmyjvpNwUE0MQdKFJYO2a8yytXUM3y9ePvUS0N4v7eRkYVEHVUovJaL m4+Y2uxZXouFbpZn8Zr37z2RaI3sVTfLr7lv8wLg2LyJLpg8UZajJDSrTQx5evMMBBxq ROzk4OcHoNboguMPp0L1AXjdjcQG7XHsRJRmLyJTVqUXIdAUarGZq1hSzKCyh6jBxUy7 L4qrbpsowkOg710lpcgLBDRfqOG1cO3mC//CN5e6JglETtm58susq1KoMsyY25KeQYel K+5Q== X-Gm-Message-State: AJaThX6Hivlzz7fq0HiJXRDzfEFQFBysuo3ZXbvv5uQjcAcLkLePNLVC cjc0j9l8Jm9C5fbXjo53oXsAiw== X-Google-Smtp-Source: AGs4zMY8CnjhvcOEBiP/AFVsN9bKbbMZa415s2rroHupHHZyaSSXJC0f5mTak2tZtnrsnEWCPYEQqQ== X-Received: by 10.237.47.228 with SMTP id m91mr66790360qtd.205.1511876322856; Tue, 28 Nov 2017 05:38:42 -0800 (PST) Subject: Re: [PATCH] Implement the mlock2 function To: Florian Weimer Cc: libc-alpha@sourceware.org, "Michael Kerrisk (man-pages)" References: <20171124165936.9CEC94071C775@oldenburg.str.redhat.com> <3abb0277-d721-c7f5-c19f-91cfdabb06a5@linaro.org> <63eee706-5b67-1b80-7a5c-df5e76d99d63@redhat.com> <61bf1cb7-a45d-0b61-3fcf-e0585901191d@linaro.org> <3fb3912f-a37b-00c5-195d-612cd915d71a@linaro.org> From: Adhemerval Zanella Message-ID: <02f06dd1-40b6-f2a4-2d3f-0d125f1032de@linaro.org> Date: Tue, 28 Nov 2017 13:38:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-11/txt/msg00968.txt.bz2 On 27/11/2017 16:46, Florian Weimer wrote: > On 11/27/2017 07:40 PM, Adhemerval Zanella wrote: >> >> >> On 27/11/2017 14:43, Florian Weimer wrote: >>> On 11/27/2017 05:35 PM, Adhemerval Zanella wrote: >>>> >>>> >>>> On 27/11/2017 14:07, Florian Weimer wrote: >>>>> On 11/27/2017 02:11 PM, Adhemerval Zanella wrote: >>>>>> This is a reasonable approach and I am ok with this patch with the >>>>>> INLINE_SYSCALL_CALL change. I wonder if it is worth to add a similar >>>>>> change to p{read,write}v2 to return ENOSUP in the case of ENOSYS. >>>>> >>>>> My copy of the manual page says that EINVAL is used there as well. >>>>> >>>>> Thanks, >>>>> Florian >>>> >>>> Indeed manpages [1] states that EINVAL is returned, but our documentation >>>> states otherwise: >>>> >>>> manual/llio.texi >>>> >>>> 1286 @item EOPNOTSUPP >>>> 1287 >>>> 1288 @c The default sysdeps/posix code will return it for any flags value >>>> 1289 @c different than 0. >>>> 1290 An unsupported @var{flags} was used. >>>> >>>> Also, "tst-preadvwritev" on a 4.13.0-17-generic indeed generates Linux >>>> EOPNOTSUPP (ENOSUP): >>>> >>>> [pid  7896] preadv2(3,  >>>> [pid  7895] <... rt_sigaction resumed> {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 >>>> [pid  7896] <... preadv2 resumed> [{iov_base=0x7ffca77846d0, iov_len=32}], 1, 0, 0x10 /* RWF_??? */) = -1 EOPNOTSUPP (Operation not supported) >>>> [pid  7895] wait4(7896,  >>>> [pid  7896] pwritev2(3, [{iov_base="\0\0\0\0\0\0\0\0\241H\363?\244\177\0\0@Gx\247\374\177\0\0\0\0\0\0\0\0\0\0", iov_len=32}], 1, 0, 0x10 /* RWF_??? */) = -1 EOPNOTSUPP (Operation not supported) >>>> >>>> So I think it would be worth to change p{read,write}v2 on GLIBC to >>>> return EINVAL for invalid flags. I will prepare a patch. >>>> >>>> [1] http://man7.org/linux/man-pages/man2/preadv2.2.html >>> >>> Typo?  Shouldn't we match the kernel behavior, so fail with EOPNOTSUPP? >> >> Not for ENOSYS. And I though about following manpages definition, but >> thinking twice I agree following the kernel would be better.  I still >> think it will be a small improvement to handle ENOSYS as ENOSUP as you >> did for mlock2 and EINVAL. > > Agreed: if you do zero-flag emulation using pwritev in user space, returning the kernel unknown flag used by pwritev2 (here: EOPNOTSUPP) when *any* non-zero flag is unknown by the kernel (because pwritev2 is not implemented) is the right approach. We are already doing the correct thing for p{read,write}v2: if ENOSYS is returned Linux implementation will return ENOTSUP for flags different than 0 otherwise call p{read,write}v.