From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC2C93815D4 for ; Tue, 30 Jun 2026 19:08:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782846528; cv=none; b=EvD8ulyaosyH1rQJUedMXHsWi2sfZX7VoSHoj2CCmOpgGn6OdHDkIu1W87cNSQbxIr36yVXFJEg/xfzZbGrbUPT2VZTmj7itTKgm2VchOSmjZkDJieQxtMkNWTRD4oIRu2zgg8AKt4RrRj/VuB22E4eOPZXWh2XcnZ7Jz14GHL4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782846528; c=relaxed/simple; bh=ZmaSWkz91oT7n/nVomAmZ7/pzMi38YCPPTt47aW/VSM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=uG+hrHRNeOdb+QnZ2yyu2Bq/yyRgfRyy0ozS1rQvN+52BytHCKQsZARiJ8q7dr0ZnrdiyBK11l/k6Iu+5zrXQ6mbTMcmZrYO3+Fkl2ft5k/92xaR3MknlTfak80pkVaps6c/X22Szez6RxklvaEIZ/MA7mFjfykzLjk7wksUAcg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=cr8NiA/q; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="cr8NiA/q" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:In-Reply-To:References; bh=WLDkhJ49sK0ZVXamzbGj7uDasVQ2fboJSMeGcLvAidA=; b=cr8NiA/qj6FaBnYxrTA7ZR0NsB czLlkZ4R34VoBDPrtkXmnPcuYqk+50uyBgC3VDRLK4oXqE+gq8Uzix0lyiduqnN+alqr1++mrDCDk 7R6KZaIkDCbjiLpzz1+ouZSYjf1XTHzxbyGVA+7N5Mp8pfmGfBBInhqp8L90b9hly4FHYkdZdXBxM umflLkQ5+dA8KX30hSqlaNEXiVuVvGC8or0j+i2PM6R0DQ6HaUcs9jYSobDNZ4rJ9AlGyFXxMaQpp UEHgaufoW5PLO4/HlRZEl4iM2V14GpbpVH8DD+cUvpe9Bg5Y9uMT+JKEDbJ4e+2cZybFtFnCfxkox SFkVHnKA==; Received: from [38.23.173.23] (helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wedp8-000000005nE-0bXT; Tue, 30 Jun 2026 19:08:46 +0000 From: "Liam R. Howlett (Oracle)" To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org, "Liam R. Howlett (Oracle)" Subject: [PATCH v2 00/19] maple_tree: lock checking and clean ups Date: Tue, 30 Jun 2026 15:08:24 -0400 Message-ID: <20260630190843.3563858-1-liam@infradead.org> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The goals of this series are: 1. Lock issue detection A number of syzbot reports are incorrectly pointing to the mm exit as a source of the locking error. The first three patches attempt to help users detect errors in their locking - but they still have to use LOCKDEP. I guess it's still down to hope and prayers. 2. Documentation fixes The documentation was lacking clarity, there are updates to try and help the users, especially around the erase() cases. 3. Two benign issues The cyclic allocator may have a race, although no in-kernel user can hit it. The erase functions may cause allocation issues if used with the incorrect locking type, but none are present in-tree. Beyond these goals there are some test fixes, some general speed-up patches targeting extra work and cycles, and dropping dead code. v1: https://lore.kernel.org/all/20260629144145.1572283-1-liam@infradead.org/ Changes since v1: - Relocated mas_set_parent_slots() lower so that mt_slots_locked() for rcu dereferencing - Thanks kernel build bot - Made mas_lockdep_map() static - Thanks kernel build bot - Added mas_lock_check() to mas_may_activate() when restoring a node to active - Thanks sashiko - Changed mas_lock_check() aliasing to use mt_locked() - Thanks sashiko - Updated __lock_unpin_lock() underflow check - Thanks sashiko - Updated checking the lock sequence based on the lockdep map - Thanks sashiko - Add a comment to mas_wr_node_store() to explain why the last slot isn't cleared. - Thanks sashiko - Drop mas_set_parent() function as it is no longer used - Thanks sashiko - Clear the mas_alloc_cyclic() wrap flag after storage - Thanks sashiko - Add might_allocate() to the mtree_erase() call - Thanks Jason - Added one more cleanup for making maple state walkable. Liam R. Howlett (Oracle) (19): maple_tree: Add rcu locking check when LOCKDEP is enabled locking/lockdep: Add sequence counter to held_lock maple_tree: Add write lock checking with lockdep sequence numbers maple_tree: Documentation fix maple_tree: Drop dead code from mas_extend_spanning_null() maple_tree: Drop MAPLE_ALLOC_SLOTS maple_tree: Clarify comments on mas_nomem() maple_tree: Use prefetched value in mas_wr_store_type() maple_tree: Optimise mas_wr_node_store() when not in rcu mode maple_tree: micro optimisation of mas_wr_store_type() maple_tree: Add bulk parent set helper maple_tree: Catch race in mas_alloc_cyclic() maple_tree: Document that erase may use GFP_KERNEL for allocations maple_tree: WARN_ON_ONCE when allocations fail maple_tree: Document erase and allocations better maple_tree: Change two GFP flags in tests maple_tree: Fix argument name in header maple_tree: Avoid extra gap calculation maple_tree: Add helper mas_make_walkable() Documentation/core-api/maple_tree.rst | 21 +- include/linux/lockdep.h | 3 + include/linux/lockdep_types.h | 3 +- include/linux/maple_tree.h | 10 +- include/linux/sched.h | 1 + kernel/locking/lockdep.c | 58 ++++- lib/maple_tree.c | 353 ++++++++++++++++++-------- tools/testing/radix-tree/maple.c | 4 +- 8 files changed, 326 insertions(+), 127 deletions(-) -- 2.47.3