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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AA04C433E2 for ; Tue, 8 Sep 2020 16:15:55 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4871C207DE for ; Tue, 8 Sep 2020 16:15:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="C7jJ/A9D"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="QS9QO1x/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4871C207DE Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YLb2IGZlLEE4OIjejspxsrL4RajH+U3cT/HSZ9fFnYA=; b=C7jJ/A9DR0MTmDluxdhdUlGLd wwWEQeDrE2YkwAj7LrlykbxFYYPNu+FuKl6RhKQBc2ds2qz5zg7SR+7ZL71wXB6SoD6UdbtWofdDr SAHKmREnJ2WhCPSQKoUNsKLWhmYItJDDr/cki22n8stb9MBaILVGREwTRv2aVH7ngGYIEAARr2tWx Hks1hTYwRmdldYw9gKMtfjG5Yn3BZd2QSUzjT24ktW0pyQBXbThGtVjMp+4av/VERCFz29O2E5b96 1bcOdgtsuRT6PhjCWz88tozLqxwtrXsEde43x/R1NZf3qEnga14nKwca9qyhZYUSe6HD6RfS3RMDw Drjp7RTbA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFgGT-0002jL-5J; Tue, 08 Sep 2020 16:14:37 +0000 Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFgGQ-0002iG-Id for linux-arm-kernel@lists.infradead.org; Tue, 08 Sep 2020 16:14:35 +0000 Received: by mail-wr1-x442.google.com with SMTP id w5so19748619wrp.8 for ; Tue, 08 Sep 2020 09:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PYj2kwCEYY4tdbHxlRk9vou/mFIHHkfUJ8u/A93HB4M=; b=QS9QO1x/9lgbsJU6BTLcNyYHtJ9WFpeN5pi0xJG2me3PX33RBPE+c0n525yXe6oQdJ uaLRImemaRtSoMGyoRIWgiIvo2dvBFsyN4TbtTMseNgXiWmvvB55h18xlAZnDR2QZEDT flDb7TOCag10jJs+v5zRDrlSRvQ4nGprHN4zBQMc0613mOkXR+VI57xCoTClyosNV93C nGBzCod/Od9AepmU4go6SBSN3VFxU8efzbxV0BtPGUh68MrdymX9OPUJjpOLKU2pUxkb gSONWBTfoo9aovSVPwCj9m8gDVIgK4Xlg2JxFPvp023w/WvsdDWRNIVrdw06eUGkqQht H2qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PYj2kwCEYY4tdbHxlRk9vou/mFIHHkfUJ8u/A93HB4M=; b=RgSgHP37Q69oC7ushOabTMqopyDIqotvCRagImkedW1VIeRykLINL3rAMsZyEqHJBB qYwjv73EfwOe3mICprVOLKPCRMkKY6ErwB0mQp95imL7oU/udiIvvQwaW47zjV0Hpl69 UsyZL41ZSdSZDez0omF2U6UmT514Y/QMBOe54YTrTv3krXnHuJFvchEU9TICFCZyXZvj G8tNlzd4+HzhO+hRAF8IOdGiub9DXna4IqjJapULKtqqnnbX69xtO0mxq9JX/tED6716 m8qA7YUKwu0mUsBJIcbvUauFYr5qWVtwhmDhN903pLPPJGRdQ0Y/NBhrmtZ4Y+I/mHg2 1MdQ== X-Gm-Message-State: AOAM531sXbWEQCJ7uarzCfoQHfNshTO4Rz2w0YoczBpRqr8HTz/IPh/l zGNCZ59IALLjqq7tqsEXrdEB0g== X-Google-Smtp-Source: ABdhPJyJIxgShgMR+/VmIkSkZNiJraMvDiBMk8Xb1BrfHZpXoQzGv7wnDPpDTm1CJvMdkrVu3mNk+g== X-Received: by 2002:adf:e481:: with SMTP id i1mr351083wrm.391.1599581673254; Tue, 08 Sep 2020 09:14:33 -0700 (PDT) Received: from elver.google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id l19sm33290410wmi.8.2020.09.08.09.14.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 09:14:32 -0700 (PDT) Date: Tue, 8 Sep 2020 18:14:26 +0200 From: Marco Elver To: Dave Hansen Subject: Re: [PATCH RFC 09/10] kfence, Documentation: add KFENCE documentation Message-ID: <20200908161426.GD61807@elver.google.com> References: <20200907134055.2878499-1-elver@google.com> <20200907134055.2878499-10-elver@google.com> <3e87490e-3145-da2e-4190-176017d0e099@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3e87490e-3145-da2e-4190-176017d0e099@intel.com> User-Agent: Mutt/1.14.4 (2020-06-18) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_121434_644617_BAB4463F X-CRM114-Status: GOOD ( 28.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, linux-doc@vger.kernel.org, peterz@infradead.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, linux-mm@kvack.org, edumazet@google.com, glider@google.com, hpa@zytor.com, cl@linux.com, will@kernel.org, corbet@lwn.net, x86@kernel.org, kasan-dev@googlegroups.com, mingo@redhat.com, linux-arm-kernel@lists.infradead.org, rientjes@google.com, aryabinin@virtuozzo.com, keescook@chromium.org, paulmck@kernel.org, jannh@google.com, andreyknvl@google.com, bp@alien8.de, luto@kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, dvyukov@google.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, penberg@kernel.org, cai@lca.pw, iamjoonsoo.kim@lge.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 08, 2020 at 08:54AM -0700, Dave Hansen wrote: > On 9/7/20 6:40 AM, Marco Elver wrote: > > +The most important parameter is KFENCE's sample interval, which can be set via > > +the kernel boot parameter ``kfence.sample_interval`` in milliseconds. The > > +sample interval determines the frequency with which heap allocations will be > > +guarded by KFENCE. The default is configurable via the Kconfig option > > +``CONFIG_KFENCE_SAMPLE_INTERVAL``. Setting ``kfence.sample_interval=0`` > > +disables KFENCE. > > + > > +With the Kconfig option ``CONFIG_KFENCE_NUM_OBJECTS`` (default 255), the number > > +of available guarded objects can be controlled. Each object requires 2 pages, > > +one for the object itself and the other one used as a guard page; object pages > > +are interleaved with guard pages, and every object page is therefore surrounded > > +by two guard pages. > > Is it hard to make these both tunable at runtime? The number of objects is quite hard, because it really complicates bookkeeping and might also have an impact on performance, which is why we prefer the statically allocated pool (like on x86, and we're trying to get it for arm64 as well). The sample interval is already tunable, just write to /sys/module/kfence/parameters/sample_interval. Although we have this (see core.c): module_param_named(sample_interval, kfence_sample_interval, ulong, IS_ENABLED(CONFIG_DEBUG_KERNEL) ? 0600 : 0400); I was wondering if it should also be tweakable on non-debug kernels, but I fear it might be abused. Sure, you need to be root to change it, but maybe I'm being overly conservative here? If you don't see huge problems with it we could just make it 0600 for all builds. > It would be nice if I hit a KFENCE error on a system to bump up the > number of objects and turn up the frequency of guarded objects to try to > hit it again. That would be a really nice feature for development > environments. Indeed, which is why we also found it might be useful to tweak sample_interval at runtime for debug-kernels. Although I don't know how much luck you'll have hitting it again. My strategy at that point would be to take the stack traces, try to construct test-cases for those code paths, and run them through KASAN (if it isn't immediately obvious what the problem is). > It would also be nice to have a counter somewhere (/proc/vmstat?) to > explicitly say how many pages are currently being used. You can check /sys/kernel/debug/kfence/stats. On a system I just booted: [root@syzkaller][~]# cat /sys/kernel/debug/kfence/stats enabled: 1 currently allocated: 18 total allocations: 105 total frees: 87 total bugs: 0 The "currently allocated" count is the currently used KFENCE objects (of 255 for the default config). > I didn't mention it elsewhere, but this work looks really nice. It has > very little impact on the core kernel and looks like a very nice tool to > have in the toolbox. I don't see any major reasons we wouldn't want to > merge after our typical bikeshedding. :) Thank you! -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel