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=-3.8 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 01138C433E7 for ; Fri, 28 Aug 2020 20:15:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D55C1206FA for ; Fri, 28 Aug 2020 20:15:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726798AbgH1UPp (ORCPT ); Fri, 28 Aug 2020 16:15:45 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:48187 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726146AbgH1UPn (ORCPT ); Fri, 28 Aug 2020 16:15:43 -0400 Received: from mail-qk1-f175.google.com ([209.85.222.175]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MS43X-1k0w3a1rdj-00TU2H; Fri, 28 Aug 2020 22:15:41 +0200 Received: by mail-qk1-f175.google.com with SMTP id g72so204338qke.8; Fri, 28 Aug 2020 13:15:41 -0700 (PDT) X-Gm-Message-State: AOAM5331iSCAYRtGmzgu+rq3Lq2kDdtGxdGldSh7WOtPnW/VNRPyAgqC boaVuzk+1UouW8HWvJ8PblfeaOVw4CCZCClGYEI= X-Google-Smtp-Source: ABdhPJyFxFIv+GcJZpKlS+lPDRy1qPULULsQ3S/m8TXtBVzsR15m6l0uoJmkbm1MsalFQvPRw8Dsa1/8I63jaxHy9uo= X-Received: by 2002:a37:a04b:: with SMTP id j72mr892253qke.352.1598645740122; Fri, 28 Aug 2020 13:15:40 -0700 (PDT) MIME-Version: 1.0 References: <20200622192900.22757-1-minchan@kernel.org> <20200622192900.22757-4-minchan@kernel.org> <9c339413-68c7-344e-dd01-327cb988d385@kernel.dk> In-Reply-To: From: Arnd Bergmann Date: Fri, 28 Aug 2020 22:15:24 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 3/4] mm/madvise: introduce process_madvise() syscall: an external memory hinting API To: Jens Axboe Cc: Minchan Kim , Andrew Morton , LKML , Christian Brauner , linux-mm , Linux API , Oleksandr Natalenko , 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, SeongJae Park , David Rientjes , Arjun Roy , Vlastimil Babka , Christian Brauner , Daniel Colascione , Kirill Tkhai , SeongJae Park , linux-man Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:nyLHj6ZpuzHpQ/Rd2Zu2ZXBe+DoHH8w3eBCH+32bWGdcQqn303K /toMw6tB1D0VEVbfcBpipXwuXza07IgVsiY6a1nX4T/okWht3ONmbaiWoBfg7WkLg2xDUo0 JnWfRr2eAG31Xl7tZ06m50/3gEY2iGyZoryyr0eupPi1V4KQ2qjC0XW6WpEvtKBsW0susOp VqSXHs4R2Ls4zQu7Tx70Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:7msRCAyRGig=:DAPNv7qMT9UJ8LGCCJMsYg i9VkG4C7kuFe9V9lQ3fFeZnp54+jORtKOSaBCTchQWjnHDeKFkuUYEQ7x5PC2R0dhgmpYTL8T EJvbZ27r4EC0qcpRs5T5E0Yi5ZVTXnylbdOiJ4pvNlOE8tmpeNOScD0oGM9wb0Tr1Tl78swol vdhL9izIxBzx1ebZ8hPHzR9YLRH6dAMGPiHwH0By7YLILRMJehpec+9PTfk6nNqx3mgQXYrU5 FkeQqdZBryVgG8qSEDEhKJAkNKuqlfB03zuc/Z/32p5lujRx4TkcBqvMLteb+I/0s8b1S6mXD MHY8AnS4yXtZjkB9R8nONJJTxVeqSNIFx/JwfyxQAI03sVpG7/Yne1/XPn81NAPev3PFgbONc McLl0MQNN9HpfyJbU1xj25suvPMsJMIMlbpn0EIH2N8cXlmE1eMTPwNiUcmZi11m5stcWqNYK aPn6YkJ3dLXgYIBNZ7bFwG2qH9N2uknSXE5i52zH2uZmq17QLVPksdSMWcHRxSNa+u4mkKpjI 0O8012W/3RBizbqFYxXUw1DcPjcvom2Aqqz4YJhmtFMxaVo9/xda/ofktyLGIJn+pS6jZzHFH Uh9q/WEHR8BAVtmsf9yFJzf0fbWQF7bvHLPZ4rG/0tt7jZjC5gZkeDUmFUGikTWRyiAGm9ycS nnS66N/IZ2S+rRYLrB30mqpON3X/cEhLNrWiOT/gyxVc/r2dhvpEA6ey5LnoKQiZaif9Pewuq 2YWb+9HmLgI0O7VWq0pRDui9KQiBwTigdT5wwg16wW7RxCELirjHu3IA+Q06fkVc9s+txrR63 xUVE7RIQp3aJ/tEZLVkT6+iSgfWn41SayDMenKgLpe+4Vo49iqU6Wsow03ny4rZEl+s5xFn Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 28, 2020 at 9:27 PM Jens Axboe wrote: > On 8/28/20 12:24 PM, Jens Axboe wrote: > >> @@ -1683,8 +1683,13 @@ ssize_t import_iovec(int type, const struct > >> iovec __user * uvector, > >> { > >> ssize_t n; > >> struct iovec *p; > >> - n = rw_copy_check_uvector(type, uvector, nr_segs, fast_segs, > >> - *iov, &p); > >> + > >> + if (in_compat_syscall()) > >> + n = compat_rw_copy_check_uvector(type, uvector, nr_segs, > >> + fast_segs, *iov, &p); > >> + else > >> + n = rw_copy_check_uvector(type, uvector, nr_segs, > >> + fast_segs, *iov, &p); > >> if (n < 0) { > >> if (p != *iov) > >> kfree(p); > > > > Doesn't work for the async case, where you want to be holding on to the > > allocated iovec. But in general I think it's a good helper for the sync > > case, which is by far the majority. > > Nevermind, I'm an idiot for reading this totally wrong. > I think you are right about the need to pick the compat vs native behavior based on req->ctx->compat instead of in_compat_syscall() inside of io_import_iovec(). That one can probably call a lower-level version and when all other callers get changed to calling ssize_t import_iovec(int type, const struct iovec __user * uvector, unsigned nr_segs, unsigned fast_segs, struct iovec **iov, struct iov_iter *i) { return __import_iovec(type, uvector, nr_segs, fast_segs, iov, i, in_compat_syscall()); } Arnd 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=-3.8 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 021DAC433E2 for ; Fri, 28 Aug 2020 20:15:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8B769206FA for ; Fri, 28 Aug 2020 20:15:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B769206FA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A4D406B0003; Fri, 28 Aug 2020 16:15:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FDB96B0005; Fri, 28 Aug 2020 16:15:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 914146B0006; Fri, 28 Aug 2020 16:15:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id 7B0806B0003 for ; Fri, 28 Aug 2020 16:15:44 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 44F7645B3 for ; Fri, 28 Aug 2020 20:15:44 +0000 (UTC) X-FDA: 77201083008.13.bikes13_4b0c13b27078 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 16FFC18140B60 for ; Fri, 28 Aug 2020 20:15:44 +0000 (UTC) X-HE-Tag: bikes13_4b0c13b27078 X-Filterd-Recvd-Size: 5897 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Fri, 28 Aug 2020 20:15:43 +0000 (UTC) Received: from mail-qk1-f178.google.com ([209.85.222.178]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPSA (Nemesis) id 1Mzz6m-1kZU8h2I2Y-00x0hk for ; Fri, 28 Aug 2020 22:15:41 +0200 Received: by mail-qk1-f178.google.com with SMTP id p2so744064qkj.5 for ; Fri, 28 Aug 2020 13:15:41 -0700 (PDT) X-Gm-Message-State: AOAM533wi1Nr8Qdo/rYKgrd7k6EvtsR1hJpR11dDQP6qYySHdoRT56uz 1gUc4URksrPzfDp7MfM/2DH6n8JEVNDlON8mHpY= X-Google-Smtp-Source: ABdhPJyFxFIv+GcJZpKlS+lPDRy1qPULULsQ3S/m8TXtBVzsR15m6l0uoJmkbm1MsalFQvPRw8Dsa1/8I63jaxHy9uo= X-Received: by 2002:a37:a04b:: with SMTP id j72mr892253qke.352.1598645740122; Fri, 28 Aug 2020 13:15:40 -0700 (PDT) MIME-Version: 1.0 References: <20200622192900.22757-1-minchan@kernel.org> <20200622192900.22757-4-minchan@kernel.org> <9c339413-68c7-344e-dd01-327cb988d385@kernel.dk> In-Reply-To: From: Arnd Bergmann Date: Fri, 28 Aug 2020 22:15:24 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 3/4] mm/madvise: introduce process_madvise() syscall: an external memory hinting API To: Jens Axboe Cc: Minchan Kim , Andrew Morton , LKML , Christian Brauner , linux-mm , Linux API , Oleksandr Natalenko , 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, SeongJae Park , David Rientjes , Arjun Roy , Vlastimil Babka , Christian Brauner , Daniel Colascione , Kirill Tkhai , SeongJae Park , linux-man Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:P7Uk6vM3Ljw7SwT3X679MflsMcGqbbLt5Hok3zPc10BZinqJmdm nFhXJQxAkB8RFTaurBQoTaqLH6IhERTdl+xq0ZIh3CLz5KTTGIYlzupNapovQDc5tlRI/xW cbPaP3kIxq3A9v4w8e3p3+sBKO4iIp6G91uMVBmuTMUILyPrsSDiAv/Hmesz0/5cTVw8JyF IuvnTXqhCo4h7vcnpUKKQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:m3g0EkaMpTE=:iY42Z1jOzqEPYEfMaaDwoz BLd3J4PQtoSQhFTj0nGamQr2GogFUR/8qLFFpyg//gDBhV8VK2B82rTMn9jC1/Im1LclMcBit CVQSDVptKYuMlRLSp6787SK42K7UkGdMYtBxbYXEvEQVvlEg4Aca33R+MieyYN9lYBGi5cZrU Kg5rxYzyypKVc/3BaLHKm3ph7jend3QTRe4yreaBhZ732/Kyv+1y23orzmyTQ45lTnviVfJ7L XJzL17kx8ZFf0/75o7UQePU+GMKCyyIQ8EYSQ6+C5wUtNCiq1NRa+vP9ye9/1PUr2kAEXW8TW llhC03rV94bw0X7E0kY7skwNHxMJ3y5QMWXlyQ5+82323uvaNhRmvz9WHSSUbjTg8uIxTbCO/ 5xlYG3bRQQlhsmwaYe7hhR87vNIGpQfOlyZtUBUNYq7br6tKxUzeU62qu4OAXvFZGk+ciCDMw 1YGY75XAycaZJaMGa9n2wLiWe8iEhgLFjR5pfho6J9mxff6zuba8GpmAWTtTgtZPxUBtruVgE Px0DYzh+d/ZNSfWjLGFzajDcCUzH0dB6CSxvBZxq339ckn9ZuPHPS4Z80YneJeTdK1WbvbNzu LDrucD/i9f3Oc5SJYfTHFLBxrskkkKlu12akkqBvzFKXgCCWCkFV0mZZeatVZwUV/HFL27wXs OLRWD36XfYORVYaefKkeO98/beKQh426IjW5bkYt/bcE5WfjaHws+4jQRN2XPmcWNzbb5lpJA D2rq/ph+aBf8NGIVf34+gqzmVOp858uXYflIGfpzr5PXZe/iJjib623XVGdptFNZwDu19v/z8 Mfj24A1IA8186WESqo/wDo5/XGPA2YT+AQfLwUb+JkxuwXH+gCddI0ly9Nc1cPmsV5/GjQ6Fe 64Lwk+BInOq0JYHQcGRTq78Y35UxTjTxFmPyFsQy4U+R9mnYxns5MPWVzxzJ41fHRs6lnNLO8 fY4oE21xKEqGtxtVBWTHNt70iKgXwNi+tVX2GyLaDAy+XQYOawgEN X-Rspamd-Queue-Id: 16FFC18140B60 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Fri, Aug 28, 2020 at 9:27 PM Jens Axboe wrote: > On 8/28/20 12:24 PM, Jens Axboe wrote: > >> @@ -1683,8 +1683,13 @@ ssize_t import_iovec(int type, const struct > >> iovec __user * uvector, > >> { > >> ssize_t n; > >> struct iovec *p; > >> - n = rw_copy_check_uvector(type, uvector, nr_segs, fast_segs, > >> - *iov, &p); > >> + > >> + if (in_compat_syscall()) > >> + n = compat_rw_copy_check_uvector(type, uvector, nr_segs, > >> + fast_segs, *iov, &p); > >> + else > >> + n = rw_copy_check_uvector(type, uvector, nr_segs, > >> + fast_segs, *iov, &p); > >> if (n < 0) { > >> if (p != *iov) > >> kfree(p); > > > > Doesn't work for the async case, where you want to be holding on to the > > allocated iovec. But in general I think it's a good helper for the sync > > case, which is by far the majority. > > Nevermind, I'm an idiot for reading this totally wrong. > I think you are right about the need to pick the compat vs native behavior based on req->ctx->compat instead of in_compat_syscall() inside of io_import_iovec(). That one can probably call a lower-level version and when all other callers get changed to calling ssize_t import_iovec(int type, const struct iovec __user * uvector, unsigned nr_segs, unsigned fast_segs, struct iovec **iov, struct iov_iter *i) { return __import_iovec(type, uvector, nr_segs, fast_segs, iov, i, in_compat_syscall()); } Arnd