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 95695C433F5 for ; Tue, 24 May 2022 23:36:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08A638D0003; Tue, 24 May 2022 19:36:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 064058D0002; Tue, 24 May 2022 19:36:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E45508D0003; Tue, 24 May 2022 19:36:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D6BCA8D0002 for ; Tue, 24 May 2022 19:36:52 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 98CB480B32 for ; Tue, 24 May 2022 23:36:52 +0000 (UTC) X-FDA: 79502249064.23.6638897 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf19.hostedemail.com (Postfix) with ESMTP id D98531A003B for ; Tue, 24 May 2022 23:36:38 +0000 (UTC) Received: by mail-pj1-f53.google.com with SMTP id o10-20020a17090a4e8a00b001df2fcdc165so229010pjh.0 for ; Tue, 24 May 2022 16:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=7d1GZoiIPgurRKHqYkbLbRfkJMBlTGlbTuzD6kjnHaA=; b=KeFIqxa6CCFetIxYiv9IdzoKB2DP/2IjtAPFyJN7ulMa+N9FmuID4xO83AXLE9XhxD QLC9D4pC5g086lAPfbPlDRGHNGdMHwddAVFaFt97S4GEoEBfL5enEWauuAld1AZRclVs vlk6RettmorUKl8wUHT10Vie0HCcM3Mx9wBPqG0i6qhZfHFc4kVMJS7KgOVSrQE0xBgI 9LIyRn2BTe72SSbfwn7J7ox7BQCmbUiHCfzzLsvKvnGb9uty97mnBsqi4usWbcRHpKsb 9kuGhvHlJM08XtjrVtsc39552A578wJHeQW3WGHq8tKjima0G3jN8kCS2zMVMq4kqLdj 4kKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=7d1GZoiIPgurRKHqYkbLbRfkJMBlTGlbTuzD6kjnHaA=; b=ejr7a35j3D7mMl7QxeTItGDmdTRLpCOy7DfzTrbLiAe/NAdINYchQf+7GS6KVuD6Qz t2z0nFV7Z2hCQSNZMpxe08A1VPbpjMSq5ti/pKtgnSUmFYtEWEQbOss2/ZW5XVYbcPkk HEfdVNB+GbiebeJcm+QtJ2QRh/3EkiRlf6pC2OlKdmwdu/yv6zo/fKgmxLnkMVMj+yfc 2XGhjuqVFujYHqK/gILJ6hwDvkcxQhfNuHa/LmtSLQ7H+dS5C0VblQPCxh+Kkfv8ByNw vmaUMD3okY8OaoiS4yyCdrzDl6VWRrWnMM2UbCASUjuXwHdEK8/DvWu6vEER9VVhiHXL FcNg== X-Gm-Message-State: AOAM530O3Uu6cbvgbZX6NrDqC90P7dlZ1PKIKqIKWd8o/I8az0yhwjhQ VoGnbN/6WuoBnYAmRHSKwvbKeA== X-Google-Smtp-Source: ABdhPJyYL9A7b9Eq9H2YA+sOCWRW25ucZlQtBHk+GLvqCYdvPljMLdHOrNVkUrPOkTAZFApgB75bJQ== X-Received: by 2002:a17:90b:388c:b0:1df:cb4b:3e72 with SMTP id mu12-20020a17090b388c00b001dfcb4b3e72mr7391714pjb.130.1653435410036; Tue, 24 May 2022 16:36:50 -0700 (PDT) Received: from [10.255.89.252] ([139.177.225.239]) by smtp.gmail.com with ESMTPSA id t11-20020a17090abc4b00b001df54d74adbsm272232pjv.25.2022.05.24.16.36.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 May 2022 16:36:49 -0700 (PDT) Message-ID: <79d17b10-3532-57d4-e70c-3ccf1ab0d87d@bytedance.com> Date: Wed, 25 May 2022 07:32:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Re: [PATCH 3/3] virtio_balloon: Introduce memory recover Content-Language: en-US To: Sean Christopherson , david@redhat.com Cc: akpm@linux-foundation.org, naoya.horiguchi@nec.com, mst@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jasowang@redhat.com, virtualization@lists.linux-foundation.org, pbonzini@redhat.com, peterx@redhat.com, qemu-devel@nongnu.org References: <20220520070648.1794132-1-pizhenwei@bytedance.com> <20220520070648.1794132-4-pizhenwei@bytedance.com> From: zhenwei pi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: emn88hhc9nernj9omm4r6698gm66q7rc X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=KeFIqxa6; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf19.hostedemail.com: domain of pizhenwei@bytedance.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=pizhenwei@bytedance.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D98531A003B X-HE-Tag: 1653435398-958352 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 5/25/22 03:35, Sean Christopherson wrote: > On Fri, May 20, 2022, zhenwei pi wrote: >> @@ -59,6 +60,12 @@ enum virtio_balloon_config_read { >> VIRTIO_BALLOON_CONFIG_READ_CMD_ID = 0, >> }; >> >> +/* the request body to commucate with host side */ >> +struct __virtio_balloon_recover { >> + struct virtio_balloon_recover vbr; >> + __virtio32 pfns[VIRTIO_BALLOON_PAGES_PER_PAGE]; > > I assume this is copied from virtio_balloon.pfns, which also uses __virtio32, but > isn't that horribly broken? PFNs are 'unsigned long', i.e. 64 bits on 64-bit kernels. > x86-64 at least most definitely generates 64-bit PFNs. Unless there's magic I'm > missing, page_to_balloon_pfn() will truncate PFNs and feed the host bad info. > Yes, I also noticed this point, I suppose the balloon device can not work on a virtual machine which has physical address larger than 16T. I still let the recover VQ keep aligned with the inflate VQ and deflate VQ. I prefer the recover VQ to be workable/unworkable with inflate/deflate VQ together. So I leave this to the virtio balloon maintainer to decide ... >> @@ -494,6 +511,198 @@ static void update_balloon_size_func(struct work_struct *work) >> queue_work(system_freezable_wq, work); >> } >> >> +/* >> + * virtballoon_memory_failure - notified by memory failure, try to fix the >> + * corrupted page. >> + * The memory failure notifier is designed to call back when the kernel handled >> + * successfully only, WARN_ON_ONCE on the unlikely condition to find out any >> + * error(memory error handling is a best effort, not 100% coverd). >> + */ >> +static int virtballoon_memory_failure(struct notifier_block *notifier, >> + unsigned long pfn, void *parm) >> +{ >> + struct virtio_balloon *vb = container_of(notifier, struct virtio_balloon, >> + memory_failure_nb); >> + struct page *page; >> + struct __virtio_balloon_recover *out_vbr; >> + struct scatterlist sg; >> + unsigned long flags; >> + int err; >> + >> + page = pfn_to_online_page(pfn); >> + if (WARN_ON_ONCE(!page)) >> + return NOTIFY_DONE; >> + >> + if (PageHuge(page)) >> + return NOTIFY_DONE; >> + >> + if (WARN_ON_ONCE(!PageHWPoison(page))) >> + return NOTIFY_DONE; >> + >> + if (WARN_ON_ONCE(page_count(page) != 1)) >> + return NOTIFY_DONE; >> + >> + get_page(page); /* balloon reference */ >> + >> + out_vbr = kzalloc(sizeof(*out_vbr), GFP_KERNEL); >> + if (WARN_ON_ONCE(!out_vbr)) >> + return NOTIFY_BAD; > > Not that it truly matters, but won't failure at this point leak the poisoned page? I'll fix this, thanks! -- zhenwei pi