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 8B10FEB64DD for ; Fri, 21 Jul 2023 03:19:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24D03280185; Thu, 20 Jul 2023 23:19:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D5F928004C; Thu, 20 Jul 2023 23:19:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04F98280185; Thu, 20 Jul 2023 23:19:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E137E28004C for ; Thu, 20 Jul 2023 23:19:27 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A9FCC1A00C5 for ; Fri, 21 Jul 2023 03:19:27 +0000 (UTC) X-FDA: 81034163574.02.68A0CC9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id AE433140005 for ; Fri, 21 Jul 2023 03:19:25 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rJMBGazv; spf=pass (imf26.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689909565; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hBkaesJwVREKeZL4yZtB8GU3JN9BxPcUY+gMay0RI6s=; b=YJo04LCUFzSlqMaDD0x4sApLCkEs2FrZNNwrf3s5tJ0g+26AsYrA9hU6QBtE0tJstDKaO2 7Ey40QrrKPNcPTNbMDqhDEQkyRYP8vnfmmuQ/MNFB49Cx37OIHss1+I0ZaQr6cFh4cbfAf WONXiw6SBOsnwApaiwPEyF8JeTvL0AI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689909565; a=rsa-sha256; cv=none; b=Qoup1LdKarEffvE2672GPDIC+zKf6z5s4doUk0OOBSavgMx01dnIRG3lOT/hyWLcbZkGLr JbvaUOjKFmgtOh7VGmHlmDn7hmr6ED0DeK+5vT2j8vrDWk/AQ/NRAA1xBfpCc24WjW8hrm PXN6JEmIs+SGfbeDoiABBWaIqLkp2EU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rJMBGazv; spf=pass (imf26.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B857761CEB for ; Fri, 21 Jul 2023 03:19:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BBCEC433CD for ; Fri, 21 Jul 2023 03:19:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689909564; bh=V/OXNG6zPguF5qEXosea/5A6BJp3v4nag/2pRCLc2+I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=rJMBGazvmlP0TdSDaKPYbCDFevCHREuL6Y3GIPYynjYg8ApPxaJxgVUUusYw5ww3k YfEkygf8jbyB7sKSb+LUcjf0lVys3HWMUQkQXvJhOAuLDes7sUAXo+fQBX7EmXiyNm jcZkwCui1kDcm2H8XwuOjx5+LqrYZ4Dwk+OcVeBliVtt8stEoicyR69v3glmBA4Uz1 q/R3/ayODCAUGF+RzdL9TDkg5sTqc8n6+7bItUYFXeNenIXcCst5pPohmx0GkT3OTN LKqI4DpYyjy/WfdZWU40GTKzlRKrOm8CdXWXDsCiKOsuGTeUkWbHSeV4eZj2OoDI60 9ZmfFkk4ypwZg== Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5216569f9e3so2059002a12.0 for ; Thu, 20 Jul 2023 20:19:24 -0700 (PDT) X-Gm-Message-State: ABy/qLYfRPDShhqzMdFJmfA4+KFJDtn8//JIuNqhT+KJcuy3WwdRtw/f aCC9tlrMZPfNlzC2EgPNWOlIyGFKqAtq4WkXv6c= X-Google-Smtp-Source: APBJJlHtcQArfaoivwJcVMJUjBCPE2XGcT7dnhNaBhtR09ldTNaYe3BWrdF9AiL0C8O3ki6SeK6xXf45KZRMwmzqOcM= X-Received: by 2002:aa7:dcc7:0:b0:515:1e50:5498 with SMTP id w7-20020aa7dcc7000000b005151e505498mr505713edu.15.1689909562263; Thu, 20 Jul 2023 20:19:22 -0700 (PDT) MIME-Version: 1.0 References: <20230719082732.2189747-1-lienze@kylinos.cn> <20230719082732.2189747-5-lienze@kylinos.cn> <87lefaez31.fsf@kylinos.cn> In-Reply-To: <87lefaez31.fsf@kylinos.cn> From: Huacai Chen Date: Fri, 21 Jul 2023 11:19:10 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/4] LoongArch: Add KFENCE support To: Enze Li Cc: kernel@xen0n.name, loongarch@lists.linux.dev, glider@google.com, elver@google.com, akpm@linux-foundation.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, zhangqing@loongson.cn, yangtiezhu@loongson.cn, dvyukov@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: AE433140005 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 5fbi1hnjg5bftp3wj4zx71brbp9y6f1u X-HE-Tag: 1689909565-684725 X-HE-Meta: U2FsdGVkX18HaEXVtwtFMooJyskVRTEjq7ObFF52SQETtyo9nk+GgBfDMdPbDbis/E6I9zxJ9Aigi/F4AvBOXzEC7WpilW1xD1gPXKY5aqDdNo6uVfITTxYoFB0wFitqjt7DSJIxndppsRRRtwi4JVj9SOdfJWzbOySTsxdFGH63Hsl51cg5hWJx25UfbKGkH1sGGXwe6c+MvmCcrJLcfJRa0z1571/6rlKTIK92xt7+PdVuENixtW4XJmVNIkt1rw72xegH/XR9NW2WbeyGokEAdvydcip42ruUadp04G0DGF5DT8K4rooh3U9D7NDFJ1MMPrnDnHacFGS6ZXje2gblo6uIRa0+BlVkmRUgZVqM/eUk5g9wIglBOuvGRUaxjJBf/6aZBv+fCuM3fph1eHuMw6WdQtYTA9Pbh2DBksxnOwDxbascptct2RSy2uzVQN4iY6r4lPOwxv68swS1oeTCkiV5MCtYopubHH0SaCD5Eb+h+x5SEnvL0TzLs9CmnmuplLprVkcb1vPP3n2Ifh6kvgCY+Ybr3VNvUquRRRIUsW/WXQ8cI7NrfNOi+OJFgBr2qYrqTTWhVTwbT8t4bqkoTlhWlRGI84xDMeGVgcP41CJSNQprxLmvwyXaXFyOe8MgPB4Gg7e2gosVdbwVGMM/LK7bo4jsrk/LNiINKLgum0XIB10vY/OcSVCbzP6gp2vjZqeKfq7Rarnuxj4GzTO0PMRshtTqmUxk4nX/t6lPsTF3r0V8AgOY0AFZaOnc68XNzN+Ookmg6pwC498IZxZG34KdaCpoJy9q6U5aPnfL0AKiSr2f04JeGxKPK35GTrRc9STlqkJUsx9kXd82XPS6JdjfYdACAz1vDBiJWnrip+G21xFwE6n1h6lUopZ62PVd9mGMpprG2c+/q/1Mj54rvGQK2A95wH3H/UsgyC9buJYwTAoYt7ugULRi25mxehBvQo/zwrQgcahv/CU 4bb69eb1 BiWefhQFZrzlgp0p/sAKOJEO4GO5yoiv/KFXcoCNiewhRrsMc007OLQm3FCMfGMfD7qsr82p6+YmYd+mqNor5e+9d7JGIJ1v4XGVcUDuAL7LDkbQa9MaoYOArKGGqx7S0WYCb5IxfQTYMWnupyOge2f21xGhWvBRa34BgEHa8Mi/l4CIppJ86LgFSFRoWbcw2TQ1b3cCZIH96I0CJDsC+UBqJRLAYKw2GawA0RqC7K6O4mNABKYaeVGTf5E7k/hUiu95ezVpcTzBxx+SP+8lQqiPtqyxBIXS3DZtaWD+1cz+2ZVxCrV0n05jiSgGGHprnyLNhzwGc0f6vZAVwklsAHO8HeiA8q6YIy1HuvLqWRR5fG0TEO/kRZmlfRPhGbjFLXdankv2jUjbwOT0LBb3ctd+1lQ== 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: Hi, Enze, On Fri, Jul 21, 2023 at 11:14=E2=80=AFAM Enze Li wrote: > > On Wed, Jul 19 2023 at 11:27:50 PM +0800, Huacai Chen wrote: > > > Hi, Enze, > > > > On Wed, Jul 19, 2023 at 4:34=E2=80=AFPM Enze Li wro= te: > >> > >> The LoongArch architecture is quite different from other architectures= . > >> When the allocating of KFENCE itself is done, it is mapped to the dire= ct > >> mapping configuration window [1] by default on LoongArch. It means th= at > >> it is not possible to use the page table mapped mode which required by > >> the KFENCE system and therefore it should be remapped to the appropria= te > >> region. > >> > >> This patch adds architecture specific implementation details for KFENC= E. > >> In particular, this implements the required interface in . > >> > >> Tested this patch by using the testcases and all passed. > >> > >> [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-= EN.html#virtual-address-space-and-address-translation-mode > >> > >> Signed-off-by: Enze Li > >> --- > >> arch/loongarch/Kconfig | 1 + > >> arch/loongarch/include/asm/kfence.h | 62 +++++++++++++++++++++++++++= + > >> arch/loongarch/include/asm/pgtable.h | 6 +++ > >> arch/loongarch/mm/fault.c | 22 ++++++---- > >> 4 files changed, 83 insertions(+), 8 deletions(-) > >> create mode 100644 arch/loongarch/include/asm/kfence.h > >> > >> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig > >> index 5411e3a4eb88..db27729003d3 100644 > >> --- a/arch/loongarch/Kconfig > >> +++ b/arch/loongarch/Kconfig > >> @@ -93,6 +93,7 @@ config LOONGARCH > >> select HAVE_ARCH_JUMP_LABEL > >> select HAVE_ARCH_JUMP_LABEL_RELATIVE > >> select HAVE_ARCH_KASAN > >> + select HAVE_ARCH_KFENCE if 64BIT > > "if 64BIT" can be dropped here. > > > > Fixed. > > >> select HAVE_ARCH_MMAP_RND_BITS if MMU > >> select HAVE_ARCH_SECCOMP_FILTER > >> select HAVE_ARCH_TRACEHOOK > >> diff --git a/arch/loongarch/include/asm/kfence.h b/arch/loongarch/incl= ude/asm/kfence.h > >> new file mode 100644 > >> index 000000000000..2a85acc2bc70 > >> --- /dev/null > >> +++ b/arch/loongarch/include/asm/kfence.h > >> @@ -0,0 +1,62 @@ > >> +/* SPDX-License-Identifier: GPL-2.0 */ > >> +/* > >> + * KFENCE support for LoongArch. > >> + * > >> + * Author: Enze Li > >> + * Copyright (C) 2022-2023 KylinSoft Corporation. > >> + */ > >> + > >> +#ifndef _ASM_LOONGARCH_KFENCE_H > >> +#define _ASM_LOONGARCH_KFENCE_H > >> + > >> +#include > >> +#include > >> +#include > >> + > >> +static inline char *arch_kfence_init_pool(void) > >> +{ > >> + char *__kfence_pool_orig =3D __kfence_pool; > > I prefer kfence_pool than __kfence_pool_orig here. > > > > Fixed. > > >> + struct vm_struct *area; > >> + int err; > >> + > >> + area =3D __get_vm_area_caller(KFENCE_POOL_SIZE, VM_IOREMAP, > >> + KFENCE_AREA_START, KFENCE_AREA_END= , > >> + __builtin_return_address(0)); > >> + if (!area) > >> + return NULL; > >> + > >> + __kfence_pool =3D (char *)area->addr; > >> + err =3D ioremap_page_range((unsigned long)__kfence_pool, > >> + (unsigned long)__kfence_pool + KFENCE= _POOL_SIZE, > >> + virt_to_phys((void *)__kfence_pool_or= ig), > >> + PAGE_KERNEL); > >> + if (err) { > >> + free_vm_area(area); > >> + return NULL; > >> + } > >> + > >> + return __kfence_pool; > >> +} > >> + > >> +/* Protect the given page and flush TLB. */ > >> +static inline bool kfence_protect_page(unsigned long addr, bool prote= ct) > >> +{ > >> + pte_t *pte =3D virt_to_kpte(addr); > >> + > >> + if (WARN_ON(!pte) || pte_none(*pte)) > >> + return false; > >> + > >> + if (protect) > >> + set_pte(pte, __pte(pte_val(*pte) & ~(_PAGE_VALID | _PA= GE_PRESENT))); > >> + else > >> + set_pte(pte, __pte(pte_val(*pte) | (_PAGE_VALID | _PAG= E_PRESENT))); > >> + > >> + /* Flush this CPU's TLB. */ > >> + preempt_disable(); > >> + local_flush_tlb_one(addr); > >> + preempt_enable(); > >> + > >> + return true; > >> +} > >> + > >> +#endif /* _ASM_LOONGARCH_KFENCE_H */ > >> diff --git a/arch/loongarch/include/asm/pgtable.h b/arch/loongarch/inc= lude/asm/pgtable.h > >> index 0fc074b8bd48..5a9c81298fe3 100644 > >> --- a/arch/loongarch/include/asm/pgtable.h > >> +++ b/arch/loongarch/include/asm/pgtable.h > >> @@ -85,7 +85,13 @@ extern unsigned long zero_page_mask; > >> #define MODULES_VADDR (vm_map_base + PCI_IOSIZE + (2 * PAGE_SIZE)) > >> #define MODULES_END (MODULES_VADDR + SZ_256M) > >> > >> +#ifdef CONFIG_KFENCE > >> +#define KFENCE_AREA_START MODULES_END > >> +#define KFENCE_AREA_END (KFENCE_AREA_START + SZ_512M) > > Why you choose 512M here? > > > > One day I noticed that 512M can hold 16K (default 255) KFENCE objects, > which should be more than enough and I think this should be appropriate. > > As far as I see, KFENCE system does not have the upper limit of this > value(CONFIG_KFENCE_NUM_OBJECTS), which could theoretically be any > number. There's another way, how about setting this value to be > determined by the configuration, like this, > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +#define KFENCE_AREA_END \ > + (KFENCE_AREA_START + (CONFIG_KFENCE_NUM_OBJECTS + 1) * 2 * PAGE_SIZE) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D How does other archs configure the size? > > >> +#define VMALLOC_START KFENCE_AREA_END > >> +#else > >> #define VMALLOC_START MODULES_END > >> +#endif > > I don't like to put KFENCE_AREA between module and vmalloc range (it > > may cause some problems), can we put it after vmemmap? > > I found that there is not enough space after vmemmap and that these > spaces are affected by KASAN. As follows, > > Without KASAN > ###### module 0xffff800002008000~0xffff800012008000 > ###### malloc 0xffff800032008000~0xfffffefffe000000 > ###### vmemmap 0xffffff0000000000~0xffffffffffffffff > > With KASAN > ###### module 0xffff800002008000~0xffff800012008000 > ###### malloc 0xffff800032008000~0xffffbefffe000000 > ###### vmemmap 0xffffbf0000000000~0xffffbfffffffffff > > What about put it before MODULES_START? I temporarily drop KASAN in linux-next for you. You can update a new patch version without KASAN (still, put KFENCE after vmemmap), and then we can improve further. Huacai > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > --- a/arch/loongarch/include/asm/pgtable.h > +++ b/arch/loongarch/include/asm/pgtable.h > @@ -82,7 +82,14 @@ extern unsigned long zero_page_mask; > * Avoid the first couple of pages so NULL pointer dereferences will > * still reliably trap. > */ > +#ifdef CONFIG_KFENCE > +#define KFENCE_AREA_START (vm_map_base + PCI_IOSIZE + (2 * PAGE_SIZ= E)) > +#define KFENCE_AREA_END \ > + (KFENCE_AREA_START + (CONFIG_KFENCE_NUM_OBJECTS + 1) * 2 * PAGE_S= IZE) > +#define MODULES_VADDR KFENCE_AREA_END > +#else > #define MODULES_VADDR (vm_map_base + PCI_IOSIZE + (2 * PAGE_SIZE)) > +#endif > #define MODULES_END (MODULES_VADDR + SZ_256M) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > Best Regards, > Enze > > >> > >> #ifndef CONFIG_KASAN > >> #define VMALLOC_END \ > >> diff --git a/arch/loongarch/mm/fault.c b/arch/loongarch/mm/fault.c > >> index da5b6d518cdb..c0319128b221 100644 > >> --- a/arch/loongarch/mm/fault.c > >> +++ b/arch/loongarch/mm/fault.c > >> @@ -23,6 +23,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> > >> #include > >> #include > >> @@ -30,7 +31,8 @@ > >> > >> int show_unhandled_signals =3D 1; > >> > >> -static void __kprobes no_context(struct pt_regs *regs, unsigned long = address) > >> +static void __kprobes no_context(struct pt_regs *regs, unsigned long = address, > >> + unsigned long write) > >> { > >> const int field =3D sizeof(unsigned long) * 2; > >> > >> @@ -38,6 +40,9 @@ static void __kprobes no_context(struct pt_regs *reg= s, unsigned long address) > >> if (fixup_exception(regs)) > >> return; > >> > >> + if (kfence_handle_page_fault(address, write, regs)) > >> + return; > >> + > >> /* > >> * Oops. The kernel tried to access some bad page. We'll have = to > >> * terminate things with extreme prejudice. > >> @@ -51,14 +56,15 @@ static void __kprobes no_context(struct pt_regs *r= egs, unsigned long address) > >> die("Oops", regs); > >> } > >> > >> -static void __kprobes do_out_of_memory(struct pt_regs *regs, unsigned= long address) > >> +static void __kprobes do_out_of_memory(struct pt_regs *regs, unsigned= long address, > >> + unsigned long write) > >> { > >> /* > >> * We ran out of memory, call the OOM killer, and return the u= serspace > >> * (which will retry the fault, or kill us if we got oom-kille= d). > >> */ > >> if (!user_mode(regs)) { > >> - no_context(regs, address); > >> + no_context(regs, address, write); > >> return; > >> } > >> pagefault_out_of_memory(); > >> @@ -69,7 +75,7 @@ static void __kprobes do_sigbus(struct pt_regs *regs= , > >> { > >> /* Kernel mode? Handle exceptions or die */ > >> if (!user_mode(regs)) { > >> - no_context(regs, address); > >> + no_context(regs, address, write); > >> return; > >> } > >> > >> @@ -90,7 +96,7 @@ static void __kprobes do_sigsegv(struct pt_regs *reg= s, > >> > >> /* Kernel mode? Handle exceptions or die */ > >> if (!user_mode(regs)) { > >> - no_context(regs, address); > >> + no_context(regs, address, write); > >> return; > >> } > >> > >> @@ -149,7 +155,7 @@ static void __kprobes __do_page_fault(struct pt_re= gs *regs, > >> */ > >> if (address & __UA_LIMIT) { > >> if (!user_mode(regs)) > >> - no_context(regs, address); > >> + no_context(regs, address, write); > >> else > >> do_sigsegv(regs, write, address, si_code); > >> return; > >> @@ -211,7 +217,7 @@ static void __kprobes __do_page_fault(struct pt_re= gs *regs, > >> > >> if (fault_signal_pending(fault, regs)) { > >> if (!user_mode(regs)) > >> - no_context(regs, address); > >> + no_context(regs, address, write); > >> return; > >> } > >> > >> @@ -232,7 +238,7 @@ static void __kprobes __do_page_fault(struct pt_re= gs *regs, > >> if (unlikely(fault & VM_FAULT_ERROR)) { > >> mmap_read_unlock(mm); > >> if (fault & VM_FAULT_OOM) { > >> - do_out_of_memory(regs, address); > >> + do_out_of_memory(regs, address, write); > >> return; > >> } else if (fault & VM_FAULT_SIGSEGV) { > >> do_sigsegv(regs, write, address, si_code); > >> -- > >> 2.34.1 > >> > >> >