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 EEDC0C433F5 for ; Tue, 4 Jan 2022 17:38:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5685D6B0071; Tue, 4 Jan 2022 12:38:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 517B46B0072; Tue, 4 Jan 2022 12:38:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DFD26B0073; Tue, 4 Jan 2022 12:38:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id 2FD246B0071 for ; Tue, 4 Jan 2022 12:38:44 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D322F94FB5 for ; Tue, 4 Jan 2022 17:38:43 +0000 (UTC) X-FDA: 78993314526.05.CA608A7 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf18.hostedemail.com (Postfix) with ESMTP id E054A1C000F for ; Tue, 4 Jan 2022 17:38:31 +0000 (UTC) Received: by mail-pl1-f172.google.com with SMTP id l16so15482687plg.10 for ; Tue, 04 Jan 2022 09:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lyYzwxTZWc2pKk20hwF7g02tZU/8D7vFzmqot46zr3o=; b=hF4kd1Mq//yjpl61nrYwvKMLJT6MIhV0E6IJ7zAD3JWlI+Lf9Kl7EjPWqG9SBDfEF8 bLQriumtvq/d4LPMxq+QOQ59vvcAi7NGeWaxhSlxlkxdhBfO29QiUCBdFlPXpq95IOxu JnrHN+97F5CEcTUWcX51rjIW0pyoQQer1CQy1E5p5jQtDlIK/mVO/JhHG7vsEQcySXvf BNaUi94Me+iu/Cekap3IlPAukuOJezwMa5QK5Oa7ly7GCgO/RioM5k2JBuseJG/0A/de MBbrQnE1pKQwoHwCb9W1/cXrW4NS+qeUQ6HoMhdMIjuDjY1Jis5Xz1s308oEz41ERKbt +qzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lyYzwxTZWc2pKk20hwF7g02tZU/8D7vFzmqot46zr3o=; b=Eh78X0qqovExcHv/XVXhZ1fNcjKCED5N+wAYB3XbrLCIObU2FMxVgLdMZYzunClag9 MoMoxwznWrrAfIZI7w3JwSAUpL464ZQjbUvYE6NzJTRV5d4D36OdZbiaHJbbjx1iIgOt VB7Ru2ZOm4AFDWoIdL0gHGEmI801ryMkwEUTmZeMsA+ngddIAwP2jd3sbSOwCnTyAfWb ht2FlX1fpmnQuOUiJLwuXPIXyRm3nr3aaor9RggQ/nqoS7nT/DfeGLElP4jHm//p8cWx eB0rv6dfnriG48CIyvVDE5dLe5MUu2v7UUuspH3rOO21zlG3pT4JMl3GIqpKGZGn0QO6 L+UQ== X-Gm-Message-State: AOAM530RXexPLjmzQYYK5R8lvcg4PFFqc2UZPQsyqS+qgzYfiTvhfgdj OoBff7lXNqUwXHI27dunqglZQA== X-Google-Smtp-Source: ABdhPJzjgo+EqH45rd3keKS/UyOltBLQmBVP2JYcV5J6T2Al78JIvydxac3UZxoz6wC2BU8T/FSzTQ== X-Received: by 2002:a17:90b:4d86:: with SMTP id oj6mr61729268pjb.185.1641317922423; Tue, 04 Jan 2022 09:38:42 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id k23sm407842pji.3.2022.01.04.09.38.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jan 2022 09:38:41 -0800 (PST) Date: Tue, 4 Jan 2022 17:38:38 +0000 From: Sean Christopherson To: Chao Peng Cc: Robert Hoo , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@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 , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, john.ji@intel.com, susie.li@intel.com, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com Subject: Re: [PATCH v3 kvm/queue 03/16] mm/memfd: Introduce MEMFD_OPS Message-ID: References: <20211223123011.41044-1-chao.p.peng@linux.intel.com> <20211223123011.41044-4-chao.p.peng@linux.intel.com> <95d13ac7da32aa1530d6883777ef3279e4ad825d.camel@linux.intel.com> <20211231023853.GB7255@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211231023853.GB7255@chaop.bj.intel.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E054A1C000F X-Stat-Signature: beu75s4d7sxj6ajnicqy4jytsk795y37 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hF4kd1Mq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of seanjc@google.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=seanjc@google.com X-HE-Tag: 1641317911-473699 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, Dec 31, 2021, Chao Peng wrote: > On Fri, Dec 24, 2021 at 11:53:15AM +0800, Robert Hoo wrote: > > On Thu, 2021-12-23 at 20:29 +0800, Chao Peng wrote: > > > From: "Kirill A. Shutemov" > > > > > > +static void notify_fallocate(struct inode *inode, pgoff_t start, > > > pgoff_t end) > > > +{ > > > +#ifdef CONFIG_MEMFD_OPS > > > + struct shmem_inode_info *info = SHMEM_I(inode); > > > + const struct memfd_falloc_notifier *notifier; > > > + void *owner; > > > + bool ret; > > > + > > > + if (!info->falloc_notifier) > > > + return; > > > + > > > + spin_lock(&info->lock); > > > + notifier = info->falloc_notifier; > > > + if (!notifier) { > > > + spin_unlock(&info->lock); > > > + return; > > > + } > > > + > > > + owner = info->owner; > > > + ret = notifier->get_owner(owner); > > > + spin_unlock(&info->lock); > > > + if (!ret) > > > + return; > > > + > > > + notifier->fallocate(inode, owner, start, end); > > > > I see notifier->fallocate(), i.e. memfd_fallocate(), discards > > kvm_memfd_fallocate_range()'s return value. Should it be checked? > > I think we can ignore it, just like how current mmu_notifier does, > the return value of __kvm_handle_hva_range is discarded in > kvm_mmu_notifier_invalidate_range_start(). Even when KVM side failed, > it's not fatal, it should not block the operation in the primary MMU. If the return value is ignored, it'd be better to have no return value at all so that it's clear fallocate() will continue on regardless of whether or not the secondary MMU callback succeeds. E.g. if KVM can't handle the fallocate() for whatever reason, then knowing that fallocate() will continue on means KVM should mark the VM as dead so that the broken setup cannot be abused by userspace.