Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 4 Sep 2020 11:36:27 +0200
From:   Christian Brauner <christian.brauner@ubuntu.com>
To:     Minchan Kim <minchan@kernel.org>
Cc:     Florian Weimer <fw@deneb.enyo.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-mm <linux-mm@kvack.org>, linux-api@vger.kernel.org,
        oleksandr@redhat.com, Suren Baghdasaryan <surenb@google.com>,
        Tim Murray <timmurray@google.com>,
        Sandeep Patil <sspatil@google.com>,
        Sonny Rao <sonnyrao@google.com>,
        Brian Geffon <bgeffon@google.com>,
        Michal Hocko <mhocko@suse.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Shakeel Butt <shakeelb@google.com>,
        John Dias <joaodias@google.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        Jann Horn <jannh@google.com>,
        alexander.h.duyck@linux.intel.com, sj38.park@gmail.com,
        David Rientjes <rientjes@google.com>,
        Arjun Roy <arjunroy@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        Christian Brauner <christian@brauner.io>,
        Daniel Colascione <dancol@google.com>,
        Jens Axboe <axboe@kernel.dk>,
        Kirill Tkhai <ktkhai@virtuozzo.com>,
        SeongJae Park <sjpark@amazon.de>, 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>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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