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 AF67AC64ED8 for ; Mon, 27 Feb 2023 18:59:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D34F6B0071; Mon, 27 Feb 2023 13:59:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 184666B0072; Mon, 27 Feb 2023 13:59:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 023796B0073; Mon, 27 Feb 2023 13:59:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E42146B0071 for ; Mon, 27 Feb 2023 13:59:57 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B431780307 for ; Mon, 27 Feb 2023 18:59:57 +0000 (UTC) X-FDA: 80513986434.28.5791DD5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 4386040020 for ; Mon, 27 Feb 2023 18:59:54 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gTudn71m; spf=pass (imf12.hostedemail.com: domain of dakr@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dakr@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677524394; 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=XJsvYk7GXp8I4COeJ3t1hMqXzf5hp4/G1Bgw17Xxk70=; b=G2FGdrdIqRNQzy+dcPmaBtDRdsleybitkcZxMlg7jXh76O5/UYBrUSISETMGtxprajFiA8 ryDon+D6jmLXOwPRRSjIJayOBKvyMPp9RCuZBqLPH1bRLkDEDLtKOOJOZuVzsAUQqO4Q/f dfD5eRKcJJyAjI811BhXkxObM3Zhm9Q= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gTudn71m; spf=pass (imf12.hostedemail.com: domain of dakr@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dakr@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677524394; a=rsa-sha256; cv=none; b=bWeLgmHDjpZdGUuY5/oH9TVBRgYrBgJSa8Wxrd3rjNRRkSFWf29QFplD1fTSJqncAHj2ov 5b+zUh62aLaI5WvaacererLWVPRQWw4Gzf9TvQBZZCB+OmUGlLp+92WbWDMIA4A+I+XDxj RnvVKT6HNbK8swoz0V0F4D0jGsJHEjw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677524393; h=from:from: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; bh=XJsvYk7GXp8I4COeJ3t1hMqXzf5hp4/G1Bgw17Xxk70=; b=gTudn71mDNVN54tOKIo5APKwZa7xQQafnY6kMynfZX2n9VmP4m/Lcl/dU5wE8Jt2mkWirM rX59viPa6ho5qXwEm0k7Uod0b9aiuM2a46vg+rCSQpkhJc/a+Z66Wk4YIqrtneO+y2FbE2 szvm6UiEfairv2lGMBZW2tshNyd9ykU= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-669-wiO8P22jPi6OmUSlMk_BPg-1; Mon, 27 Feb 2023 13:59:50 -0500 X-MC-Unique: wiO8P22jPi6OmUSlMk_BPg-1 Received: by mail-ed1-f71.google.com with SMTP id cy28-20020a0564021c9c00b004acc6cf6322so9844788edb.18 for ; Mon, 27 Feb 2023 10:59:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XJsvYk7GXp8I4COeJ3t1hMqXzf5hp4/G1Bgw17Xxk70=; b=6Z/xorhSNxLcbMFGdFTnD/O6FU0tXIfIJAAJ1BNevXxLR0NFGKrKqIPTHlYmFlWQGe 2D365V6w5x9+w/zqtMVjRgHqD1hwPGmwtfIIHDc1oSxoXZ8dXY3oya38FXEtnzs3ZrAO lr6RICjmLATRuFWBlrT0qrZMn8jEsjXG7SAXxkfN7uJmp0g/dkGl2OXfCsSWD1N8iJWO bUrOC/4peqthA8diqOKi/MnOZOvZ5GwDKGHX04z4uFaR/BwvnzMZIDta+H7cq0xR8nye 8kVSKoExjFF7ARtJ2knses2F/j/BT8w+GgoH6ojKc0n5Uw0istHyzNKW6DgorthoZvEW 7+1g== X-Gm-Message-State: AO0yUKWT6oBCzHBuugbc3BkXgfbsFttaKiLK+jouo+EfIHCKmh8UbevZ 4wEcHwddOU7t63sWllbGzLb9+4rV5GFs7lKEMFiUxu2lCTZBJuYUPW8jLgGChLBDcVQ5gnfm1qA NERdYZYnM5do= X-Received: by 2002:a17:907:76f3:b0:878:50f7:a35a with SMTP id kg19-20020a17090776f300b0087850f7a35amr31180644ejc.72.1677524389409; Mon, 27 Feb 2023 10:59:49 -0800 (PST) X-Google-Smtp-Source: AK7set/nAXyU6HErE/WKmVJkdOcUhliWwVp6EtClu1WGQ8XxsSLsimgCTlXes6YRi85ETu9ws3e7Hw== X-Received: by 2002:a17:907:76f3:b0:878:50f7:a35a with SMTP id kg19-20020a17090776f300b0087850f7a35amr31180622ejc.72.1677524389137; Mon, 27 Feb 2023 10:59:49 -0800 (PST) Received: from ?IPV6:2a02:810d:4b3f:de78:642:1aff:fe31:a15c? ([2a02:810d:4b3f:de78:642:1aff:fe31:a15c]) by smtp.gmail.com with ESMTPSA id i16-20020a17090685d000b008b7a9ff7dfdsm3436723ejy.162.2023.02.27.10.59.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Feb 2023 10:59:48 -0800 (PST) Message-ID: Date: Mon, 27 Feb 2023 19:59:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH drm-next v2 04/16] maple_tree: add flag MT_FLAGS_LOCK_NONE To: Matthew Wilcox Cc: matthew.brost@intel.com, dri-devel@lists.freedesktop.org, corbet@lwn.net, nouveau@lists.freedesktop.org, ogabbay@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, boris.brezillon@collabora.com, bskeggs@redhat.com, tzimmermann@suse.de, Liam.Howlett@oracle.com, bagasdotme@gmail.com, christian.koenig@amd.com, jason@jlekstrand.net References: <20230217134422.14116-1-dakr@redhat.com> <20230217134422.14116-5-dakr@redhat.com> <3bb02ec3-4d19-9135-cabc-26ed210f7396@redhat.com> <67942a68-2ae7-8883-25d7-c6d595c3587e@redhat.com> From: Danilo Krummrich Organization: RedHat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4386040020 X-Stat-Signature: esbxaju7h9rs4nbobujf8yq7cbubswdn X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1677524394-22587 X-HE-Meta: U2FsdGVkX1/57zhlGo+VzjkMZQMCWfpP4SBimmh0WNd7MEMFcPqOWsBxwwo3rtjZEFCfKtzH047wurqVDzDLHwum8i4Zu76p8xaCS7EdJUTYyBKSlMOF7cPbBlfdOi5Co+LveUkLmYXLhbjdn+N+Neqm/CTkjxJZbuJWtVMcqymXBbZEv/27UMZ8VrBQXgVuDdKKv4BQ/8m5GjDjPVVKLAg3TzBty544Ju6+AJcf2Pv7DlMt62eBmIfWLzz2fNbFqcc/ydg7OfsbkTuz/BAr9CGaubKZC9mj+rOac2PeZJJAqT5vaQpKw68x+Nme0l4G7KJ4jwct5ZhLG8xILX2pzd1immvfhFK0MOIeTI6pu2tmfuHsFT8qlSb5qYgE+H8QS6WWbA4kyWFoSU/RtXY9B6zuf+6Uv9j/4ht3LBDTYI90MmnE1zcbNBWMsm+4qnkh8J0Dm0HVX5KE53q3xKHDuktedy4UXBLZjenckApSWkuR0f7P1AV5cpWnvvDeecaSKyQHRz1FiFMxqRzsFm1UtsV05LwKE5++D0av/NaUExaZXQ3OqOC6IP/r93qGwCRMXkldH73SeKOXVeQqvH1KYHAPYSx78JEDZ5+kB5O/ECdB43/KFuuoCeSkqAk7bxwYQy2nJPkOVNQnvGJuEfO644Dpa5ZUNV98ovV4qIew1aU13Ww5zneYsqMrq5NJ7QGAmzic7JQbjPbMdNWqbmAdW6x4p412rJUIb2NlYivT+daPqXgCuAvqN1OmX1fD/xAlc8fXuZsRRQTAj9BkfY7JwuMS4JV0iALoVzimMK1SX4DoFUulAFxQ7wuuIfX6UO1Ehf626U3/+d1dmjIYMiLkftrs6aBiQjVduJlgPJU8/FVxNhrJRQqTJVdQQ2FNqcbXlGGC+kieC4PniSEzfZIal0E2FQyMd91b2TKK75fBI5wrpTv920Du4h7fD0sqgHHFnBwW2255XwUfSbPUV7Q OlSA0Sli 20V64kOkWcy9U5EBou10YXA0jr1mYH+HWS2L3Kraavkm9C+MVgFx6TDxIZmLfN25A0n09MDgyjOBg5aPrnSB6qZzFlFjF4C5yIeBbZ+5upRlXln0Nd69cNtbU5378dx+QixkO955p5UC+S9nru/IZmxM21TNZnZO4EP7E32j8rycbfZ80rTd0Hi521HBPnlpQ/avDJF3BEtqyJ6Njdgf2RafeJFsjrWxSqKb4gpkNyWhfUueyaQSxeb/Ce3Q7C6XxPIhh+pn2jk2I/duXqAwkBEsaxca1J1Wq6xhSaobkBU/VUOQdbsPjaAWJr00mmvaeQtDwhzlAS5AEyg1EXSaBUnDBtMnKpzweW2W8WzY3xaIfPgroUZhXDvWG0MSjVOPkP/dAUMwglx5/u6uUlIuRzJRh9W/zHp3IZ+nc834bcoCCSgUPR5trtDr8mZKLQVOhuC5+ 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 2/27/23 19:36, Matthew Wilcox wrote: > On Mon, Feb 27, 2023 at 06:39:33PM +0100, Danilo Krummrich wrote: >> On 2/21/23 19:31, Matthew Wilcox wrote: >>> Lockdep will shout at you if you get it wrong ;-) But you can safely >>> take the spinlock before calling mas_store_gfp(GFP_KERNEL) because >>> mas_nomem() knows to drop the lock before doing a sleeping allocation. >>> Essentially you're open-coding mtree_store_range() but doing your own >>> thing in addition to the store. >> >> As already mentioned, I went with your advice to just take the maple tree's >> internal spinlock within the GPUVA manager and leave all the other locking >> to the drivers as intended. >> >> However, I run into the case that lockdep shouts at me for not taking the >> spinlock before calling mas_find() in the iterator macros. >> >> Now, I definitely don't want to let the drivers take the maple tree's >> spinlock before they use the iterator macro. Of course, drivers shouldn't >> even know about the underlying maple tree of the GPUVA manager. >> >> One way to make lockdep happy in this case seems to be taking the spinlock >> right before mas_find() and drop it right after for each iteration. > > While we don't have any lockdep checking of this, you really shouldn't be > using an iterator if you're going to drop the lock between invocations. > The iterator points into the tree, so you need to invalidate the iterator > any time you drop the lock. The tree can't change either way in my case. Changes to the DRM GPUVA manager (and hence the tree) are protected by drivers, either by serializing tree accesses or by having another external lock ensuring mutual exclusion. Just as a reminder, in the latter case drivers usually lock multiple transactions to the manager (and hence the tree) to ensure they appear atomic. So, really the only purpose for me taking the internal lock is to ensure I satisfy lockdep and the maple tree's internal requirements on locking for future use cases you mentioned (e.g. slab cache defragmentation). It's the rcu_dereference_check() in mas_root() that triggers in my case: [ 28.745706] lib/maple_tree.c:851 suspicious rcu_dereference_check() usage! stack backtrace: [ 28.746057] CPU: 8 PID: 1518 Comm: nouveau_dma_cop Not tainted 6.2.0-rc6-vmbind-0.2+ #104 [ 28.746061] Hardware name: ASUS System Product Name/PRIME Z690-A, BIOS 2103 09/30/2022 [ 28.746064] Call Trace: [ 28.746067] [ 28.746070] dump_stack_lvl+0x5b/0x77 [ 28.746077] mas_walk+0x16d/0x1b0 [ 28.746082] mas_find+0xf7/0x300 [ 28.746088] drm_gpuva_in_region+0x63/0xa0 [ 28.746099] __drm_gpuva_sm_map.isra.0+0x465/0x9f0 [ 28.746103] ? lock_acquire+0xbf/0x2b0 [ 28.746111] ? __pfx_drm_gpuva_sm_step+0x10/0x10 [ 28.746114] ? lock_is_held_type+0xe3/0x140 [ 28.746121] ? mark_held_locks+0x49/0x80 [ 28.746125] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 28.746138] drm_gpuva_sm_map_ops_create+0x80/0xc0 [ 28.746145] uvmm_bind_job_submit+0x3c2/0x470 [nouveau] [ 28.746272] nouveau_job_submit+0x60/0x450 [nouveau] [ 28.746393] nouveau_uvmm_ioctl_vm_bind+0x179/0x1e0 [nouveau] [ 28.746510] ? __pfx_nouveau_uvmm_ioctl_vm_bind+0x10/0x10 [nouveau] [ 28.746622] drm_ioctl_kernel+0xa9/0x160 [ 28.746629] drm_ioctl+0x1f7/0x4b0 > > You don't have to use a spinlock to do a read iteration. You can just > take the rcu_read_lock() around your iteration, as long as you can > tolerate the mild inconsistencies that RCU permits. > Doing that would mean that the driver needs to do it. However, the driver either needs to serialize accesses or use it's own mutex for protection for the above reasons. Hence, that should not be needed.