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 6ED8AD75E5E for ; Fri, 22 Nov 2024 15:01:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C415A6B00A6; Fri, 22 Nov 2024 10:01:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BEDCE6B00AF; Fri, 22 Nov 2024 10:01:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A408C6B00B3; Fri, 22 Nov 2024 10:01:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 862AC6B00A6 for ; Fri, 22 Nov 2024 10:01:42 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 348DD4191C for ; Fri, 22 Nov 2024 15:01:42 +0000 (UTC) X-FDA: 82814041422.17.9AB7694 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by imf08.hostedemail.com (Postfix) with ESMTP id E599F16002D for ; Fri, 22 Nov 2024 15:01:03 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=n6Nm0HHp; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of elver@google.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732287607; 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=2CBrmR/4K5+pOzn9XzmrpMtqvst0Y6UbBDGLFW9ccDE=; b=tWzlBqUXN72MkoO+J5v8oZoArjqTrXUHQ1Un1LsJL6ET7Edlytq1bOz8JJrS/UJxid4iNb xg77fRq9c/GH4+v5/5ix4LRZardi4D243zYEygfhabYw0AQT0g+AUYFoRY0e2Y2r3U50Q4 wLcPfD8+A4idZrZOqxk1BRkMa5huCz8= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=n6Nm0HHp; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of elver@google.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732287607; a=rsa-sha256; cv=none; b=E2wQnDPFIH+funKcFhghwZh3x5NzWa+pV8xupCcW8pT3SXex19iAfO7qifONTHm8Un+aHo 9GAgOyo9TdWyzPmARqR2OIVY26//J84wg4eSCZxrmNttZ7pWQ4+2vrZ6J3SL+QLT8nM3m2 7gqU8ukQFZafRGEmQKIMCQs+D7yRd/Y= Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-38248b810ffso1544775f8f.0 for ; Fri, 22 Nov 2024 07:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732287698; x=1732892498; darn=kvack.org; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2CBrmR/4K5+pOzn9XzmrpMtqvst0Y6UbBDGLFW9ccDE=; b=n6Nm0HHpRRcpdnIfyB3PQ8Qx0hTvGqG2TQB11DxkBxxnaEvnn22VzQOCqZzQTLUrIG QyPQSB2oTzaSP49zFD74DyK0Z+LedThA7RU43+dXuLACz/ObxxG39Trhd52xM43crvoF w6ian7qN+6xGdQV5SCNBqxdEwgGW9lFCYB+pkOXkOmrItVPSznRV3cE+sSIdJf87QxC3 5fJAHZD3tvssU+lC1xnFit+xXEqn6jdLZ0QYGoJ6I58ToN3StX+KIxZgyD736u/Ck4mZ GSejP10iQORKf78Gx6SEnCmYDXOzFEg5Z9ZMVyG/T0V8l+6MU9SGJbSno4zIFgDKwBqw wKbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732287698; x=1732892498; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2CBrmR/4K5+pOzn9XzmrpMtqvst0Y6UbBDGLFW9ccDE=; b=hbSDHh0Sk9Wa6mr4r226UVbjhnAwymK94vVdLQ9NljlXocEXUlGUKXwj2VPLI6DLm8 1Yn8cG1Vd1pzYatJusoVzhAD8fu0D8BqDLTg4mUikBrVxAtQZq5a9LX+V6R/oC5ox3YY lmDUeuRp6Xb+nHlwoHVzCehhqVwjrnKm+B+6qfZf37xaXYkai071WyUNTVEufEWOy0SG /wena9hP6PRABze+SSeplAr9wr8Z5WMvx3yqoictrNDp1ZW3zis/EB/gBXilAkzH8SOG XDmEjZsdZfaVvXVo7YpfCiYjR5WvZWAyxkzRxUae6t1ZLGth2YW4xmtc74e19M5pPH+D L5pw== X-Forwarded-Encrypted: i=1; AJvYcCVxUm2rmCLmAHKbZKHqSFiYRBpNXRgypfa85WvrQTwTxiGWEv7cX8eX+T034oHZuX6bLeAceE7zug==@kvack.org X-Gm-Message-State: AOJu0Yz8533+EP1LLhfmXWP8ODbZiKzCe+cFZeujimEZyCkUvqx6+AWY TzyjkpezfKdUg1bUuD07iUn8o53Jh7NNuiobDTaogwxgBLEZFxQ6PAtN7TjUgA== X-Gm-Gg: ASbGncuzkXWxfQpaYmhWDGLPRJBq/ULVns9mPMV/jY4PjA3yJ8JIuKeThbLNG1ICg05 9k4vh3ocelUNbm54x2XMRbgUWaNsijUBvlrYnm1mimhiYjQ0A4LUXHkiRFQyQqv9JUWYTNrKFTy 7YSVlJ+vqqm//iQGWB0RkahTdLvp+d6AA5lEofDnEQLvD1/rq0vqHYjM8u1Jip8Ll6llBpq8abJ sfHMPnMNBlkrmvigzo3adiqfvInrxI8k8ulM437d3yLgq2YCIM= X-Google-Smtp-Source: AGHT+IFF4ahp+lojSsbIu757K7jRdjQw+mcOJ9fyXHtJSRlvd+VoIDXJnOIjlPPaqGgb9XiUJbFMLA== X-Received: by 2002:a5d:47aa:0:b0:382:3789:191c with SMTP id ffacd0b85a97d-38260b45584mr2567216f8f.7.1732287697197; Fri, 22 Nov 2024 07:01:37 -0800 (PST) Received: from elver.google.com ([2a00:79e0:9c:201:e369:a6f7:a3ea:97bb]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3825fafe3cbsm2583014f8f.38.2024.11.22.07.01.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Nov 2024 07:01:36 -0800 (PST) Date: Fri, 22 Nov 2024 16:01:29 +0100 From: Marco Elver To: Sebastian Andrzej Siewior Cc: Andrey Konovalov , Peter Zijlstra , Vlastimil Babka , syzbot , Liam.Howlett@oracle.com, akpm@linux-foundation.org, jannh@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, syzkaller-bugs@googlegroups.com, kasan-dev , Andrey Ryabinin , Alexander Potapenko , Waiman Long , dvyukov@google.com, vincenzo.frascino@arm.com, paulmck@kernel.org, frederic@kernel.org, neeraj.upadhyay@kernel.org, joel@joelfernandes.org, josh@joshtriplett.org, boqun.feng@gmail.com, urezki@gmail.com, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, qiang.zhang1211@gmail.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, tj@kernel.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, Thomas Gleixner , roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, rcu@vger.kernel.org Subject: Re: [PATCH] kasan: Remove kasan_record_aux_stack_noalloc(). Message-ID: References: <67275485.050a0220.3c8d68.0a37.GAE@google.com> <20241104114506.GC24862@noisy.programming.kicks-ass.net> <20241119155701.GYennzPF@linutronix.de> <20241122113210.QxE7YOwK@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241122113210.QxE7YOwK@linutronix.de> User-Agent: Mutt/2.2.12 (2023-09-09) X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E599F16002D X-Stat-Signature: 7pyhy4s1fwgnji7w6xjbgmxn7w9fd98h X-HE-Tag: 1732287663-614093 X-HE-Meta: U2FsdGVkX1/KJKfueZGyA8JT+tP3hLM54jR/gOZZlhcXbTuqUfO6bjZdnIZO/g4j3cvhyf8OKy3crqs4Qirs1Mw5iHnJInlcs6H04LSvjgvx6C3fixCdv61SpAX2De9uwvkL9bRnt22+xA3FvnHkn3H7Lu+1jCU4Da/UxO5NtpP+9OdsbBbF4MvpmI3cVBuY9TzIC6BDMKekaiaDaRj9rija8XpvvUSSqW9xfhayBJ4uyjon/1eo/oGEZCTMQdTCTvlBKsb8TAYp2M6F3kG2xiLzAkJBVsaPjHs7LVxrjLChcFoSqQtSKT1PkovekFSNcKhyeyuJFGL1I8bj2r5cP5WYVB3rOYVcLJAm/roAGrUH/MsN+D8BRkMIkBOvYxApnHjKj+exj0AQ6TZFcZjbz+auMJYbID2cciCyylWiM7ZT4DGh8YHpT+oKp/v9CbxeFvRTVrsu+H4Y4Xgmi6NQvaAbIuxFti019Azx7y3k12epshjOv0nukQtPKwPX4/gSqHtU969Kb9c9/Qn+4zpYwgatY3itakoSX1QS7ZDOumpsnMPzMDbisgK/iqMRwG3tE/c9IXsuX6CALSEBzuVJluG0t6hh5aPZASMFH9Q6QrtmJQTuqfuEn8Tf23Fly3EjfAdBxakReGKqa1ZtO4o4lkXLAKvS8Z9DiQawlhv86qZPCr5cWiY0aiEvUEj/FbHxsKHvJoK525ZdwaRLiNst2++oYGUFqEGjdHYId8TVlKYEmN3bsPCYZUHJmiv63mJDt62Ag9+if76p/3oEPCyWZxWNkfpwlbpiBei0/x0Lv4C51xz8359fsBnHoXnO9Era0SoUTzQ6HtZASl5dkn5gxjx8XmvWtkr7zjBBgGkFeri3T5xUn+nVzuoIh4Supoq+sFrc3Htpdd3+e1PRtSO1TVKg8aGMIEE4vTDmvwVeyDa7802Aw9WkGbCVPD6PE7lJFARTg+KKrzinleLtg2Q oxEQyTZU 19nq2CuvD/SDcw3ppUCEZsMq9Vg+92XZ+zvzCJ/0O9WeZdvVeg0U5xUxElZTSGf15iQtCvVMfrTbDfxTiHBISP1GSPjxxUBQ/dy7aylvdpILLbNfO/ZivlsWDs+geaRzMO4wswBZEFz1zCrwMsPJmCztEngW0iVM5RUZSBVmOIoEHiJOcNcnsdb11Aga5sAh0wlQVN+ch+oGF8+ikRU61VMqZdCkkYVeth/dJYswgyRUzujLUidZZ8sC8UUsEfR9lsjza8r6qPE4BUX2KLFJ7zDOrbRAs5P8eJ+lZl+NTJlFp/8EtfblFIDWFs8yYaORc5vsmgEE3oUL3bOHRq0hItHaWs9nks7o9IIYmoG3CxhNeowcHjUrGIurTQ+2ocjkkg0DaG0W+qG9td2GoS+2dLPwlhUejYeNgtC7x6dreNsrzt4F5JwOXI3MTIT2g0h0MEepWElNAsZ+X2kPieYyXOUY1KakFyrhpauqJ+w5yT31jGOjV3XyrPE7WVS1NeZqUh5yF 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: List-Subscribe: List-Unsubscribe: On Fri, Nov 22, 2024 at 12:32PM +0100, Sebastian Andrzej Siewior wrote: > On 2024-11-19 20:36:56 [+0100], Andrey Konovalov wrote: > > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c > > > index 6310a180278b6..b18b5944997f8 100644 > > > --- a/mm/kasan/generic.c > > > +++ b/mm/kasan/generic.c > > > @@ -521,7 +521,7 @@ size_t kasan_metadata_size(struct kmem_cache *cache, bool in_object) > > > sizeof(struct kasan_free_meta) : 0); > > > } > > > > > > -static void __kasan_record_aux_stack(void *addr, depot_flags_t depot_flags) > > > > Could you add a comment here that notes the usage, something like: > > > > "This function avoids dynamic memory allocations and thus can be > > called from contexts that do not allow allocating memory." > > > > > +void kasan_record_aux_stack(void *addr) > > > { > … > Added but would prefer to add a pointer to stack_depot_save_flags() > which has this Context: paragraph. Would that work? > Now looking at it, it says: > | * Context: Any context, but setting STACK_DEPOT_FLAG_CAN_ALLOC is required if > | * alloc_pages() cannot be used from the current context. Currently > | * this is the case for contexts where neither %GFP_ATOMIC nor > | * %GFP_NOWAIT can be used (NMI, raw_spin_lock). > > If I understand this correctly then STACK_DEPOT_FLAG_CAN_ALLOC must not > be specified if invoked from NMI. This will stop > stack_depot_save_flags() from allocating memory the function will still > acquire pool_lock, right? > Do we need to update the comment saying that it must not be used from > NMI or do we make it jump over the locked section in the NMI case? Good point. It was meant to also be usable from NMI, because it's very likely to succeed, and should just take the lock-less fast path once the stack is in the depot. But I think we need a fix like this for initial saving of a stack trace: diff --git a/lib/stackdepot.c b/lib/stackdepot.c index 5ed34cc963fc..245d5b416699 100644 --- a/lib/stackdepot.c +++ b/lib/stackdepot.c @@ -630,7 +630,15 @@ depot_stack_handle_t stack_depot_save_flags(unsigned long *entries, prealloc = page_address(page); } - raw_spin_lock_irqsave(&pool_lock, flags); + if (in_nmi()) { + /* We can never allocate in NMI context. */ + WARN_ON_ONCE(can_alloc); + /* Best effort; bail if we fail to take the lock. */ + if (!raw_spin_trylock_irqsave(&pool_lock, flags)) + goto exit; + } else { + raw_spin_lock_irqsave(&pool_lock, flags); + } printk_deferred_enter(); /* Try to find again, to avoid concurrently inserting duplicates. */ If that looks reasonable, I'll turn it into a patch.