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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B026C64EC4 for ; Tue, 7 Mar 2023 01:20:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF8A8280001; Mon, 6 Mar 2023 20:20:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D81546B0074; Mon, 6 Mar 2023 20:20:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFAD2280001; Mon, 6 Mar 2023 20:20:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id ACBBC6B0073 for ; Mon, 6 Mar 2023 20:20:04 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0904716048D for ; Tue, 7 Mar 2023 01:20:03 +0000 (UTC) X-FDA: 80540345928.17.1DB6555 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 7937F1C0006 for ; Tue, 7 Mar 2023 01:20:01 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YGeRZmkt; spf=pass (imf20.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678152001; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8qrw2gr+qx7DWb3UAvdR/mcFIQhqsDgcX3EEuLph/d4=; b=OU584Zi+WXaae/Vsu8NcBzZqTDmfqnzIUnoADU6+jpr6iZU4fs0Jn+ldZvPleLcKtpCxCn Lhca7I4F7eNIMr611f2q6oxq1zaVriknGWoT4ZkUt6msB1HMSSlNkuHGOkUzcsH7eyacsb tTWLfugraIjbtwLrN+zzuz/6DFiM2v0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YGeRZmkt; spf=pass (imf20.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678152001; a=rsa-sha256; cv=none; b=lzyYyJMdJ+fUGm2CwfRUyxpGscb+RtqP8Vwa7OgymgR0aoYIGGLLauKZphcCvFoWIxrcqY 9DIZ1a6AWAZSL56jRFlIte3ljkmBbTcQyU7bjt3BBz2PiAQpZz7i/A/Lx8Afjiz19ulQZn keerKR68tkgRNfI1o0G229TAU4fb15I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678152000; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8qrw2gr+qx7DWb3UAvdR/mcFIQhqsDgcX3EEuLph/d4=; b=YGeRZmkt7KTnmfz0mjbJg7dpkGGflmQPQEwP2U3RoDgEjIjwDq0sLFrNl/L7jawKbGyXou V/6djRUqTh2s2HMDxNwPuIjMLaHKe3raP6r1IJM8xkLeV0l0KetebFhABURHHI+jCl+WuW jnYMOIKpJfBAGU5cG3HgDeHdp2u2vX4= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-491-bQuWbXUXMZWndIxSod7egw-1; Mon, 06 Mar 2023 20:19:59 -0500 X-MC-Unique: bQuWbXUXMZWndIxSod7egw-1 Received: by mail-qv1-f71.google.com with SMTP id e9-20020a0cf749000000b00571f1377451so6669018qvo.2 for ; Mon, 06 Mar 2023 17:19:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678151999; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8qrw2gr+qx7DWb3UAvdR/mcFIQhqsDgcX3EEuLph/d4=; b=sl3yQzlh1E4C0fPA5mzhjiGI8F5o04s/uf0Ekr8NwXckdY8lWZ3OLZqg/qGlfSVGY2 /3uh2pV8ZdJCKuPwY+AuPk0P1J9Zdb88uDQZACuNDxIdxZZnfNqvH72i54dnVPyWdeed XZjZvhuZXHygSJR1uuKmHlPqesaB6cyVjcQsbthymZdhnul+pVJmH6AmxwmOmWe39B8/ pIgzAVRzq8HYVy/xjVlTXO7nuqTQhWvDtoovFEBCGkAnRT04jTr+1xXx4fWPMDLQdMiP E0GhLzKXNP40dtR9ulWA4/5fqfhr9xIuI/Is9WpEwnyWvI5jqsrf8BzGEehsfnMLadHn Xpfw== X-Gm-Message-State: AO0yUKWa7m6kQkKGXpW0vg4tWTTFfw6PngwP59xQ76rCrW5jBPGy/03m U2jvfzClIiJgviL/kikrSLC4fsmYOaZ8aFv12l14pDWuafI7hTmVAlaPlczjEU+pAqTi4sjXAwt R3E8VP1yV7vo= X-Received: by 2002:ac8:7d12:0:b0:3bf:d71e:5b08 with SMTP id g18-20020ac87d12000000b003bfd71e5b08mr25643232qtb.3.1678151999079; Mon, 06 Mar 2023 17:19:59 -0800 (PST) X-Google-Smtp-Source: AK7set+YPHN/ncr0Du5Ek2aNycnO04K6K6elfomWX85YMAJoHPLqYfwEiEIk3YRAWh/HHoBKpUm+sw== X-Received: by 2002:ac8:7d12:0:b0:3bf:d71e:5b08 with SMTP id g18-20020ac87d12000000b003bfd71e5b08mr25643186qtb.3.1678151998762; Mon, 06 Mar 2023 17:19:58 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-56-70-30-145-63.dsl.bell.ca. [70.30.145.63]) by smtp.gmail.com with ESMTPSA id j11-20020a05622a038b00b003bd0f0b26b0sm8855311qtx.77.2023.03.06.17.19.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Mar 2023 17:19:58 -0800 (PST) Date: Mon, 6 Mar 2023 20:19:56 -0500 From: Peter Xu To: Axel Rasmussen Cc: Alexander Viro , Andrew Morton , Hugh Dickins , Jan Kara , "Liam R. Howlett" , Matthew Wilcox , Mike Kravetz , Mike Rapoport , Muchun Song , Nadav Amit , Shuah Khan , James Houghton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v3 4/5] mm: userfaultfd: don't separate addr + len arguments Message-ID: References: <20230306225024.264858-1-axelrasmussen@google.com> <20230306225024.264858-5-axelrasmussen@google.com> MIME-Version: 1.0 In-Reply-To: <20230306225024.264858-5-axelrasmussen@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 7937F1C0006 X-Stat-Signature: 5f8s33wk5icn4akuyugeyf3gkk69m5nk X-Rspam-User: X-HE-Tag: 1678152001-702501 X-HE-Meta: U2FsdGVkX1/1asbTc3710emfO+SN5f2+nZhRfSuiWp+MR0ppnYmFP3V5kYCPvpIoAWaNhroaoysOaz1PV41xkAhbBNGfLcacC1JDZkHBoWuCD+F2Bx5uhAIrf6lBpi6lZLZ3NucMYgOs3rQH43wZJWA6QFpVUPszWoujM0Dw7CMhGwp91TKK4839bAJSWKx8pQr38pb+S1vXxVNbJlRB31vYHZa5MjaA93D+GzJtUkHU2s0cYeV59lm+4Brk2Lnxb6PHEn60UsUmbzmVnCck9BF3YVklL2haaRN4S34AKY9W1TU9iMgnIAQ3u6UKkFlZt+7sJGQJrTpKGoDBff69+O6MKRqiLQuoETrW0hmaw/hENwtwl3SPCmOL+XyFNKiDwWjJ2h3RPmNdT+jJZBoF1pVB+WK0+V+xe5oZi7Fql1UDjeMxC5fDNiUI/g/F2z6v0tNUSRPGS0a8MW+FlaJ+wumVc85sZpC6yFTxd+5zyyr9qPDfFUCGsBCkLSNcaSYijkpDfNckgnyAAw17YYhqzc7Oh8qIyBAwfOQGN6eJvG1oy1bZvnBD82+jfVJtmWHXeZN4CbAg6dIhyjlQDI6OYff6yNgpbvKrtGhfM+M3DAZi91gi+DSGDb5j22N8j3v3AleNsxMn8kMusGcFQA0tWmYTJG4h/bAoVeRwCFfzF2y5BnPeVV2Y0WBsknJADOgwZRiGZr8tPMFBCBc+CrZ5HwBFMYIIUDv3Lk063Bh1Ive1VZH1L/QlAjBCsgWrSyClWe6CLUjnRAWNXGgfpTX8hPAJVcCYet/d4BEaaD6XKhKp4BFar5z5YnyWGM0Zhctk3+cI7zIXWR2j9W+yxOZQP6Nlw1IjQV5uoyXV7JBnpWLX4NEri+sHvz1Opep0TD7f/A2/O8jGuHu9azE4gWkDCDg45P53WEHDdS7w8lfoH3/6xevlsBjA2k1BvUuDpsKGoVmffJJT8lBrwURHY78 zV/P7dT9 pU1Qi4xXbvFTK9+gbtBC7XQ3DzHnuBK/LblXm7dUCIxlfqQBsXDXAZiI2Vt4SCrqNJFLgIXiQpRnaGvBs3UptH743CeEPu1OvgSrhkyYR1PYvdpzp5bEgg1lE8B1Q7fQtnq4qsRBNfXNdqgHJ3Rt7mM2nvL/23ZpkxxyMHB/Wr+KIf8fwqO9NG59+pgLwx37T98UaYvXOKcd6iFcwYQXUuXL8AADaYOhqyXIxkSTDuPuH0Bfx/xkgaVeDiHvdQfCb8f2gmFn7OmFGUapkIUEkZGnnOlNG2cCp1CMTP+dhw4tVqEGd200D3lqrFeB6M3lT4OGN6RFK6CoW80IHBln8XrfP8Ia3t7DecmZepnRbtMJvvbu8lX8DLCy9Ef3Ys3SqP0Q05x31YjO+SnIEd5VGvYaVag== 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 Mon, Mar 06, 2023 at 02:50:23PM -0800, Axel Rasmussen wrote: > We have a lot of functions which take an address + length pair, > currently passed as separate arguments. However, in our userspace API we > already have struct uffdio_range, which is exactly this pair, and this > is what we get from userspace when ioctls are called. > > Instead of splitting the struct up into two separate arguments, just > plumb the struct through to the functions which use it (once we get to > the mfill_atomic_pte level, we're dealing with single (huge)pages, so we > don't need both parts). > > Relatedly, for waking, just re-use this existing structure instead of > defining a new "struct uffdio_wake_range". > > Signed-off-by: Axel Rasmussen > --- > fs/userfaultfd.c | 107 +++++++++++++--------------------- > include/linux/userfaultfd_k.h | 17 +++--- > mm/userfaultfd.c | 92 ++++++++++++++--------------- > 3 files changed, 96 insertions(+), 120 deletions(-) > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > index b8e328123b71..984b63b0fc75 100644 > --- a/fs/userfaultfd.c > +++ b/fs/userfaultfd.c > @@ -95,11 +95,6 @@ struct userfaultfd_wait_queue { > bool waken; > }; > > -struct userfaultfd_wake_range { > - unsigned long start; > - unsigned long len; > -}; Would there still be a difference on e.g. 32 bits systems? [...] > static __always_inline int validate_range(struct mm_struct *mm, > - __u64 start, __u64 len) > + const struct uffdio_range *range) > { > __u64 task_size = mm->task_size; > > - if (start & ~PAGE_MASK) > + if (range->start & ~PAGE_MASK) > return -EINVAL; > - if (len & ~PAGE_MASK) > + if (range->len & ~PAGE_MASK) > return -EINVAL; > - if (!len) > + if (!range->len) > return -EINVAL; > - if (start < mmap_min_addr) > + if (range->start < mmap_min_addr) > return -EINVAL; > - if (start >= task_size) > + if (range->start >= task_size) > return -EINVAL; > - if (len > task_size - start) > + if (range->len > task_size - range->start) > return -EINVAL; > return 0; > } Personally I don't like a lot on such a change. :( It avoids one parameter being passed over but it can add a lot indirections. Do you strongly suggest this? Shall we move on without this so to not block the last patch (which I assume is the one you're looking for)? Thanks, -- Peter Xu