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 9941DC43334 for ; Fri, 1 Jul 2022 10:34:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF9EC6B0073; Fri, 1 Jul 2022 06:34:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA6C36B0074; Fri, 1 Jul 2022 06:34:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6E526B0075; Fri, 1 Jul 2022 06:34:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C946F6B0073 for ; Fri, 1 Jul 2022 06:34:54 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 98E6E21248 for ; Fri, 1 Jul 2022 10:34:54 +0000 (UTC) X-FDA: 79638172908.23.4971A3B Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf03.hostedemail.com (Postfix) with ESMTP id B0FD920039 for ; Fri, 1 Jul 2022 10:34:53 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id a13so3087294lfr.10 for ; Fri, 01 Jul 2022 03:34:53 -0700 (PDT) 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=r9tKEj16d5tR2G+qnALq6e2umf1wAchyZTQfWhHn/lQ=; b=hOWskhaT9BnBIvhYHwEipW3tIPTPzs+uwhJQcQvKiX36zsPu3hbdGi8car8k4C3Nv4 a6jxrlWgQRh9j0Jd3iCSsI3CPEJzdXY1sutH2NrQJ/KpqS+zPNvUYv/xARIGCRgIqcwu P/NAQjBIxMV9QslcP9CZrDbXa3KC57R3bnGRB/4DOPcKG/V3VD/V4K+kVa/1Y6wmhvCs cPq67bZWiz9SS8D9C8PNjVBnuCkOSzQVjwmFQHqcSbTiNzjTF/H9M2aQFrEybJFd6duW jlLYHBlYx1BcpPQ41+nKa34vmIlYNmKk9wOeAnJCYZNEzdKAuhmfXTaSY0rryr1usjYj jJ2Q== 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=r9tKEj16d5tR2G+qnALq6e2umf1wAchyZTQfWhHn/lQ=; b=TtD2rJJDn/eUwQoZP0h7Y1kIsTM0RQTrmNGOJX4FDFTcRLVoeDDhgDnc9Y1PCfXa4V yrv1I/DQSR04FWtWmGD7JFutqDHPUB44x4GxP4fjC2TMVTmZqS4QmSJDtqDnTdjBw6JA 04it1LZboFnc3NyW1IztuLx4/W9NL/gMWop0aRMcnbcHiFfpJg/u0uxuHbPH6P5srXPL EbWoDDu9X98+OrcHkkXNf6RQ4uYi1dLmc+PZbonw9aqd8l2Hl9HnZ+aMPUKt+oJuOQdi +ttN5zRgKuYljkA4DNpCC2q/4wMkuipFMCtDhyX6LOoX5gKzqU/GnHWBmjOKHWe+vA9S HJtA== X-Gm-Message-State: AJIora+aps5g7dhOuBfMeeey+PkQc5Km7Pqg8BGBTv9eLDOtgY8P6Mc+ Ei3g7qqyEGxQ7tBM4UOTAo7L+8ptOHc6js/Uh4STug== X-Google-Smtp-Source: AGRyM1v5FUVOat6gmgFRKbQSnfiJy8R8hSU6Xh0lZv1nXMkdfAeKL5kC85n2Od+ElP7r82Pw5f9ECw9k9nrZtDTko/w= X-Received: by 2002:a05:6512:10c3:b0:47f:a97e:35c with SMTP id k3-20020a05651210c300b0047fa97e035cmr8666355lfg.417.1656671686899; Fri, 01 Jul 2022 03:34:46 -0700 (PDT) MIME-Version: 1.0 References: <20220630080834.2742777-1-davidgow@google.com> <20220630080834.2742777-2-davidgow@google.com> <20220630125434.GA20153@axis.com> <20220701091653.GA7009@axis.com> <20220701100441.GA8082@axis.com> In-Reply-To: <20220701100441.GA8082@axis.com> From: Dmitry Vyukov Date: Fri, 1 Jul 2022 12:34:35 +0200 Message-ID: Subject: Re: [PATCH v4 2/2] UML: add support for KASAN under x86_64 To: Vincent Whitchurch Cc: David Gow , Andrey Konovalov , Johannes Berg , Patricia Alfonso , Jeff Dike , Richard Weinberger , "anton.ivanov@cambridgegreys.com" , Brendan Higgins , Andrew Morton , Andrey Ryabinin , kasan-dev , "linux-um@lists.infradead.org" , LKML , Daniel Latypov , "linux-mm@kvack.org" , "kunit-dev@googlegroups.com" Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656671693; 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=r9tKEj16d5tR2G+qnALq6e2umf1wAchyZTQfWhHn/lQ=; b=ytYMCr27x6O6En6DNIvkqJAWPXhvUHfpyKSNFmvsZGXyOz9bhJ54qu4sKygSjnj0/EfalD IwkfyVZrgjgO5WVqitNEWOIkq5yniuiIJrnh9C8AT6YSHys0Z6GQgu6/ruI+TtUOEjSqnK 8F81TOMVIORDaD5O9hMwWn0Pa+64Bjw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656671693; a=rsa-sha256; cv=none; b=7drGU3L5eU5403a5offUByoc7VhHceGeU1939LnaAHtvLPzB4MWhPDZBDTSxrMO5vgv4gU PKngX3gfKrBiO/KDoQ3+7SqQpdClAwCbEKVnpUgG3bDkNam4Yg4gK9eb7zccitBSiW2jo+ kmXu1+CPTk6n5i66i/yQ8xiHBObb1hE= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hOWskhaT; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of dvyukov@google.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=dvyukov@google.com X-Stat-Signature: oosu7koki4n83otomdwy6et3d4xj76jz X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hOWskhaT; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of dvyukov@google.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=dvyukov@google.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B0FD920039 X-HE-Tag: 1656671693-956892 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 Fri, 1 Jul 2022 at 12:04, Vincent Whitchurch wrote: > > wrote: > > > On Fri, Jul 01, 2022 at 11:08:27AM +0200, David Gow wrote: > > > > On Thu, Jun 30, 2022 at 9:29 PM Andrey Konovalov wrote: > > > > > Stack trace collection code might trigger KASAN splats when walking > > > > > stack frames, but this can be resolved by using unchecked accesses. > > > > > The main reason to disable instrumentation here is for performance > > > > > reasons, see the upcoming patch for arm64 [1] for some details. > > > > > > > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=802b91118d11 > > > > > > > > Ah -- that does it! Using READ_ONCE_NOCHECK() in dump_trace() gets rid > > > > of the nasty recursive KASAN failures we were getting in the tests. > > > > > > > > I'll send out v5 with those files instrumented again. > > > > > > Hmm, do we really want that? In the patch Andrey linked to above he > > > removed the READ_ONCE_NOCHECK() and added the KASAN_SANITIZE on the > > > corresponding files for arm64, just like it's already the case in this > > > patch for UML. > > > > Personally, I'm okay with the performance overhead so far: in my tests > > with a collection of ~350 KUnit tests, the total difference in runtime > > was about ~.2 seconds, and was within the margin of error caused by > > fluctuations in the compilation time. > > > > As an example, without the stacktrace code instrumented: > > [17:36:50] Testing complete. Passed: 364, Failed: 0, Crashed: 0, > > Skipped: 47, Errors: 0 > > [17:36:50] Elapsed time: 15.114s total, 0.003s configuring, 8.518s > > building, 6.433s running > > > > versus with it instrumented: > > [17:35:40] Testing complete. Passed: 364, Failed: 0, Crashed: 0, > > Skipped: 47, Errors: 0 > > [17:35:40] Elapsed time: 15.497s total, 0.003s configuring, 8.691s > > building, 6.640s running > > OK, good to know. > > > That being said, I'm okay with disabling it again and adding a comment > > if it's slow enough in some other usecase to cause problems (or even > > just be annoying). That could either be done in a v6 of this patchset, > > or a follow-up patch, depending on what people would prefer. But I'd > > not have a problem with leaving it instrumented for now. > > I don't have any strong opinion either way either, so you don't have to > change it back on my account. Thanks. I would consider using READ_ONCE_NOCHECK() by default. And then switching to KASAN_SANITIZE:=n only if there is a real reason for that. Disabling instrumentation of any part of the kernel makes things faster, but at the same time we are losing checking coverage. For arm it was done for a very specific reason related to performance. While UML can be considered more test-oriented rather than production-oriented.