Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp280305ybj; Fri, 8 May 2020 11:38:45 -0700 (PDT) X-Google-Smtp-Source: APiQypKpmYyf1mYlMWYR0DHl4kjsuMfbRooHqIQMYfLFxc9+0sPqIJXxxreCyLjbIMJ+C0pGl7ys X-Received: by 2002:aa7:d4cd:: with SMTP id t13mr3368153edr.30.1588963125143; Fri, 08 May 2020 11:38:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588963125; cv=none; d=google.com; s=arc-20160816; b=LVjSBclfgO1qzSw035ftDv8HhfACyd3jVle4MG0K20LnDYPWgflnbea+zEY3lYJg5n YbSA+dt0ez8kNH6BYcfBbomhUkv8nChkgyTzcSBx+UEuujSoJYmG9nCDttatheL5gPpp 9IFtEhnAoBO5pM7dtRaQ5Sf59koYrpgjsaTRM7IHXR4OWSx7Isy+Ho3qsz3hNga9JQvN ixDCpVRbDfEdH6Awt6/UeuAqcYiSRkRwq5ge8Y+/oYaybzy9KMalKBi0TKGJ8GlJ0N6T nkzyndiIefPccfoO6odYrjwGev6r0ErtOC+6SoJjY0KjexziglUkqyQlvhvy48dbGBZf 7gRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=DI4jr073qlq2kMXmJOvGcOhiGeUasYxQR1ZwT0O6BJc=; b=qtvPOOyq85s3VT0ieRer+amIl8k6b8/jhZm6Oru3caHT4FsknTHDWweDGKkLGLPz08 lf0EFIOveAV1/gHNs/icS9WIdgalC45HpdUqMIwpKQeCUD2GyFcHLUh16R/tqAiNEq9T WUzgOLCCKDNZYx4X6G35lmd+e9H4bH1HlRHWhzj7DyVE4ewnepzKsjtlmmuCYB2vhLY2 d96S2Xn3NaUeE/css/uEoCUrThwZ0tui8efq7ZaUrS9ufE7yZckv+ZuOabvdf75rqDSH bu0Zwl9yMafgo5dnHXp4WvMMjobcLDNX0rRopqEL0dK3luSm0Pq8tCR3SlNfqWNMGwR7 l0Eg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=e9phhNfq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x21si1362563ejc.141.2020.05.08.11.38.22; Fri, 08 May 2020 11:38:45 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=e9phhNfq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726863AbgEHSg6 (ORCPT + 99 others); Fri, 8 May 2020 14:36:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726636AbgEHSg5 (ORCPT ); Fri, 8 May 2020 14:36:57 -0400 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 840EFC061A0C; Fri, 8 May 2020 11:36:57 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id x10so1112721plr.4; Fri, 08 May 2020 11:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DI4jr073qlq2kMXmJOvGcOhiGeUasYxQR1ZwT0O6BJc=; b=e9phhNfqFy4SUFWgk2EkceTCIXKBpoo+T6gbLnaezV4G1B1/6lGhJ9ZcLZnuIelgrn Ql4cXp0/PLMBEjmnbd2PNYpKCM9yzKGC3CymbAKLYUct+zd+y/b8iq4Ky/HQZw9RQrIY xsTziG+UJ7AhftkBwChU8kc9ifBpNVlPOuwtpKv1eySwSaFBPFq5dJ4usA5J2F/H+v6m vktpsEvHDUu22Sy7Bu5cLx4TwMhNuNvPG0WBDsdtsVacNNxZmnxGqbJerhxm+TOunoDS 2wKFP/FJdInr5l49rJI1sh1qd9ISmsRyxCk2BCLIMDZe6Ql6K/PqU2ITpyvLxqk5XBUL Ta6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=DI4jr073qlq2kMXmJOvGcOhiGeUasYxQR1ZwT0O6BJc=; b=f6isCfWSyi9Kd4YVT5ux2+p7P+3FTj0DMqMYbIfio4asllNRa7tcKjvzXx+U8/iaKY yAsaoUgUIeSo0+ifG0w+yJ9+PtolSMjVhPzy3+kx1SIaCutexxjVvT/ONVznlEhNiRjq OFDbAbMYc8vnmyfV3Jxrq8X8myjfV3FMF7op1kiV225oSV3UhKHzzlq+eoNavbou+0LJ BSNm86J1MdFTjzqPKNtE0wmC0FAcfkKQIiH6txVgiHyCw/IdqKtIgpUj9UZwrMXoTuxb pIDX06UtRp+WBDj0TQaTWxfGMC4A6pHuAL8AqCJihhTDrO1NTjqlwmfZgKkmoxUann1t AguA== X-Gm-Message-State: AGi0PuYN7iVy8wRS+hAfzL5a7qJeLo8K2D5gmUnWm5gzf48+ecil3FKx gZPv32iOO6277oJUUFJcWuw= X-Received: by 2002:a17:902:4c:: with SMTP id 70mr3617494pla.336.1588963016739; Fri, 08 May 2020 11:36:56 -0700 (PDT) Received: from google.com ([2620:15c:211:1:3e01:2939:5992:52da]) by smtp.gmail.com with ESMTPSA id mn1sm2880315pjb.24.2020.05.08.11.36.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2020 11:36:55 -0700 (PDT) Date: Fri, 8 May 2020 11:36:53 -0700 From: Minchan Kim To: Vlastimil Babka Cc: Andrew Morton , LKML , linux-mm , linux-api@vger.kernel.org, oleksandr@redhat.com, Suren Baghdasaryan , Tim Murray , Daniel Colascione , 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, Christian Brauner , Kirill Tkhai Subject: Re: [PATCH v7 5/7] mm: support both pid and pidfd for process_madvise Message-ID: <20200508183653.GB125527@google.com> References: <20200302193630.68771-1-minchan@kernel.org> <20200302193630.68771-6-minchan@kernel.org> <14089609-5fb1-b082-716f-c2e129d27c48@suse.cz> <20200311004251.GB87930@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200311004251.GB87930@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 10, 2020 at 05:42:51PM -0700, Minchan Kim wrote: > On Fri, Mar 06, 2020 at 12:14:19PM +0100, Vlastimil Babka wrote: > > On 3/2/20 8:36 PM, Minchan Kim wrote: > > > There is a demand[1] to support pid as well pidfd for process_madvise > > > to reduce unnecessary syscall to get pidfd if the user has control of > > > the target process(ie, they could guarantee the process is not gone > > > or pid is not reused). > > > > > > This patch aims for supporting both options like waitid(2). So, the > > > syscall is currently, > > > > > > int process_madvise(int which, pid_t pid, void *addr, > > > size_t length, int advise, unsigned long flag); > > > > This is again halfway between kernel and userspace description, so if we stick > > to userspace then it's: > > > > int process_madvise(idtype_t idtype, id_t id, void *addr, > > size_t length, int advice, unsigned long flags); > > Yub. > Hi Andrew, Per Vlastimil's request, I changed "which and advise" with "idtype and advice" in function prototype of description. Could you replace the part in the description? Code is never changed. Thanks. From f11cfd023746ae67b89f2d84d960706ba6c5c911 Mon Sep 17 00:00:00 2001 From: Minchan Kim Date: Wed, 6 May 2020 13:54:40 +0000 Subject: [PATCH] mm/madvise: support both pid and pidfd for process_madvise There is a demand[1] to support pid as well pidfd for process_madvise to reduce unnecessary syscall to get pidfd if the user has control of the target process(ie, they could guarantee the process is not gone or pid is not reused). This patch aims for supporting both options like waitid(2). So, the syscall is currently, int process_madvise(idtype_t idtype, id_t id, void *addr, size_t length, int advice, unsigned long flags); @which is actually idtype_t for userspace libray and currently, it supports P_PID and P_PIDFD. [1] https://lore.kernel.org/linux-mm/9d849087-3359-c4ab-fbec-859e8186c509@virtuozzo.com/ Link: http://lkml.kernel.org/r/20200302193630.68771-6-minchan@kernel.org Signed-off-by: Minchan Kim Suggested-by: Kirill Tkhai Reviewed-by: Suren Baghdasaryan Reviewed-by: Vlastimil Babka Cc: Christian Brauner Cc: Alexander Duyck Cc: Brian Geffon Cc: Daniel Colascione Cc: Jann Horn Cc: Jens Axboe Cc: Joel Fernandes Cc: Johannes Weiner Cc: John Dias Cc: Michal Hocko Cc: Oleksandr Natalenko Cc: Sandeep Patil Cc: SeongJae Park Cc: SeongJae Park Cc: Shakeel Butt Cc: Sonny Rao Cc: Tim Murray Cc: Signed-off-by: Andrew Morton