From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) (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 08374446C0C for ; Wed, 29 Jul 2026 11:42:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785325367; cv=none; b=dZkEcm3/YpYw6sY5R3DAVNgprUehZ+o5IFUzCBO2HpeIMfCrnujA+jhV8WmgwtR4AVyChcwQNjVr3qop8Hd77dVmLD5lSAMY9n6Hu5Z/RwH6YChsC/Mrt8Zc2uKThMBRSGtWUUfxqGJzDCkNKgvmeogdj/Opf0TSOHmIIK/bbdQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785325367; c=relaxed/simple; bh=9kfH4itgJUa8GPf4yY/mBlNDdHDMxdjknQcWqkATunU=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=nHJ+S7ETfoY3VHVHZdH8cHlM2xc3M4lAmuGNaIfvews3PS7WaAnGG1a2VU6traBVY49of7BWu5DLGyRyxJrw9E21PjXhsvZGMr4vQAjhTR7K3fGC+8uPOIQ1u2T/jyjT7DIIhcFV/Xp6swuUdcshutMad8Cg9KquaAlzMSnaNRc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=vuyvti+8; arc=none smtp.client-ip=95.215.58.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="vuyvti+8" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785325360; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cBInP0G7hBRjYIAsJ1YuS+3Ld12NRw9QSsq6YAtF1tA=; b=vuyvti+86m2ZmsFyuTHQDzcvgRE/uB3+UDJi+y3Zr5XD/vSK0aJ8xQfSK0i1AMButhsI1s WXThiwNHX2ilGaSVPW7nttHZDCNZEg+cBlgxGt+AEG7GH74wuOfXncBC/1rrz3o6TzWyW2 iH6yGk5/Ni1vp2Rm44hnjNUv73HzH0E= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 29 Jul 2026 11:42:27 +0000 Message-Id: Cc: "Borislav Petkov" , "Dave Hansen" , "Peter Zijlstra" , "Andrew Morton" , "David Hildenbrand" , "Vlastimil Babka" , "Wei Xu" , "Johannes Weiner" , "Zi Yan" , "Lorenzo Stoakes" , , , , "Sumit Garg" , "Will Deacon" , , "Kalyazin, Nikita" , , "Itazuri, Takahiro" , "Andy Lutomirski" , "David Kaplan" , "Thomas Gleixner" , "Yosry Ahmed" , "Patrick Bellasi" , "Reiji Watanabe" , "Sean Christopherson" , "Nikita Kalyazin" Subject: Re: [PATCH v3 01/26] set_memory: add folio_{zap,restore}_direct_map helpers X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Brendan Jackman" To: "Mike Rapoport" , "Brendan Jackman" References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-1-6f5729aa9832@google.com> In-Reply-To: X-Migadu-Flow: FLOW_OUT On Mon Jul 27, 2026 at 10:33 AM UTC, Mike Rapoport wrote: ... >> +#ifdef CONFIG_ARCH_HAS_SET_DIRECT_MAP >> +/** >> + * folio_zap_direct_map - remove a folio from the kernel direct map >> + * @folio: folio to remove from the direct map >> + * >> + * Removes the folio from the kernel direct map and flushes the TLB. T= his may >> + * require splitting huge pages in the direct map, which can fail due t= o memory >> + * allocation. So far, only order-0 folios are supported; this guarant= ees >> + * the unmap is either a complete success or a total failure. >> + * >> + * Return: 0 on success, or a negative error code on failure. >> + */ >> +int folio_zap_direct_map(struct folio *folio) >> +{ >> + struct page *page =3D folio_page(folio, 0); >> + unsigned long addr =3D (unsigned long)page_address(page); >> + int ret; >> + >> + if (folio_test_large(folio) || folio_test_highmem(folio)) >> + return -EINVAL; >> + >> + ret =3D set_direct_map_valid_noflush(page, 1, false); > > There was a discussion about slight differences in the semantics of > set_direct_map_valid() on x86 and on arm64 and that execmem should > apparently switch to set_direct_map_{invalid,default}. > > Maybe for this series it would be better to add a patch that adds numpage= s > to set_direct_map_{invalid,default}_noflush and use > set_direct_map_default_noflush() here? Um, I think probably we need to clean that API up a bit overall, and I think that's probably best handled as a separate patchset? I think with the API as it currently is, the current usage is correct in this patchset, and I'm a bit reluctant to grow this patchset any further (and I didn't want to block v3 on yet another preparatory series, but potentially blocking v4 on one might make sense). > And maybe also pick another Nikita's patch [2] that makes set_direct_map_= * > to take address? I deliberately omitted that, I don't think it's a good idea: https://lore.kernel.org/all/DJJ2QJQQ73CM.2WHKW4AT6QT1D@linux.dev/ (If we do want to change the API we could use PFNs as I mentioned in the last message of that thread, but I don't see any need to change that API).