Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2209324pxb; Tue, 12 Oct 2021 01:33:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxKF+IClYvjzi9DrlBAihbbfcq2J++1+UBw6EM6bvrDf95cl1ZFO+Hw6J9/sHbtuuV1GJmp X-Received: by 2002:a17:902:e0d5:b0:13f:25a0:d26b with SMTP id e21-20020a170902e0d500b0013f25a0d26bmr16435698pla.53.1634027623991; Tue, 12 Oct 2021 01:33:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634027623; cv=none; d=google.com; s=arc-20160816; b=LsgBupS4R6P+abJ9w0EmXLmKIPsUP2rDIK98xLd4ZbmrdzXy/gDZdO5pkSAzOGf/4y p/a4aZgZyJ4UrD/rGWjIwCCWphSxiHfSKwja6ZrMH4dG4skbE/wA8LUnNGkZzuhb0wdm VniEnlKk/EBqQWo96TDYj1Bg7UC+eGljOoQOhMpzlfvNkuWbw4FRtk3UQqmRC0xWwNdz t2+w/VAX6es3ttYanAM58l2iLddIkcWIIXns5LC17FX9ZyU3a9AaNSHU1aUNBxFoUN7T c2AcHXSlcqx/EvzwwipkFOw14jTdpBkjLKvT8AJuGdTGppcDRkgCjRdSzCKA5lfW7l45 DcvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature:dkim-signature; bh=jzhciBvqQ0vTMCmMY7ans9eWDLkjdIgrfHAs17HgGQk=; b=HIXrJrmGKiQwxh/N+qAr2Z/jewXRppx1XvnZaugoWGWgwQvkv5vUGjyJn9oVMr/RoI p8D8qjUk1zr+fE+au/bkZGdKoLLC1V5yRZ2RmZ9ndsuy0mINh7pjJPv11r5M7w3F53+5 622G0gDMv8hRIHygdCM6WxB4tH6ssviFc/Bd/qGJueg0mX9e8rZSJGrYzmuc9v8xL2SL 1KGqDLY4ujoIj0Tgwj7VewPIeSyZaO/DiD/7vL/YqqmYYnMxsPRvwoFvHsaxsfw629yU FzHhlaGN7GZNCDqybeZ5t5DZCpIgyKOpFf8DMBOIqflSRv1hHwpuYg0PTVyTi5n5fNVb V3Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=GBFKzyqP; dkim=neutral (no key) header.i=@suse.cz; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u185si14169728pgd.93.2021.10.12.01.33.31; Tue, 12 Oct 2021 01:33:43 -0700 (PDT) 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=@suse.cz header.s=susede2_rsa header.b=GBFKzyqP; dkim=neutral (no key) header.i=@suse.cz; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234831AbhJLIdy (ORCPT + 99 others); Tue, 12 Oct 2021 04:33:54 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:48694 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235009AbhJLIdt (ORCPT ); Tue, 12 Oct 2021 04:33:49 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 79F0220189; Tue, 12 Oct 2021 08:31:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1634027504; h=from:from:reply-to: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; bh=jzhciBvqQ0vTMCmMY7ans9eWDLkjdIgrfHAs17HgGQk=; b=GBFKzyqP4aFaQYz4LYka2c25/WepD8eDLhKgmdlwDY6a8+PWKuJOb/YiFgASvKISf+L/pN FFzTAIJY1yefHrYYwunVYeLbVw0tieKnuvSd6XVLWG0qQWCEm3uATRZKjOAVKucSkYj50p BpzuKXYmE+VYr0N1cW0G+pdI9wI8XsM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1634027504; h=from:from:reply-to: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; bh=jzhciBvqQ0vTMCmMY7ans9eWDLkjdIgrfHAs17HgGQk=; b=HJtXWc9v/GvoS2ZYZ+y3ofWWVJOYc0BvONGgP+qhjWtSFMdTcUMAsyyfJnKKIrhzt7u3Nr XBa1gvw9kPfaDFAw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E7E8613AD5; Tue, 12 Oct 2021 08:31:43 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id +SDwN+9HZWFCSwAAMHmgww (envelope-from ); Tue, 12 Oct 2021 08:31:43 +0000 Message-ID: Date: Tue, 12 Oct 2021 10:31:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH] lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() Content-Language: en-US To: Marco Elver Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, kasan-dev@googlegroups.com, Vijayanand Jitta , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Geert Uytterhoeven , Oliver Glitta , Imran Khan References: <20211007095815.3563-1-vbabka@suse.cz> <2a62971d-467f-f354-caac-2b5ecf258e3c@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/11/21 19:08, Marco Elver wrote: > On Mon, 11 Oct 2021 at 19:02, Vlastimil Babka wrote: > [...] >> > On the other hand, the lazy initialization mode you're introducing >> > requires an explicit stack_depot_init() call somewhere and isn't as >> > straightforward as before. >> > >> > Not sure what is best. My intuition tells me STACKDEPOT_LAZY_INIT would >> > be safer as it's a deliberate opt-in to the lazy initialization >> > behaviour. >> >> I think it should be fine with ALWAYS_INIT. There are not many stackdepot >> users being added, and anyone developing a new one will very quickly find >> out if they forget to call stack_depot_init()? > > I think that's fine. > >> > Preferences? >> > >> > [...] >> >> --- a/drivers/gpu/drm/drm_mm.c >> >> +++ b/drivers/gpu/drm/drm_mm.c >> >> @@ -980,6 +980,10 @@ void drm_mm_init(struct drm_mm *mm, u64 start, u64 size) >> >> add_hole(&mm->head_node); >> >> >> >> mm->scan_active = 0; >> >> + >> >> +#ifdef CONFIG_DRM_DEBUG_MM >> >> + stack_depot_init(); >> >> +#endif >> > >> > DRM_DEBUG_MM implies STACKDEPOT. Not sure what is more readable to drm >> > maintainers, but perhaps it'd be nicer to avoid the #ifdef here, and >> > instead just keep the no-op version of stack_depot_init() in >> > . I don't have a strong preference. >> >> Hm, but in case STACKDEPOT is also selected by something else (e.g. >> CONFIG_PAGE_OWNER) which uses lazy init but isn't enabled on boot, then >> without #ifdef CONFIG_DRM_DEBUG_MM above, this code would call a >> stack_depot_init() (that's not a no-op) even in case it's not going to be >> using it, so not what we want to achieve. >> But it could be changed to use IS_ENABLED() if that's preferred by DRM folks. > > You're right -- but I'll leave this to DRM folks. Ah, the file only includes stackdepot.h in a #ifdef CONFIG_DRM_DEBUG_MM section so I will keep the #ifdef here for a minimal change, unless requested otherwise.