From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A121175A8F for ; Tue, 21 Apr 2026 13:06:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776776769; cv=none; b=dqGAoAVyQS9NOzs0CkmjI6Z3YjB/pDua9vGo21TL1Na9V7C32efufnJzFE503vjsGxfC9y5jMgA1ulbYdPRh2ZV4Dze+7QrcRKqLfp+Kl9rWFD9Ciis5kazzbFgtCVq5LfsAiHbetq1aMsOShQ+bR+u3O+N2BJgckUEcimPLUAc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776776769; c=relaxed/simple; bh=lh1FcXOPpS+yPvMhZ11/X62M6aZEU5IC4SqKzlJLlWE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=G1ifJRB4ZkmjfL5WJv0D55Hn3PmG5mGtG7EY29ZVfaJSM+TOr9s048VgusnmObsLV0xJioJSfgvHjT/XWyVe2hQ0IWbEClWTTx3lHHBY2ydDeAQUK6K5tXbBMuifHVvMnIRQoDgGRed9NZ8v3eTkrWlRCgeWLrNnbj4PwyP7e98= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=K1FR8HI7; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Q9tTFf5a; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="K1FR8HI7"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Q9tTFf5a" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776776767; 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: in-reply-to:in-reply-to:references:references; bh=z1rvnWiWbaVtbuakXF1GY3gyQym0BGWKhGhCncv/qMI=; b=K1FR8HI7+aJTrOzd6hstviNxyAWS2Xn+xz8TI29K1I+DDewdleqMT9bKzFlFYTYTzws7GJ QTfjjzrz4gJ98gyn4YDQfg9uGMhsMNAdAbtGQJpWBIPkCeMQiibSDeekGvK/3+0RlSWniC 7DRppX8Mp8RE/FgHQNmlTfTyEX+hn2c= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-665-2MMGzRGmNGW-VvXiFT_CTw-1; Tue, 21 Apr 2026 09:06:06 -0400 X-MC-Unique: 2MMGzRGmNGW-VvXiFT_CTw-1 X-Mimecast-MFC-AGG-ID: 2MMGzRGmNGW-VvXiFT_CTw_1776776765 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-43d780757eeso2456692f8f.1 for ; Tue, 21 Apr 2026 06:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776776765; x=1777381565; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=z1rvnWiWbaVtbuakXF1GY3gyQym0BGWKhGhCncv/qMI=; b=Q9tTFf5agxlcSlvKXcke263Uc5oez9DK4oVB8I5x9i3Q/xg1KTSc1lBzbW4s85z/sV 9PX0Uz3ZLghu2vkGCwyoEw0rrVeFMcXqz9J/6+IHK8FvhJrey1HJmmiXMd+LCpMBxY+5 BudZV81G36+bKP7cIOsyZGsQgbj16Uxeds4MLyg4J+YyoTQzmB/16mWj/jN6kyA/OhJN pO9/qfPft6Fsg0I0GoVD2Y2XisFINK310drwZeud0xP2zddMhwkE885JWb7SzXqgJog0 XrMk/QOX5/UG7D0mYBBYLX9Dd0Ev1UhyJafM1EdPMZcUAD2Wsy5cQB+rS6knbMp6uUp1 nSvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776776765; x=1777381565; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=z1rvnWiWbaVtbuakXF1GY3gyQym0BGWKhGhCncv/qMI=; b=YvDkD/c8/CKaWJBTcuZDACUqnru9KnHL5Ue0q/PGhObx9KaWQw26KEeDYhszgJiKyi JKfzv68uDsS85fGFwG7zk1jLwpytdg38eVCgi7i9KCZHODUdWn8htGMKXFNAmKwD7lNu n70uhr0exzvLfGJswl3lgiO7hWzGFnMo0toQcVPZ2Uv24YKfxJArzfRx1iDWPBxCmJRd gLEWRhJJLc2kTn5aIW0s/vYGXUC9OUrW3mNKtF+a8aX0ce7JFcjPpgzWEEqRV34LR9gr GBp5yT2q+fDfqFAqBoYetNyl+KPbzuQRI1hLDPSZg+OB+Yby7osagFV7x/pEMwXLmdKS UBug== X-Forwarded-Encrypted: i=1; AFNElJ8aJl1YqkRNH5M5qYys47Eph5W/wIy6VaNvCOkmPiBhpvWQzk4t73cd53uakrsh6N6uRxQcUKI8ETyGwJY=@vger.kernel.org X-Gm-Message-State: AOJu0Yw22aCAhA/qRKaDiqtAV9wbdkHnhpu4LYUbCpHYvWVGB7PemzK/ Resw4C6asRe3SwoTNWk0D3sjq3dillMObaKRzlyoiWgF5rvByPuJwOhZ8EN+zJj+V9tD+zQxmt9 4IbwcK/LhChj0bX85VU5jdwC1OBPLFQehEvzF7gXup+sotg/detb9ncgWETzlZiZVLw== X-Gm-Gg: AeBDieukb5LtxI0xEDgIOLPqwVB4gkZwJlXB/z9q1ZqztCGrnpIqKP0okncMUCbVUUu oaGnt2f2DfvOdnQb9fsAPhZrkytWMF+Ecjt2AjXALPo6rPy8VpMH2JtxVAOTBaHPXzoVWRpCzRk GdPYTQRmuvh8Q5Nk8J0KfDetIHQiqyXpm4RNT/T3fXvaYle+HdSdighqe3Fdp8XyPolYIhHS5zr gIzFFR6E1oPdXsVxA+gNiKxO4mY+fWT5GZiRUPsbf/g9LfsGaUdaa519114hTYfcA3wGmDkwEdZ 2ldoTie5wEUX2JPvWBkhOpPgbfHcrSucYeRzJd6sD9Z0FrP32OcYMK6CBJ89BHIfXl9zifV7tjg pCa5AG2ZuDJzcCIFciwALsnEU2zfrZiUwEdS+XcC81mYk6w5iwigPRA== X-Received: by 2002:a05:6000:2a0d:b0:43d:7a5e:8162 with SMTP id ffacd0b85a97d-43fe407df74mr18663584f8f.15.1776776764972; Tue, 21 Apr 2026 06:06:04 -0700 (PDT) X-Received: by 2002:a05:6000:2a0d:b0:43d:7a5e:8162 with SMTP id ffacd0b85a97d-43fe407df74mr18663537f8f.15.1776776764395; Tue, 21 Apr 2026 06:06:04 -0700 (PDT) Received: from redhat.com (IGLD-80-230-25-21.inter.net.il. [80.230.25.21]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43fe4dc26a3sm42414615f8f.15.2026.04.21.06.06.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2026 06:06:03 -0700 (PDT) Date: Tue, 21 Apr 2026 09:06:00 -0400 From: "Michael S. Tsirkin" To: Gregory Price Cc: "David Hildenbrand (Arm)" , linux-kernel@vger.kernel.org, Andrew Morton , Vlastimil Babka , Brendan Jackman , Michal Hocko , Suren Baghdasaryan , Jason Wang , Andrea Arcangeli , linux-mm@kvack.org, virtualization@lists.linux.dev Subject: Re: [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages Message-ID: <20260421090341-mutt-send-email-mst@kernel.org> References: <20260420192037-mutt-send-email-mst@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Apr 20, 2026 at 10:38:19PM -0400, Gregory Price wrote: > On Mon, Apr 20, 2026 at 07:33:38PM -0400, Michael S. Tsirkin wrote: > > On Mon, Apr 20, 2026 at 08:20:57PM +0200, David Hildenbrand (Arm) wrote: > > > On 4/20/26 14:51, Michael S. Tsirkin wrote: > > > > > > A lot of churn, and my concern is, if we miss even one > > > > place, silent, subtle data corruption will result and only > > > > on some arches (x86 will be fine). > > > > > > Which would *already* be the case of you use folio_alloc(GFP_ZERO) > > > instead of magical vma_alloc_folio() + folio_zero_user(). > > > > > > I don't really see how vma_alloc_folio_hints() -- that also consumes the > > > address -- is any better in that regard? > > > > By itself, it is not. But the issue is propagating the address from > > there all over mm. If we miss even one place - we get a subtle cache > > corruption on non x86. > > > > Why does it need to propogate? > > Can we leave folio_zero_user() callers the same, but add a PG_zeroed > check in folio_zero_user() that skips the zeroing (but not the cache > flush) and clear the PG_zeroed bit? > > Is this feasible? I do not see how - this would require leaking the page flag out of the buddy allocator. > You don't eliminate the folio_zero_user(), but maybe we shouldn't? > > (a bit naive here - i haven't checked the PG_zeroed lifetime, i did > see it overloads PG_private - so this might not be feasible) > > > > > I also note that we need a flag for free in order to implement > > balloon deflate as you asked. Here, I reused the hints. > > > > I'd sooner just implement this as > > ___put_folio(folio, gfp_t) > > __put_folio(folio) { ___put_folio(folio, NULL); } > > And change the free path to take overloaded gfp flags. > Some of the existing ones might even be useful as-is. > > It's essentially the same thing, but prevents a bunch of churn and > saves us a new concept. > > optional gfp flags on free seem like genuinely useful interface for > certain callers (definitely not all). > > ~Gregory But we do not have a gfp_t flag meaning "this has been zeroed" and when I proposed something similar in v1, David hated abusing gfp flags for what is not an allocation property.