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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31E18C433EF for ; Wed, 8 Dec 2021 15:33:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236142AbhLHPhO (ORCPT ); Wed, 8 Dec 2021 10:37:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236132AbhLHPhL (ORCPT ); Wed, 8 Dec 2021 10:37:11 -0500 Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66081C0617A1 for ; Wed, 8 Dec 2021 07:33:39 -0800 (PST) Received: by mail-oo1-xc31.google.com with SMTP id g11-20020a4a754b000000b002c679a02b18so926928oof.3 for ; Wed, 08 Dec 2021 07:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IxIfRX4p1ShqDdqDmnt+bp423Hz8b1BolvUDyPorj8Y=; b=qY8ENfN3W0Yf9nuo152oD+q2MbKXXE68D03Y13l/idtVg4tIZ7a/92vuX5iAK6K7fG SFzn9Sd3pT+R/9WbKC4mXC4T3kvxIdUHFPKu46QpALXLcNzhIKXq6iRsrB/9RWFqUPif T/BoxlDf55/SQd0vvwmfP79E6TyeEowm9AdZu1uVsDaDZ6vOLjRWVKAR5h62CaDuZqWm b1Q/31oF0q8Cw6jGkY8zDrCBWaBfIM8O9bkYSjkwT5zVBr/83UPJigeMVkU0+TssuJut EUEVYTFyivbXDX7agrCPW49SLBfnhiykSVJ5Fpo9Mp0zgS4KMgqZQ2xflZo+yqiVr8KW Pgpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IxIfRX4p1ShqDdqDmnt+bp423Hz8b1BolvUDyPorj8Y=; b=UW5mJ+hcj+nLmrrbEYYyNMVnAwuS2OwiqZqg6o5vwuIjtipRY5rXuxEE7OCxnOT/XP G/9TxPdhrTxdj5qHFm3tvCvigzzXRq523cP+6Ccebv/WLCQqjgs8uyrb4ARvmQOlk+Fb d0oI8udc/cnENwOgJMNfeGTZ4s9vzWgeaEnQfUbYaEhQeKmo3MytIb/rWQqTVso9KgoE IX44xf3AbXeXnuGdU5K8pvyEHjpNppPnweNKrNUY1/5GVepiq0A9hj5xFEKNtLUKdAc7 UqCeoP3pd190N7iS5lS2ZtEh9fJmIem3+Di6dXa6VMfwwyWpYlUknNpAj3aE5OO3FXhW eB6g== X-Gm-Message-State: AOAM530zw/o1K1bOMNsHFpvji1ZmRrHLw+skUYPSfwaVVD+7WA9s+w9M 703XF8WD2b6mzybo8/kWfYltaDfVF4cFz/EUBEOnsA== X-Google-Smtp-Source: ABdhPJzxgoA4G0rp+2qsKYM6ma2T0oGdG17NC5ZMmsGAIXxmQb65eoU42AnrhA5/ygmcAsXJZtOV5gXtVSJRg9A0EQg= X-Received: by 2002:a4a:a5cf:: with SMTP id k15mr160987oom.70.1638977618527; Wed, 08 Dec 2021 07:33:38 -0800 (PST) MIME-Version: 1.0 References: <20211208044808.872554-1-pcc@google.com> In-Reply-To: <20211208044808.872554-1-pcc@google.com> From: Marco Elver Date: Wed, 8 Dec 2021 16:33:26 +0100 Message-ID: Subject: Re: [PATCH v3 0/6] kernel: introduce uaccess logging To: Peter Collingbourne Cc: Catalin Marinas , Will Deacon , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Thomas Gleixner , Andy Lutomirski , Kees Cook , Andrew Morton , Masahiro Yamada , Sami Tolvanen , YiFei Zhu , Mark Rutland , Frederic Weisbecker , Viresh Kumar , Andrey Konovalov , Gabriel Krisman Bertazi , Chris Hyser , Daniel Vetter , Chris Wilson , Arnd Bergmann , Dmitry Vyukov , Christian Brauner , "Eric W. Biederman" , Alexey Gladkov , Ran Xiaokai , David Hildenbrand , Xiaofeng Cao , Cyrill Gorcunov , Thomas Cedeno , Alexander Potapenko , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Evgenii Stepanov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 8 Dec 2021 at 05:48, Peter Collingbourne wrote: [...] > Peter Collingbourne (6): > include: split out uaccess instrumentation into a separate header > uaccess-buffer: add core code > fs: use copy_from_user_nolog() to copy mount() data > uaccess-buffer: add CONFIG_GENERIC_ENTRY support > arm64: add support for uaccess logging > Documentation: document uaccess logging I think it needs to be possible to disable the feature via a Kconfig option. Not all systems want or could even tolerate the additional overheads -- even though you say they are minimal elsewhere. For example, some embedded systems most likely have absolutely no use for this feature, and the increase in .text might be unacceptable. Certain features that we usually take for granted are no different (see init/Kconfig: FUTEX, EPOLL, .. etc). If you'd like it enabled by default, given the overheads are small enough, it can do "default y" and be configurable only "if EXPERT". Is it possible to add a kselftest-style test to tools/testing/selftests? In addition to the basic tests, can certain non-trivial properties, like masking of signals, also be tested? I think that'd be extremely valuable, because I'm sure we'd have to backport this to several older kernels. Thanks, -- Marco