From nobody Sun Feb 8 18:15:35 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 8C4C02139B6 for ; Fri, 10 Jan 2025 18:22:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736533326; cv=none; b=TG+3h52+icWbU8c6qSyehQw6nxn6fe8BaFXNdv/tX2QI4Tg0FHqzXmCawGGTk2viec3bX9U0ZKIiLKPHEG6b1AOvWTmvCsXoiPQ7u5d5ZdK/UKBIFiEVtF+DXr5G/3LTV8Z36qtxNbBVlvSEvrJnmoU7i/TAmjmfla0NF8A+2l8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736533326; c=relaxed/simple; bh=baQ9XIDqSvAwquPXxSXI3giATBOT6DgOA+vM19Qyddg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LRmB7zpFmnMQZVpgEXNiU9xvo1qvz8zAOwxmSZBaHymcfOFm1yUXdw3qnHElUHfYH3Ph3A7w1Vks7vyqFzV13/z7+FTJNNiNOy/4XSkXT0TQLjHCJ1+JIoMjhhxQ2fNDCz1Q14u+kY6rnIptH4nbv1eYQKZlcUMlTzDSvXLFklA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none 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=WuO8P/lY; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none 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="WuO8P/lY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736533323; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v8hq4g4DhybxUwRn0BKWdtx8BUqV1Iw/Qc0FsV0dDNg=; b=WuO8P/lYbO6WgADyMdHJBQTySIK+Mvr4M4buT/TooP2iciWN69/rg2cwLxi8pdaWkueHqT K7peoWDaJRT0vl4ExIqSf/r+Ya4WLGLk0eyhONn1Kb2XTQAMlN7bALKkBc1In6Ty+HJhjq 1FYSSXal4G7LrUY4pxEXpjZdHVQqans= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-664-kVGkUQJdOR-SAU5COAqSmQ-1; Fri, 10 Jan 2025 13:22:02 -0500 X-MC-Unique: kVGkUQJdOR-SAU5COAqSmQ-1 X-Mimecast-MFC-AGG-ID: kVGkUQJdOR-SAU5COAqSmQ Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-436248d1240so11481425e9.0 for ; Fri, 10 Jan 2025 10:22:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736533321; x=1737138121; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=v8hq4g4DhybxUwRn0BKWdtx8BUqV1Iw/Qc0FsV0dDNg=; b=jq5yXMaqgSSiQfz4tn4iEeBb7D2zHi3S5b4MCJi+SMwYMzp+wHqtiQi0R2zYO/514u y8GXHfLvWvRWdxgPGlqTrnAiuvsWxJKUuUtL/Nj8g0bO0JwwT30aoTmSddpdM+XKHyB+ hQhuys5/qPB9PnOIQUo3CLOjC041zkCfQaMX967lm9AJOGVW84uotZEIb2+cE5nekczR 3nI9f9GMMJqpN3ioPPT8xpgSvEnx1XiaKSs2OmgY4EqnaO4ajT4ArZP3U96tJV1PLGS3 F7RWdEyd2iO+L2nCeWNulQ232skfqaYmdeZ+4u+pGQHZG7trdTlHyG+smn/z1tB945al 9k9Q== X-Gm-Message-State: AOJu0YyeinpcFPYZB6gtlzML9rx7Vj4W4wrP9x8g7oqxdJOKTMA755XE QM+do5M6UcmatmuL+rwyoOez8Ij4vIwif9wOjUry7/MTpQkVuNJ5quMskQufaFQZ7ougP9BckD8 xTpJLx4+Y3/LAgldQltygVLH5j6REGb6tDdx/BrEEvHcu9BgLAflcXdYqW0E9FnwZgpBGxExyq9 z195I5yVzGUkH6CV/YGTV8wNiRhstw4/0Hpnvevferdg8R X-Gm-Gg: ASbGncs4Sdr9aaTw9VSe7kIZpqD+SKBcZe/502Asl22d3BWUph6/0cCrA3Ag0yMYEAb aXl9YHRLy2RaCbf9VygRtWOIki5ryUJPkIOkEkrFAAglyrO+tuJ94sm2uuUbPsuc8T0ed2mZR9Y c6lV6txqGFFUMuzHVo8E2Ya9nltgbjiTuvjhxzMPVdnKqxLsvDhTS8FJR9N5gPeEtjxPTeyQI2p +os05Iv0LcsSYPTZ7gRX2EjM8uRf3cpLqgQgsDteJ1+WTjxFD2AS/Iccuit9Ndu3WSqpMtyjsYL hguvoGjq/5mfYvvxie0fPzeTjBK0pFHhgH1zaLy4Ig== X-Received: by 2002:a5d:648b:0:b0:386:3e3c:ef1 with SMTP id ffacd0b85a97d-38a87312f36mr11978777f8f.35.1736533320899; Fri, 10 Jan 2025 10:22:00 -0800 (PST) X-Google-Smtp-Source: AGHT+IHsNI1nT/mSiB4lNoNG7hpy+n586x8LDR/iUFuGNavqE1Zjg9u3TYOy+Hd2kEulLAgwJ82EoA== X-Received: by 2002:a5d:648b:0:b0:386:3e3c:ef1 with SMTP id ffacd0b85a97d-38a87312f36mr11978752f8f.35.1736533320488; Fri, 10 Jan 2025 10:22:00 -0800 (PST) Received: from localhost (p200300cbc708e1004f41ff29a59f8c7a.dip0.t-ipconnect.de. [2003:cb:c708:e100:4f41:ff29:a59f:8c7a]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-436e2da66d9sm95077415e9.1.2025.01.10.10.21.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2025 10:21:59 -0800 (PST) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Andrew Morton , Muchun Song , "Matthew Wilcox (Oracle)" Subject: [PATCH v1 3/6] mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio Date: Fri, 10 Jan 2025 19:21:46 +0100 Message-ID: <20250110182149.746551-4-david@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250110182149.746551-1-david@redhat.com> References: <20250110182149.746551-1-david@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We replaced a simple put_page() by a putback_active_hugepage() call in commit 3aaa76e125c1 ("mm: migrate: hugetlb: putback destination hugepage to active list"), to set the "active" flag on the dst hugetlb folio. Nowadays, we decoupled the "active" list from the flag, by calling the flag "migratable". Calling "putback" on something that wasn't allocated is weird and not future proof, especially if we might reach that path when migration failed and we just want to free the freshly allocated hugetlb folio. Let's simply set the "migratable" flag in move_hugetlb_state(), where we know that allocation succeeded, and use simple folio_put() to return our reference. Do we need the hugetlb_lock for setting that flag? Staring at other users of folio_set_hugetlb_migratable(), it does not look like it. After all, the dst folio should already be on the active list, and we are not modifying that list. Signed-off-by: David Hildenbrand Reviewed-by: Baolin Wang --- mm/hugetlb.c | 5 +++++ mm/migrate.c | 8 ++++---- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index da98d671088d0..b24ccf8ecbf38 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -7529,6 +7529,11 @@ void move_hugetlb_state(struct folio *old_folio, str= uct folio *new_folio, int re } spin_unlock_irq(&hugetlb_lock); } + /* + * Our old folio is isolated and has "migratable" cleared until it + * is putback. As migration succeeded, set the new folio "migratable". + */ + folio_set_hugetlb_migratable(new_folio); } =20 static void hugetlb_unshare_pmds(struct vm_area_struct *vma, diff --git a/mm/migrate.c b/mm/migrate.c index 80887cadb2774..7e23e78f1e57b 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1542,14 +1542,14 @@ static int unmap_and_move_huge_page(new_folio_t get= _new_folio, list_move_tail(&src->lru, ret); =20 /* - * If migration was not successful and there's a freeing callback, use - * it. Otherwise, put_page() will drop the reference grabbed during - * isolation. + * If migration was not successful and there's a freeing callback, + * return the folio to that special allocator. Otherwise, simply drop + * our additional reference. */ if (put_new_folio) put_new_folio(dst, private); else - folio_putback_active_hugetlb(dst); + folio_put(dst); =20 return rc; } --=20 2.47.1