<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/lib/test_xarray.c, branch v5.4.42</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.42</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.42'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-04-17T08:50:18Z</updated>
<entry>
<title>XArray: Fix xas_pause for large multi-index entries</title>
<updated>2020-04-17T08:50:18Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2020-01-31T11:17:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8f4c8e92bdac564b8c562460a271d3ff11317fe9'/>
<id>urn:sha1:8f4c8e92bdac564b8c562460a271d3ff11317fe9</id>
<content type='text'>
commit c36d451ad386b34f452fc3c8621ff14b9eaa31a6 upstream.

Inspired by the recent Coverity report, I looked for other places where
the offset wasn't being converted to an unsigned long before being
shifted, and I found one in xas_pause() when the entry being paused is
of order &gt;32.

Fixes: b803b42823d0 ("xarray: Add XArray iterators")
Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>XArray: Fix xa_find_next for large multi-index entries</title>
<updated>2020-04-08T07:08:40Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2020-01-31T10:07:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=16696ee7b58101c90bf21c3ab2443c57df4af24e'/>
<id>urn:sha1:16696ee7b58101c90bf21c3ab2443c57df4af24e</id>
<content type='text'>
[ Upstream commit bd40b17ca49d7d110adf456e647701ce74de2241 ]

Coverity pointed out that xas_sibling() was shifting xa_offset without
promoting it to an unsigned long first, so the shift could cause an
overflow and we'd get the wrong answer.  The fix is obvious, and the
new test-case provokes UBSAN to report an error:
runtime error: shift exponent 60 is too large for 32-bit type 'int'

Fixes: 19c30f4dd092 ("XArray: Fix xa_find_after with multi-index entries")
Reported-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reported-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>XArray: Fix xas_pause at ULONG_MAX</title>
<updated>2020-02-05T21:22:47Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2019-11-08T03:49:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=08022255a9ee926896e81ba63a83bb904efe446d'/>
<id>urn:sha1:08022255a9ee926896e81ba63a83bb904efe446d</id>
<content type='text'>
[ Upstream commit 82a22311b7a68a78709699dc8c098953b70e4fd2 ]

If we were unlucky enough to call xas_pause() when the index was at
ULONG_MAX (or a multi-slot entry which ends at ULONG_MAX), we would
wrap the index back around to 0 and restart the iteration from the
beginning.  Use the XAS_BOUNDS state to indicate that we should just
stop the iteration.

Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>XArray: Fix xas_find returning too many entries</title>
<updated>2020-01-29T15:45:27Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2020-01-18T03:13:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dd05cf12c72f11b7841d4ffeca29e5190606df1b'/>
<id>urn:sha1:dd05cf12c72f11b7841d4ffeca29e5190606df1b</id>
<content type='text'>
commit c44aa5e8ab58b5f4cf473970ec784c3333496a2e upstream.

If you call xas_find() with the initial index &gt; max, it should have
returned NULL but was returning the entry at index.

Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>XArray: Fix xa_find_after with multi-index entries</title>
<updated>2020-01-29T15:45:26Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2020-01-18T03:00:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=db38561288b75082b5e839decaa15ed253bd2298'/>
<id>urn:sha1:db38561288b75082b5e839decaa15ed253bd2298</id>
<content type='text'>
commit 19c30f4dd0923ef191f35c652ee4058e91e89056 upstream.

If the entry is of an order which is a multiple of XA_CHUNK_SIZE,
the current detection of sibling entries does not work.  Factor out
an xas_sibling() function to make xa_find_after() a little more
understandable, and write a new implementation that doesn't suffer from
the same bug.

Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>XArray: Fix infinite loop with entry at ULONG_MAX</title>
<updated>2020-01-29T15:45:26Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2020-01-17T22:45:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a5135ca1f92a7b201b7f8297f42b8579f92bc55d'/>
<id>urn:sha1:a5135ca1f92a7b201b7f8297f42b8579f92bc55d</id>
<content type='text'>
commit 430f24f94c8a174d411a550d7b5529301922e67a upstream.

If there is an entry at ULONG_MAX, xa_for_each() will overflow the
'index + 1' in xa_find_after() and wrap around to 0.  Catch this case
and terminate the loop by returning NULL.

Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>XArray: Fix xas_next() with a single entry at 0</title>
<updated>2019-07-01T21:11:16Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2019-07-01T21:03:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=91abab83839aa2eba073e4a63c729832fdb27ea1'/>
<id>urn:sha1:91abab83839aa2eba073e4a63c729832fdb27ea1</id>
<content type='text'>
If there is only a single entry at 0, the first time we call xas_next(),
we return the entry.  Unfortunately, all subsequent times we call
xas_next(), we also return the entry at 0 instead of noticing that the
xa_index is now greater than zero.  This broke find_get_pages_contig().

Fixes: 64d3e9a9e0cc ("xarray: Step through an XArray")
Reported-by: Kent Overstreet &lt;kent.overstreet@gmail.com&gt;
Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
</content>
</entry>
<entry>
<title>XArray tests: Add check_insert</title>
<updated>2019-06-03T03:00:24Z</updated>
<author>
<name>Matthew Wilcox</name>
<email>willy@infradead.org</email>
</author>
<published>2019-03-10T03:25:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=12fd2aee6db765ab4e97c4a37e6d1f6c10e74ee6'/>
<id>urn:sha1:12fd2aee6db765ab4e97c4a37e6d1f6c10e74ee6</id>
<content type='text'>
A simple test which just checks that inserting an entry into an empty
array succeeds.  Try various different interesting indices.

Signed-off-by: Matthew Wilcox &lt;willy@infradead.org&gt;
</content>
</entry>
<entry>
<title>XArray: Fix xa_reserve for 2-byte aligned entries</title>
<updated>2019-02-21T22:54:44Z</updated>
<author>
<name>Matthew Wilcox</name>
<email>willy@infradead.org</email>
</author>
<published>2019-02-21T22:54:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4a5c8d898948d1ac876522cdd62f07a78104bfe9'/>
<id>urn:sha1:4a5c8d898948d1ac876522cdd62f07a78104bfe9</id>
<content type='text'>
If we reserve index 0, the next entry to be stored there might be 2-byte
aligned.  That means we have to create the root xa_node at the time of
reserving the initial entry.

Signed-off-by: Matthew Wilcox &lt;willy@infradead.org&gt;
</content>
</entry>
<entry>
<title>XArray: Fix xa_erase of 2-byte aligned entries</title>
<updated>2019-02-21T22:36:45Z</updated>
<author>
<name>Matthew Wilcox</name>
<email>willy@infradead.org</email>
</author>
<published>2019-02-21T22:36:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2fbe967b3eb7466f679307b38564b8271c093241'/>
<id>urn:sha1:2fbe967b3eb7466f679307b38564b8271c093241</id>
<content type='text'>
xas_store() was interpreting the entry it found in the array as a node
entry if the bottom two bits had value 2.  That's only true if either
the entry is in the root node or in a non-leaf node.

Signed-off-by: Matthew Wilcox &lt;willy@infradead.org&gt;
</content>
</entry>
</feed>
