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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C513BC433FE for ; Thu, 29 Sep 2022 23:22:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229502AbiI2XW0 (ORCPT ); Thu, 29 Sep 2022 19:22:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbiI2XWZ (ORCPT ); Thu, 29 Sep 2022 19:22:25 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37BC313D1CB for ; Thu, 29 Sep 2022 16:22:24 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id i15-20020a17090a4b8f00b0020073b4ac27so2715498pjh.3 for ; Thu, 29 Sep 2022 16:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=SlBvqIbtpL0VufXgwK7uhVH38JuonCmEli0InnRVEwc=; b=WuAt0WRwYyROULHsLoKuJv2kXZVaCxvv5se5SYxucmOEgMFUNx2D57LgdDwCei2x1H BHZJk6cnqMJ9lpHSGjIAQZn0y8BmTQuG82WIZcNgoFeD7LG4pqgoDjfwNUvpxX0kJLxv Dw+WsZzJyUYdaQkT0re+VcE6b51zajqB6Pihs0d5Dm06lt/3y15zlDRlEVhaJYcITjqq kxupICcV/19shZioX2psCPJiZdpZ4ysq5/1T3jM0Xx0pSi+GIDFyiPzVO05s6m98CDTT tOo/5JDD8RVKU0DNuMgu6l56RXQ8C5tSDlMssCXWcmrz1Q8KJiW+10QJLFQH8nbm/WCu b7Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=SlBvqIbtpL0VufXgwK7uhVH38JuonCmEli0InnRVEwc=; b=ILsGIudqb41ZSA/+vMv5DFDioWb4XHB7nC+65GwxwAOv1RDqyF8B4GLhDf8PmXr6kP OOHpL5Y34ajgiHPp+z87ZTMDeNfa1rM6OEPLjWAIfX8anj/XBwy2xCXyS3rVLpBADzdb 0RgcTcS6t/ienBluFUx0c8E2VEInzNpeimT8z7HUH9PcGHdOxCzy4txUNzShfygUWYst o6mJ2MGGyI0hTosKP62UPpzFKd0LKXgnnXKvbZucrl2qE24wrY8EO30OQ4ZjvwG0nqgD IA9llYBR6nM2CumhELpHqBjEgkuNtbz4oqN0aJAZL1Df3brjr0BUvHiT6YXrn+Aj1FP0 EUpw== X-Gm-Message-State: ACrzQf3q/6MP1iBtJ/8W0PTtQlzV12ieblKMCUqjH7HfLVJ2rQ8Ty0nf U1g8TMNNjFJ+Z9l188EXhHe03w== X-Google-Smtp-Source: AMsMyM75zZcPQQjlBQckiGdn+LExa+Ehm1TbE+ovPavYyibrIT8X85CNF5p+NDaTg0PkeD+6UnKilA== X-Received: by 2002:a17:90b:1d81:b0:205:f381:7372 with SMTP id pf1-20020a17090b1d8100b00205f3817372mr11503541pjb.165.1664493743484; Thu, 29 Sep 2022 16:22:23 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id g11-20020a17090a290b00b001f319e9b9e5sm4062149pjd.16.2022.09.29.16.22.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 16:22:22 -0700 (PDT) Date: Thu, 29 Sep 2022 23:22:19 +0000 From: Sean Christopherson To: Isaku Yamahata Cc: Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v8 2/8] KVM: Extend the memslot to support fd-based private memory Message-ID: References: <20220915142913.2213336-1-chao.p.peng@linux.intel.com> <20220915142913.2213336-3-chao.p.peng@linux.intel.com> <20220929224516.GA2260388@ls.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220929224516.GA2260388@ls.amr.corp.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Thu, Sep 29, 2022, Isaku Yamahata wrote: > On Thu, Sep 15, 2022 at 10:29:07PM +0800, > Chao Peng wrote: > > @@ -4645,14 +4672,20 @@ static long kvm_vm_ioctl(struct file *filp, > > break; > > } > > case KVM_SET_USER_MEMORY_REGION: { > > - struct kvm_userspace_memory_region kvm_userspace_mem; > > + struct kvm_user_mem_region mem; > > + unsigned long size = sizeof(struct kvm_userspace_memory_region); > > + > > + kvm_sanity_check_user_mem_region_alias(); > > > > r = -EFAULT; > > - if (copy_from_user(&kvm_userspace_mem, argp, > > - sizeof(kvm_userspace_mem))) > > + if (copy_from_user(&mem, argp, size); > > + goto out; > > + > > + r = -EINVAL; > > + if (mem.flags & KVM_MEM_PRIVATE) > > goto out; > > Nit: It's better to check if padding is zero. Maybe rename it to reserved. > > + if (mem.pad1 || memchr_inv(mem.pad2, 0, sizeof(mem.pad2))) > + goto out; No need, KVM has more or less settled on using flags instead "reserving" bytes. E.g. if/when another fancy feature comes along, we'll add another KVM_MEM_XYZ and only consume the relevant fields when the flag is set. Reserving bytes doesn't work very well because it assumes that '0' is an invalid value, e.g. if the future expansion is for a non-private file descriptor, then we'd need a new flag even if KVM reserved bytes since fd=0 is valid. The only reason to bother with pad2[14] at this time is to avoid having to define yet another struct if/when the struct needs to expand again. The struct definition will still need to be changed, but at least we won't end up with struct kvm_userspace_memory_region_really_extended.