Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp432901pxt; Thu, 12 Aug 2021 01:44:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmnEyN+3whlg0abvXlbfmlx4axGzTQ8NNXBgcx/x+djlcjdlSMzkGdJibqQDDvRZbqaR+C X-Received: by 2002:a05:6402:cb7:: with SMTP id cn23mr4098453edb.82.1628757848713; Thu, 12 Aug 2021 01:44:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628757848; cv=none; d=google.com; s=arc-20160816; b=m0nw8LCk/toJ6HBpmm38vjguD6/kl97g5XN704acq+RUs2BYw9o6PNjXmkVAJMktjT imdI3tW+fKuwGXeWExBlKzg1V7yGdktCCbj4+llzzHBMRG448IE/71oTjHTgtTY6OyO2 /GLwl51m7fzYrHAAzzaSJAFU6AHdqmFPZsCk9uYsKBPRZwb8sKx3F84qVUrtvgGqEBi0 2ufyR6lGuKz3i9pDMJ63AP7H/tmy1uqHgutDy7POvbpogWpmu9qbZ4QEiLMMdhw/wpzD Q/4UPQaeEESoCJvMVlmo5y1eycqxllw9MO8ObDoE8idkcIiMPnCgXgygun2F5zWEmS7R 00Sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=+nfS8qOmyfIYA2Mf0aXHVt9ATNP8lz9AMeYrHpMK/5s=; b=IpxR+ARzAOBJeK0INfQzkBvYl9W75VQhVjgFVwZOpeb5/iMuskl0QT3GWtGXiqPLdC I760TAjeD8Pxex8WmmFrwqnfC195fdN1fIo8qNce6fNq67kIWOOmmlIOOvydwv5HolZa 6FL8c0RM1N4Tw+oEzhnt8MnzsrNEt/96iFhACX2nSBg+rY7qh7vvNN2Jp6/CjNNbAcym u6DyLdXX3z7KGiR7O/qqU19EYjwonQYdvpNkGV0FYZSkPuoLplatofWtMbsPh9hm7yVq FcdWTktu2x6jMY7A7gIDcs4n3UaUX40Wuia+AP6LBKLErFWTJsOQGC11+Q3n4nZG8MC3 bASA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=ts3pYMzU; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=rx07iiQd; 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=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s9si1943440edd.138.2021.08.12.01.43.45; Thu, 12 Aug 2021 01:44:08 -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=pass header.i=@suse.de header.s=susede2_rsa header.b=ts3pYMzU; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=rx07iiQd; 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=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234764AbhHLIUi (ORCPT + 99 others); Thu, 12 Aug 2021 04:20:38 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:54110 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234086AbhHLIUa (ORCPT ); Thu, 12 Aug 2021 04:20:30 -0400 Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id CA93E1FF1F; Thu, 12 Aug 2021 08:20:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1628756401; h=from:from:reply-to: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=+nfS8qOmyfIYA2Mf0aXHVt9ATNP8lz9AMeYrHpMK/5s=; b=ts3pYMzUQcqW0Gkjtx/WWY4ScRfH6uEO1D1ScsIYDXqU08PDeiGoi3wZ+TYWnjaUNXMZnt 9nJxXhDbxc/aDjU0st2scpFDc1JlMpQTEN1WW9haG84zo5mWpLmUMfJnp75AiN60JJaFCj 7fTvQa9gvRrgzyU2MDL0IEhHeeUhO3M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1628756401; h=from:from:reply-to: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=+nfS8qOmyfIYA2Mf0aXHVt9ATNP8lz9AMeYrHpMK/5s=; b=rx07iiQdwqQZKFzKHGNSz061RUNeiXz+xircouhbBQ40fgNk+wU+puXtI49WOq3zRQLUQ4 k3+SW73FBj9csdBQ== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id F379413846; Thu, 12 Aug 2021 08:20:00 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id FHKcObDZFGGaCQAAGKfGzw (envelope-from ); Thu, 12 Aug 2021 08:20:00 +0000 Date: Thu, 12 Aug 2021 10:19:59 +0200 From: Joerg Roedel To: Andi Kleen Cc: Dave Hansen , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: Re: [PATCH 1/5] mm: Add support for unaccepted memory Message-ID: References: <20210810062626.1012-1-kirill.shutemov@linux.intel.com> <20210810062626.1012-2-kirill.shutemov@linux.intel.com> <9748c07c-4e59-89d0-f425-c57f778d1b42@linux.intel.com> <17b6a3a3-bd7d-f57e-8762-96258b16247a@intel.com> <796a4b20-7fa3-3086-efa0-2f728f35ae06@linux.intel.com> <3caf5e73-c104-0057-680c-7851476e67ac@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3caf5e73-c104-0057-680c-7851476e67ac@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 10, 2021 at 02:20:08PM -0700, Andi Kleen wrote: > Also I agree with your suggestion that we should get the slow path out of > the zone locks/interrupt disable region. That should be easy enough and is > an obvious improvement. I also agree that the slow-path needs to be outside of the memory allocator locks. But I think this conflicts with the concept of accepting memory in 2MB chunks even if allocation size is smaller. Given some kernel code allocated 2 pages and the allocator path starts to validate the whole 2MB page the memory is on, then there are potential races to take into account. Either some other code path allocates memory from that page and returns it before validation is finished or we end up with double validation. Returning unvalidated memory is a guest-problem and double validation will cause security issues for SNP guests. Regards, Joerg