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 C314DC433EF for ; Tue, 10 May 2022 18:32:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 566CF6B0072; Tue, 10 May 2022 14:32:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53D706B0073; Tue, 10 May 2022 14:32:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42B176B0074; Tue, 10 May 2022 14:32:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 346DF6B0072 for ; Tue, 10 May 2022 14:32:23 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id ECEDD6195B for ; Tue, 10 May 2022 18:32:22 +0000 (UTC) X-FDA: 79450678524.16.1886945 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf26.hostedemail.com (Postfix) with ESMTP id B79D914009B for ; Tue, 10 May 2022 18:32:18 +0000 (UTC) Received: from zn.tnic (p5de8eeb4.dip0.t-ipconnect.de [93.232.238.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1E0DA1EC0354; Tue, 10 May 2022 20:32:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1652207536; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=YwlI4SOdaCiIF2T0fRasnf3pb0Dz0W+PbTJT112BTbI=; b=qtivRA6UZ8N6glsgC7YCH4Cm2zMMzUrDPR5yH/pAfaBCOygYNvflOfciVP7oT8Np8O/88W CgzdPyC6lZl0zGjd536DXox2BLwQQZXRDAB0JHlgjwISgp0GqwOGue4hyBNWd+iqwogCc/ /bYQ0+dDaSjuHp0NUl7USPvcr5qTq8s= Date: Tue, 10 May 2022 20:32:23 +0200 From: Borislav Petkov To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Dave Hansen , Brijesh Singh , Mike Rapoport , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory Message-ID: References: <20220425033934.68551-1-kirill.shutemov@linux.intel.com> <20220425033934.68551-9-kirill.shutemov@linux.intel.com> <20220506161359.4j5j5fxrw53fdbyr@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220506161359.4j5j5fxrw53fdbyr@box.shutemov.name> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B79D914009B X-Stat-Signature: tpk5r1q61n3ys3xz1eq8fkgesmqucohr X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=qtivRA6U; spf=pass (imf26.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de X-HE-Tag: 1652207538-760330 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, May 06, 2022 at 07:13:59PM +0300, Kirill A. Shutemov wrote: > Failure to accept the memory is fatal. Why pretend it is not? > > For TDX it will result in a crash on the first access. Prolonging the > suffering just make it harder to understand what happened. Ok then. Does that panic message contain enough info so that the acceptance failure can be debugged? Just "Cannot accept memory" doesn't seem very helpful to me... > That's true. Note also that the check is inherently racy. Other CPU can > get the range or subrange accepted just after spin_unlock(). > > The check indicates that accept_memory() has to be called on the range > before first access. > > Do you have problem with a name? Maybe has_unaccepted_memory()? I have a problem with the definition of this function, what it is supposed to do and how it is supposed to be used. Right now, it looks weird and strange: is it supposed to check for *all* in-between (start, end)? It doesn't, atm, so what's the meaning of @start and @end then at all? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette