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 2D540C64EC4 for ; Thu, 9 Mar 2023 11:39:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B805E6B0071; Thu, 9 Mar 2023 06:39:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B08126B0072; Thu, 9 Mar 2023 06:39:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D21E6B0075; Thu, 9 Mar 2023 06:39:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8FD8A6B0071 for ; Thu, 9 Mar 2023 06:39:26 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4FD3BAB7EC for ; Thu, 9 Mar 2023 11:39:26 +0000 (UTC) X-FDA: 80549164332.28.EC61A04 Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) by imf07.hostedemail.com (Postfix) with ESMTP id 9598140011 for ; Thu, 9 Mar 2023 11:39:24 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VzEe7sRh; spf=pass (imf07.hostedemail.com: domain of elver@google.com designates 209.85.222.48 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678361964; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=G+8z2L1kFSNkS27suUQ09cJ0m82R8UDZ0dpQDPDz3WU=; b=oV7QgYIktPCgP58Mqmaf5Lf1T/ORzBYbJXgEFo/v4stMGaLinDeDMCB2Hm8pyq6NNAv6br UWGHermaY3/racZyEe/L+pQ3F5r7rrEAl7sSnf3UzRBJmj5F4L4mGZKABW6cAhntr1aTkm dgW5fFYdGGsZM926+ytPIFafgqDG0k8= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VzEe7sRh; spf=pass (imf07.hostedemail.com: domain of elver@google.com designates 209.85.222.48 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678361964; a=rsa-sha256; cv=none; b=Vui3jYx9i5cp5WxTimu0PtcaTjcpuAz4e7ITZ5UzV76J8cyqalctmoZ86+HUvuLLNoY7h5 SRDNQHDhgLlVv5YFaaEQwCZyDYnLDYUris6lGGeJOEkrNQ2NUpp9tLpqqWiMN1pIyXlaJD UoNCcDmNMbT52DcdWi9mykV1Wk3hmxU= Received: by mail-ua1-f48.google.com with SMTP id x40so908673uaf.2 for ; Thu, 09 Mar 2023 03:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1678361963; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=G+8z2L1kFSNkS27suUQ09cJ0m82R8UDZ0dpQDPDz3WU=; b=VzEe7sRh/Ij2y/k3D/tqohV5U6f6IcIQkh6ZX1y0A03Ph1ii3DiJPCp40FEGtYRfBX DOIsZVkgW3D++XewibBCES7NTFheNcRkO5f8qaoQTQQd2EN8BX1OLFXLFDIwcMR+0Sqs rO5gYFntHNkIcgTU3p5mEdu98Z4CIWes35gnKt2DURUVTiatRvm2fsVx3wAvcSZ+txlW w0BrrVPjsLhFF8NyoO+OIpD/2XG4O/AGMwz7m1gd17UcFQBdy8IasUKBVDTJbZxM5LFA 7w6M2gfBYErCwO21FQJbr5RpQzbfzlzZv5oWkrjaHyTFCWIbYudO9kl3WnEZtEqiObCv bVBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678361963; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=G+8z2L1kFSNkS27suUQ09cJ0m82R8UDZ0dpQDPDz3WU=; b=cflRNp1flQI4/23AVgn/4OYLac3Oc9i7rCI+aePHGBimeQCbFSkre56MjEoqUDbtot O5XHvS+XzKuBZIi0MZmBCJAl1afd55tgyogWW5f9bEqgFpscLSTfuzxMBMc18izQ1eP7 0Qo3J3PEgDXkuO0MQRfWJ/81Z62J4MIvAjUahH3pIhW6+YDgac8fRup/lNOWDuqY0oDs 2JOi7gFr7XfLS6aAHG+j2FOa8Z/mRJ1VvIQggooBDiQN7HpIOR7OXJVq2i/joeJGjv3z v3XABEX2irfOvaDj/fSGLGiimJ/9DE5oQNSE0NT+JxxS0VBXGDNHOdW2vT63Y6wj032h FhUw== X-Gm-Message-State: AO0yUKW/juoveSxkU2TjeMeG3eOP9nAyI0LFgl+119WXS8YuostGHwjj 3GEyWxZCyH9zx576l/4NCBh2QOVNC2ZQ/bVPZaegoQ== X-Google-Smtp-Source: AK7set+GNkobzr6eMeXzIkNTtl9T0rFmUMArRjK0bZnS801XXq/pXowCXJKdeq3S3WWlUocUDvoHA9Qjpe2k4X1P9h8= X-Received: by 2002:a1f:4384:0:b0:41d:fe99:4633 with SMTP id q126-20020a1f4384000000b0041dfe994633mr13340530vka.2.1678361963509; Thu, 09 Mar 2023 03:39:23 -0800 (PST) MIME-Version: 1.0 References: <1678349122-19279-1-git-send-email-quic_zhenhuah@quicinc.com> <706340ef-1745-c1e4-be4d-358d5db4c05e@quicinc.com> <3e8606e4-0585-70fa-433d-75bf115aa191@quicinc.com> In-Reply-To: <3e8606e4-0585-70fa-433d-75bf115aa191@quicinc.com> From: Marco Elver Date: Thu, 9 Mar 2023 12:38:43 +0100 Message-ID: Subject: Re: [PATCH] mm,kfence: decouple kfence from page granularity mapping judgement To: Zhenhua Huang Cc: catalin.marinas@arm.com, will@kernel.org, glider@google.com, dvyukov@google.com, akpm@linux-foundation.org, robin.murphy@arm.com, mark.rutland@arm.com, jianyong.wu@arm.com, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, quic_pkondeti@quicinc.com, quic_guptap@quicinc.com, quic_tingweiz@quicinc.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9598140011 X-Stat-Signature: c5ofzyds4xcp7h5ico5uj9us3czikygc X-HE-Tag: 1678361964-496655 X-HE-Meta: U2FsdGVkX19bqEJ7/JzAJtwPHFl+ouftJ6gEahKH8MK7MazepRXv51sWXtr0HjtQKosf7rqYiZokCiTB/RPmY5PP2+jbF2f/kINYYqBgZXO6b0+66E2l2iDub9TNLCmsm4yPKP+64x2wyt8GCURSfFUWM0gtavsgteKqkuLuyTIrg73qi2fhjceGUmYBuKS0uK6NBF06fa1q/1XbEmrrMUuRxgS052zRGKOFnvuD98CKPngQcOeuXZaKQxLzP7wa7Yua1XvL/zTYl2s57vn/6P4RLeYlh9J35Nbqza15mCOGvjD7AYxfqglIRBWWMYfFHb1nUhJHCGmO5IZv3tRuZ/W7j232G4u1oWK1b90uj/wKT8R35qtmk3fNc1sjcWjQSKpiRBQuadaND9LuAvAhQm5FHPCjEBGfVXByKBmkOp6rc1Z+EUt0ZIoF5p1NsuP7QELw0CiTsivOktoA799ZKEdaavdOAEX/J0JsOrI5fxh56MxkEsTSWT61XMb78QCV5J8KbviDpS+7XUTCeQStxt8nIzejRJzKIOVVfwqQRomzatCguIZHXZBX412mISeEaiHxaeSlhjlBEd10YRMKzD0ZMoXBsoAfc3S13fERq6SDLnJcHEROn4hmEGM69ubkno/5qWkrDyCSm2bmn7zmTiL816Kf4vXHrV7+6egAbazWxXECx7JhzfuLFd+8pxx+orRSISuyhZ0D0yExGJgXyAHn65ImwFpin2dq70T9u6NGtE9qX7EByWLOwpCPOXvZkQqyq+q8D4yoFp3GOAeaxxoaQBHh+lYhC8Ilz7TcJO7tRVOUg4PjSxzpItN2BwbKJSfYg7wmdgErrKrvyDYJpbt5n1v3sLqky4GS8kxnpXItn/o0v7ZmFt6U262Y13lF/gG4OM1ao1WRNPjErFW505i62cShH8qRsiDiPHE915gnKDNOvliHbQKJWQJnIBJV1VE6y+bHpXaRP5gIGGz U8iYLTk4 nIRCHFTMRjBvwUHJKrl+CHDEbtXjb2LE3Tn4VbugaFC4ONvo0U54/4Ywlnm9wjZfPvtYemrLcB6Yi+2B74N2tcmtT2jEUt8+HxcIx6hJiJpnZNRJlF77/xWx39geTH96tM4roszup2ow2iCO+Z1jFvv7ELVkKDTNDJEg1XxEnGVq17FCDIk3WPlhh1fJPmoVjHQlzOxXBaOY1j2AE67s9Gc/bC54mx06nB+FXqSKL2phfAD3N2rfXXNcWNJAhUqjxLm1//qr0HPhnLBPNAMOaJzeEMhNb/MG8eLFZ8AOpK4zAh9nsUsK40i05BA== 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 Thu, 9 Mar 2023 at 12:26, Zhenhua Huang wrote: [...] > > Ah right - well, you can initialize __kfence_pool however you like > > within arm64 init code. Just teaching kfence_alloc_pool() to do > > nothing if it's already initialized should be enough. Within > > arch/arm64/mm/mmu.c it might be nice to factor out some bits into a > > helper like arm64_kfence_alloc_pool(), but would just stick to > > whatever is simplest. > > Many thanks Marco. Let me conclude as following: > 1. put arm64_kfence_alloc_pool() within arch/arm64/mm/mmu.c as it's > arch_ specific codes. > 2. leave kfence_set_pool() to set _kfence_pool within kfence driver, as > it may become common part. > > The reason we still need #2 is because _kfence_pool only can be used > after mapping set up, it must be late than pool allocation. Do you have > any further suggestion? I don't mind kfence_set_pool() if it helps avoid some #ifdef CONFIG_KFENCE. However, do note that __kfence_pool is exported from include/linux/kfence.h. Since you guard all the new arm64 code by #ifdef CONFIG_KFENCE, kfence_set_pool() doesn't look necessary. However, if you do something like: #ifdef CONFIG_KFENCE ... define arm64_kfence_alloc_pool ... #else ... define empty arm64_kfence_alloc_pool that returns NULL ... #endif and make that the only #ifdef CONFIG_KFENCE in the new arm64 code, then you need kfence_set_pool(). I think that'd be preferable, so that most code is always compile-tested, even if the compiler ends up optimizing it out if it's dead code if !CONFIG_KFENCE. Thanks, -- Marco