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 EF738C4332F for ; Thu, 29 Sep 2022 23:22:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229652AbiI2XW3 (ORCPT ); Thu, 29 Sep 2022 19:22:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbiI2XW1 (ORCPT ); Thu, 29 Sep 2022 19:22:27 -0400 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37C4D13D1CE for ; Thu, 29 Sep 2022 16:22:24 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id g1-20020a17090a708100b00203c1c66ae3so2720431pjk.2 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=JSwKqIR/QnT7aTnjYI0v0NftCleMgtRwSOMXOcIi6ZyWejcZ0Qkwb8Dn2fLQkuN3Mp AiGgxTC9re5i2YJ5nYqW0HuwWESvUBUZnkZeuhr6l7G9prN+AzxrRSiI0u9zwQ3WGLfw LBVCbLz+sHxlE9bYNou6IGzsCb4g2IGvAyl7uSSF1ynzfdwxRDZmj+CjI8QXsLRnG3sZ fDch4LmA9CsS6uXu9rLYa/ONgsgRt1vZfkP7314E6bUu3jhw2RwRDm6O/tiby4PUUTKT I0tQwlGb0BJEwbksM2++8jhns85huc4Jnm5ibi7IcpZ//y+w+7FSftrYWDia9aYXD9MC cYdQ== X-Gm-Message-State: ACrzQf3yG4jJ5Z4jV7llkvOfgmk5DpUx4KrCGWgvNmFxSG6j7X+mRwkT QIiXRJXHHnTp+TcCDj1oJYXa25yhNCDz0A== 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-kernel@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.