From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F410EC28E83 for ; Fri, 4 Sep 2020 09:36:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B67A4207EA for ; Fri, 4 Sep 2020 09:36:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B67A4207EA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 41F5E6B0002; Fri, 4 Sep 2020 05:36:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D0BD6B0003; Fri, 4 Sep 2020 05:36:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BFA76B005A; Fri, 4 Sep 2020 05:36:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id 120B46B0002 for ; Fri, 4 Sep 2020 05:36:38 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BF6978245578 for ; Fri, 4 Sep 2020 09:36:37 +0000 (UTC) X-FDA: 77224874034.16.walk77_2501459270b1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 93724100E7FD6 for ; Fri, 4 Sep 2020 09:36:37 +0000 (UTC) X-HE-Tag: walk77_2501459270b1 X-Filterd-Recvd-Size: 3760 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Sep 2020 09:36:37 +0000 (UTC) Received: from ip5f5af70b.dynamic.kabel-deutschland.de ([95.90.247.11] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kE890-0006Sg-0v; Fri, 04 Sep 2020 09:36:30 +0000 Date: Fri, 4 Sep 2020 11:36:27 +0200 From: Christian Brauner To: Minchan Kim Cc: Florian Weimer , Andrew Morton , LKML , linux-mm , linux-api@vger.kernel.org, oleksandr@redhat.com, Suren Baghdasaryan , Tim Murray , Sandeep Patil , Sonny Rao , Brian Geffon , Michal Hocko , Johannes Weiner , Shakeel Butt , John Dias , Joel Fernandes , Jann Horn , alexander.h.duyck@linux.intel.com, sj38.park@gmail.com, David Rientjes , Arjun Roy , Linus Torvalds , Vlastimil Babka , Christian Brauner , Daniel Colascione , Jens Axboe , Kirill Tkhai , SeongJae Park , linux-man@vger.kernel.org Subject: Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API Message-ID: <20200904093627.vj6t6q5spicfyonh@wittgenstein> References: <20200901000633.1920247-1-minchan@kernel.org> <20200901000633.1920247-4-minchan@kernel.org> <87blippc7p.fsf@mid.deneb.enyo.de> <20200903172618.GB1959033@google.com> <87pn72lq65.fsf@mid.deneb.enyo.de> <20200903175949.GC1959033@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200903175949.GC1959033@google.com> X-Rspamd-Queue-Id: 93724100E7FD6 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Sep 03, 2020 at 10:59:49AM -0700, Minchan Kim wrote: > On Thu, Sep 03, 2020 at 07:34:58PM +0200, Florian Weimer wrote: > > * Minchan Kim: > > > > > On Tue, Sep 01, 2020 at 08:46:02PM +0200, Florian Weimer wrote: > > >> * Minchan Kim: > > >> > > >> > ssize_t process_madvise(int pidfd, const struct iovec *iovec, > > >> > unsigned long vlen, int advice, unsigned int flags); > > >> > > >> size_t for vlen provides a clearer hint regarding the type of special > > >> treatment needed for ILP32 here (zero extension, not changing the type > > >> to long long). > > >> > > > > > > All existing system calls using iove in Linux uses unsigned long so > > > I want to be consistent with them unless process_madvise need something > > > speicial. > > > > Userspace uses int, following POSIX (where applicable). There is no > > consistency to be had here. > > Okay, I changed it with size_t. Maybe some context helps. We had the discussion about syscall conventions during LPC both in the KernelSummit and in the glibc toolchain session and one of wishlist conventions from libc was to always use size_t and not unsigned long for sizes. I know this has been a little frustrating having to change types and so on for the syscall quite a bit but I'm going to start drafting an updated version of our howto for adding syscalls now so things like this are more transparent going forward. I just hadn't gotten around to it right after Plumbers. Christian