linux-kernel - Re: [PATCH v4 05/11] mm: do not split a folio if it has minimum folio order requirement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed, 1 May 2024 15:28:26 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Zi Yan <ziy@...dia.com>, Andrew Morton <akpm@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>,
	Sean Christopherson <seanjc@...gle.com>,
	"Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>,
	djwong@...nel.org, brauner@...nel.org, david@...morbit.com,
	chandan.babu@...cle.com, linux-fsdevel@...r.kernel.org,
	hare@...e.de, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-xfs@...r.kernel.org, gost.dev@...sung.com,
	p.raghav@...sung.com
Subject: Re: [PATCH v4 05/11] mm: do not split a folio if it has minimum
 folio order requirement

On Wed, May 01, 2024 at 05:13:59AM +0100, Matthew Wilcox wrote:
> On Tue, Apr 30, 2024 at 12:27:04PM -0700, Luis Chamberlain wrote:
> >   2a:*	8b 43 34             	mov    0x34(%rbx),%eax		<-- trapping instruction
> > RBX: 0000000000000002 RCX: 0000000000018000
> 
> Thanks, got it.  I'll send a patch in the morning, but I know exactly
> what the problem is.  You're seeing sibling entries tagged as dirty.
> That shouldn't happen; we should only see folios tagged as dirty.
> The bug is in node_set_marks() which calls node_mark_all().  This works
> fine when splitting to order 0, but we should only mark the first entry
> of each order.  eg if we split to order 3, we should tag slots 0, 8,
> 16, 24, .., 56.

Confirmed:

+++ b/lib/test_xarray.c
@@ -1789,8 +1789,10 @@ static void check_split_1(struct xarray *xa, unsigned lon
g index,
 {
        XA_STATE_ORDER(xas, xa, index, new_order);
        unsigned int i;
+       void *entry;

        xa_store_order(xa, index, order, xa, GFP_KERNEL);
+       xa_set_mark(xa, index, XA_MARK_1);

        xas_split_alloc(&xas, xa, order, GFP_KERNEL);
        xas_lock(&xas);
@@ -1807,6 +1809,12 @@ static void check_split_1(struct xarray *xa, unsigned long index,
        xa_set_mark(xa, index, XA_MARK_0);
        XA_BUG_ON(xa, !xa_get_mark(xa, index, XA_MARK_0));

+       xas_set_order(&xas, index, 0);
+       rcu_read_lock();
+       xas_for_each_marked(&xas, entry, ULONG_MAX, XA_MARK_1)
+               XA_BUG_ON(xa, xa_is_internal(entry));
+       rcu_read_unlock();
+
        xa_destroy(xa);
 }


spits out:

$ ./tools/testing/radix-tree/xarray
BUG at check_split_1:1815
xarray: 0x562b4043e580x head 0x50c0095cc082x flags 3000000 marks 1 1 0
0-63: node 0x50c0095cc080x max 0 parent (nil)x shift 3 count 1 values 0 array 0x562b4043e580x list 0x50c0095cc098x 0x50c0095cc098x marks 1 1 0
0-7: node 0x50c0095cc140x offset 0 parent 0x50c0095cc080x shift 0 count 8 values 4 array 0x562b4043e580x list 0x50c0095cc158x 0x50c0095cc158x marks 1 ff 0
0: value 0 (0x0) [0x1x]
1: sibling (slot 0)
2: value 2 (0x2) [0x5x]
3: sibling (slot 2)
4: value 4 (0x4) [0x9x]
5: sibling (slot 4)
6: value 6 (0x6) [0xdx]
7: sibling (slot 6)
xarray: ../../../lib/test_xarray.c:1815: check_split_1: Assertion `0' failed.
Aborted