Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp89181pxb; Mon, 8 Nov 2021 10:12:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJzhpncejp4tmWHn9buQtihCkhk1CvNk3f/4URVm6XtLbT60iyj8y+8+xYHXZhUfQqtbu6iE X-Received: by 2002:a05:6e02:1b09:: with SMTP id i9mr704042ilv.111.1636395168507; Mon, 08 Nov 2021 10:12:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636395168; cv=none; d=google.com; s=arc-20160816; b=NBNoITzRg2eVcaIDFNaVadW92dE+cOle+OId4D+g9pISij0zURoLwwG+DRpDwJqrnJ J36IYum/95zS9elBsTwL031E0VPcqfDkYLL04WqyScP5O5UbKqEq+herSjHhmwfV1gSP FH1MRAndtP1xEX5FxusQuyC24ITo+8t7PRjV4qtpZsz8Wa6QXXQvUdAkib0yShcqENzL Xnp+7b81uMECC9CdviVml23p4ZBnHnXTVDdetcxvQI+VliIVYQzqrXwO+3mb5mI3Nf0I moVn9zBfiDzIUQ7/U4B3DGH33/FcG14eERwPrawAtDWNjjzEEA0Q2lGQtmizRw2/Mj7n NU8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=oWxAh99exjntWaHx951+lk35+JEy7HDXRjBJyaOouWU=; b=O9LbNSVvU2husi8oi/p0QKK/1OshQ9Q6b7WGi6sV8MHqpAK52JssWvlTEeHChlgMPx lYN49X+ZF/D18rhclvgVDM7m3mgPrw0XStyJTANa9un36DtUOqHCxHT90RDZWW3TKnCX VK26Xku1UHI5FU9bqJ3RouPOFclC6QyQrttcbNarAl1o9pbiYBQN2I4+o5nAMNz8RC3v o0oj3MeXLmrVNAmIUC1A00TtH+u+UN5uLS54lrKwdLdhWYdTs4lx2aev0WZN8nkYRW1R YQjUA7h5sO60Qy71/MC7SJj+8lRT4kG+3VcKkJWX7rTWwuf2K6gyvIeX4xxcaveVd0hY OYPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=TMWKPx9M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a1si2231549ilr.21.2021.11.08.10.12.35; Mon, 08 Nov 2021 10:12:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=TMWKPx9M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232912AbhKHMZp (ORCPT + 99 others); Mon, 8 Nov 2021 07:25:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237550AbhKHMZo (ORCPT ); Mon, 8 Nov 2021 07:25:44 -0500 Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3651EC061746 for ; Mon, 8 Nov 2021 04:23:00 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id o15-20020a9d410f000000b0055c942cc7a0so2485436ote.8 for ; Mon, 08 Nov 2021 04:23:00 -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:content-transfer-encoding; bh=oWxAh99exjntWaHx951+lk35+JEy7HDXRjBJyaOouWU=; b=TMWKPx9Mlu1gt1Dsql9V5i6foiLkmYoluQWW2TZGLNH9JOIfWbU3kOAlTrgWmJU18L 6t+dAkMC0bLe9uBOUXznq2AchZWKNXA8QGz1X5dGFyuODtusu3svwNtw42mDoyLY2c1z n0q7RrPftmR6gKSGND2PkG+Io+Cb9i2PzKvOrGbg3Vt6sRTQQCgossWdxIM4/1rm2GDY AqMzY4atHP5Nmn6iaNooPg0xfx4Lgu451Ie6jcjWyrH9kMsVRCxJ5fJ0mcl9klsHLC7L 4xte54RsrSavj+bV+2BjwG30ATpN8QSaIKLXmVQgv1i+vmexgkEKcDvnWfyjOUM5iGqQ JAMg== 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:content-transfer-encoding; bh=oWxAh99exjntWaHx951+lk35+JEy7HDXRjBJyaOouWU=; b=DNEUb139sVx9Z6hB8K+uAkMHuaY/JT3UGKKjIMEpAjPkk/UDPlx0WULiK0lxEQrtzP DLIxficms8GJ/tSSdrSpwr8iyr+H1rcOHDx/iDO5u8hZlN4tRrrHl9v4JsQVv4SoTVjR a14nE+bAyqAGuT2XaI3yE0K+hjppTnpZ0vPgKr+crU2LTC9LFVsmdaGRm3Rhvd2gLumS U8i0LLYym8O/trBpvKZLSlkBED0w0o3fp3b9Ey8N3EjZS1NOOZ09BGQAxsKad89inSAW dV6JMn4OLqzPv4m28ITNczz+ZUnnNbVxRixE9C1NZ7K3DXv5Plmvf7SLw0LverRa39ex QhfA== X-Gm-Message-State: AOAM5321E7LST07UaAw5HY2gjgbmuQks4vu/Ru6YZTnE+iLX3E1X8Ffq 1xirvwoUS61Fuzqdc8sKtoGl7dgyaQMoHpjhgWtz8w== X-Received: by 2002:a9d:2ac2:: with SMTP id e60mr60084401otb.92.1636374179281; Mon, 08 Nov 2021 04:22:59 -0800 (PST) MIME-Version: 1.0 References: <20211101103158.3725704-1-jun.miao@windriver.com> <96f9d669-b9da-f387-199e-e6bf36081fbd@windriver.com> <20211103181315.GT880162@paulmck-ThinkPad-P17-Gen-1> <20211103212117.GA631708@paulmck-ThinkPad-P17-Gen-1> <309b8284-1c31-7cc4-eb40-ba6d8d136c09@windriver.com> <20211104012843.GD641268@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: From: Marco Elver Date: Mon, 8 Nov 2021 13:22:47 +0100 Message-ID: Subject: Re: [PATCH] rcu: avoid alloc_pages() when recording stack To: Dmitry Vyukov Cc: paulmck@kernel.org, kasan-dev , Jun Miao , Uladzislau Rezki , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , qiang.zhang1211@gmail.com, RCU , LKML , miaojun0823@163.com, ryabinin.a.a@gmail.com, Alexander Potapenko , jianwei.hu@windriver.com, melver@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 8 Nov 2021 at 12:42, 'Dmitry Vyukov' via kasan-dev wrote: [...] > > > > > > Reviewed-by: Uladzislau Rezki (Sony) > > > > > I have queued it for review and testing, thank you both! I do ha= ve > > > > > some remaining concerns about this code being starved for memory.= I am > > > > > wondering if the code needs to check the interrupt state. And pe= rhaps > > > > > also whether locks are held. I of course will refrain from sendi= ng > > > > > this to mainline until these concerns are resolved. > > > > > > > > > > Marco, Dmitry, thoughts? It's a general limitation of kasan_record_aux_stack_noalloc(), and if stackdepot's pool is exhausted, we just don't record the stacktrace. But given we just can't allocate any memory at all, I think it's the best we can do. However, given there are enough normal (with allocation allowed) uses of stackdepot with KASAN enabled, the chances of stackdepot having exhausted its pool when calling this are small. The condition when recording the stack with the _noalloc() variant would fail is: stackdepot runs out of space AND the same stack trace has not been recorded before. And the only time we'd notice this is if we actually hit a kernel bug that KASAN wants to report. The aggregate probability of all this happening is very very low. The original series has some more explanation: https://lkml.kernel.org/r/20210913112609.2651084-1-elver@google.com > > > > Well, the compiler does have an opinion: > > > > > > > > kernel/rcu/tree.c: In function =E2=80=98__call_rcu=E2=80=99: > > > > kernel/rcu/tree.c:3029:2: error: implicit declaration of function = =E2=80=98kasan_record_aux_stack_noalloc=E2=80=99; did you mean =E2=80=98kas= an_record_aux_stack=E2=80=99? [-Werror=3Dimplicit-function-declaration] > > > > 3029 | kasan_record_aux_stack_noalloc(head); > > > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > | kasan_record_aux_stack > > > > > > > > I get the same message after merging in current mainline. > > > > > > > > I have therefore dropped this patch for the time being. > > > > > > > > Thanx, Pau= l > > > Hi Paul E, > > > The kasan_record_aux_stack_noalloc() is just introduce to linux-next = now, > > > and marking "Notice: this object is not reachable from any branch." i= n > > > commit. > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/c= ommit/include/linux/kasan.h?h=3Dnext-20211029&id=3D2f64acf6b653d01fbdc92a69= 3f12bbf71a205926 "Notice: this object is not reachable from any branch." because it kept changing the hash since it's in the -mm tree. > > That would explain it! Feel free to resend once the functionality is > > more generally available. > > +kasan-dev@googlegroups.com mailing list > > I found the full commit with kasan_record_aux_stack_noalloc() implementat= ion: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commi= t/?h=3Dnext-20211029&id=3D2f64acf6b653d01fbdc92a693f12bbf71a205926 > > but it calls kasan_save_stack() with second bool argument, and > kasan_save_stack() accepts only 1 argument: > https://elixir.bootlin.com/linux/latest/source/mm/kasan/common.c#L33 > so I am lost and can't comment on any of the Paul's questions re > interrupts/spinlocks. None of the kasan_record_aux_stack_noalloc() code and its dependencies were in mainline yet. I think it landed a few days ago, but too late for the patches here.