linux-stable.git/lib, branch linux-5.17.y

iov_iter: fix build issue due to possible type mis-match

2022-06-14T16:41:53+00:00

commit 1c27f1fc1549f0e470429f5497a76ad28a37f21a upstream.

Commit 6c77676645ad ("iov_iter: Fix iter_xarray_get_pages{,_alloc}()")
introduced a problem on some 32-bit architectures (at least arm, xtensa,
csky,sparc and mips), that have a 'size_t' that is 'unsigned int'.

The reason is that we now do

    min(nr * PAGE_SIZE - offset, maxsize);

where 'nr' and 'offset' and both 'unsigned int', and PAGE_SIZE is
'unsigned long'.  As a result, the normal C type rules means that the
first argument to 'min()' ends up being 'unsigned long'.

In contrast, 'maxsize' is of type 'size_t'.

Now, 'size_t' and 'unsigned long' are always the same physical type in
the kernel, so you'd think this doesn't matter, and from an actual
arithmetic standpoint it doesn't.

But on 32-bit architectures 'size_t' is commonly 'unsigned int', even if
it could also be 'unsigned long'.  In that situation, both are unsigned
32-bit types, but they are not the *same* type.

And as a result 'min()' will complain about the distinct types (ignore
the "pointer types" part of the error message: that's an artifact of the
way we have made 'min()' check types for being the same):

  lib/iov_iter.c: In function 'iter_xarray_get_pages':
  include/linux/minmax.h:20:35: error: comparison of distinct pointer types lacks a cast [-Werror]
     20 |         (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
        |                                   ^~
  lib/iov_iter.c:1464:16: note: in expansion of macro 'min'
   1464 |         return min(nr * PAGE_SIZE - offset, maxsize);
        |                ^~~

This was not visible on 64-bit architectures (where we always define
'size_t' to be 'unsigned long').

Force these cases to use 'min_t(size_t, x, y)' to make the type explicit
and avoid the issue.

[ Nit-picky note: technically 'size_t' doesn't have to match 'unsigned
  long' arithmetically. We've certainly historically seen environments
  with 16-bit address spaces and 32-bit 'unsigned long'.

  Similarly, even in 64-bit modern environments, 'size_t' could be its
  own type distinct from 'unsigned long', even if it were arithmetically
  identical.

  So the above type commentary is only really descriptive of the kernel
  environment, not some kind of universal truth for the kinds of wild
  and crazy situations that are allowed by the C standard ]

Reported-by: Sudip Mukherjee 
Link: https://lore.kernel.org/all/YqRyL2sIqQNDfky2@debian/
Cc: Jeff Layton 
Cc: David Howells 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

mm/huge_memory: Fix xarray node memory leak

2022-06-14T16:41:49+00:00

commit 69a37a8ba1b408a1c7616494aa7018e4b3844cbe upstream.

If xas_split_alloc() fails to allocate the necessary nodes to complete the
xarray entry split, it sets the xa_state to -ENOMEM, which xas_nomem()
then interprets as "Please allocate more memory", not as "Please free
any unnecessary memory" (which was the intended outcome).  It's confusing
to use xas_nomem() to free memory in this context, so call xas_destroy()
instead.

Reported-by: syzbot+9e27a75a8c24f3fe75c1@syzkaller.appspotmail.com
Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache")
Cc: stable@vger.kernel.org
Signed-off-by: Matthew Wilcox (Oracle) 
Signed-off-by: Greg Kroah-Hartman

nodemask: Fix return values to be unsigned

2022-06-14T16:41:42+00:00

[ Upstream commit 0dfe54071d7c828a02917b595456bfde1afdddc9 ]

The nodemask routines had mixed return values that provided potentially
signed return values that could never happen. This was leading to the
compiler getting confusing about the range of possible return values
(it was thinking things could be negative where they could not be). Fix
all the nodemask routines that should be returning unsigned
(or bool) values. Silences:

 mm/swapfile.c: In function ‘setup_swap_info’:
 mm/swapfile.c:2291:47: error: array subscript -1 is below array bounds of ‘struct plist_node[]’ [-Werror=array-bounds]
  2291 |                                 p->avail_lists[i].prio = 1;
       |                                 ~~~~~~~~~~~~~~^~~
 In file included from mm/swapfile.c:16:
 ./include/linux/swap.h:292:27: note: while referencing ‘avail_lists’
   292 |         struct plist_node avail_lists[]; /*
       |                           ^~~~~~~~~~~

Reported-by: Christophe de Dinechin 
Link: https://lore.kernel.org/lkml/20220414150855.2407137-3-dinechin@redhat.com/
Cc: Alexey Dobriyan 
Cc: Yury Norov 
Cc: Andy Shevchenko 
Cc: Rasmus Villemoes 
Cc: Andrew Morton 
Cc: Zhen Lei 
Signed-off-by: Kees Cook 
Signed-off-by: Yury Norov 
Signed-off-by: Sasha Levin

iov_iter: Fix iter_xarray_get_pages{,_alloc}()

2022-06-14T16:41:33+00:00

[ Upstream commit 6c77676645ad42993e0a8bdb8dafa517851a352a ]

The maths at the end of iter_xarray_get_pages() to calculate the actual
size doesn't work under some circumstances, such as when it's been asked to
extract a partial single page.  Various terms of the equation cancel out
and you end up with actual == offset.  The same issue exists in
iter_xarray_get_pages_alloc().

Fix these to just use min() to select the lesser amount from between the
amount of page content transcribed into the buffer, minus the offset, and
the size limit specified.

This doesn't appear to have caused a problem yet upstream because network
filesystems aren't getting the pages from an xarray iterator, but rather
passing it directly to the socket, which just iterates over it.  Cachefiles
*does* do DIO from one to/from ext4/xfs/btrfs/etc. but it always asks for
whole pages to be written or read.

Fixes: 7ff5062079ef ("iov_iter: Add ITER_XARRAY")
Reported-by: Jeff Layton 
Signed-off-by: David Howells 
cc: Alexander Viro 
cc: Dominique Martinet 
cc: Mike Marshall 
cc: Gao Xiang 
cc: linux-afs@lists.infradead.org
cc: v9fs-developer@lists.sourceforge.net
cc: devel@lists.orangefs.org
cc: linux-erofs@lists.ozlabs.org
cc: linux-cachefs@redhat.com
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

bootconfig: Make the bootconfig.o as a normal object file

2022-06-14T16:41:27+00:00

[ Upstream commit 6014a23638cdee63a71ef13c51d7c563eb5829ee ]

Since the APIs defined in the bootconfig.o are not individually used,
it is meaningless to build it as library by lib-y. Use obj-y for that.

Link: https://lkml.kernel.org/r/164921225875.1090670.15565363126983098971.stgit@devnote2

Cc: Padmanabha Srinivasaiah 
Cc: Jonathan Corbet 
Cc: Randy Dunlap 
Cc: Nick Desaulniers 
Cc: Sami Tolvanen 
Cc: Nathan Chancellor 
Cc: Linux Kbuild mailing list 
Reported-by: Masahiro Yamada 
Signed-off-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt (Google) 
Signed-off-by: Sasha Levin

list: test: Add a test for list_is_head()

2022-06-09T08:26:31+00:00

commit 37dc573c0a547e1aed0c9abb480fab797bd3833f upstream.

list_is_head() was added recently[1], and didn't have a KUnit test. The
implementation is trivial, so it's not a particularly exciting test, but
it'd be nice to get back to full coverage of the list functions.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/list.h?id=0425473037db40d9e322631f2d4dc6ef51f97e88

Signed-off-by: David Gow 
Acked-by: Daniel Latypov 
Acked-by: Brendan Higgins 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman

lib/string_helpers: fix not adding strarray to device's resource list

2022-06-09T08:26:25+00:00

commit cd290a9839cee2f6641558877e707bd373c8f6f1 upstream.

Add allocated strarray to device's resource list. This is a must to
automatically release strarray when the device disappears.

Without this fix we have a memory leak in the few drivers which use
devm_kasprintf_strarray().

Link: https://lkml.kernel.org/r/20220506044409.30066-1-puyou.lu@gmail.com
Link: https://lkml.kernel.org/r/20220506073623.2679-1-puyou.lu@gmail.com
Fixes: acdb89b6c87a ("lib/string_helpers: Introduce managed variant of kasprintf_strarray()")
Signed-off-by: Puyou Lu 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Linus Walleij 
Cc: Tejun Heo 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

kunit: fix debugfs code to use enum kunit_status, not bool

2022-06-09T08:25:46+00:00

[ Upstream commit 38289a26e1b8a37755f3e07056ca416c1ee2a2e8 ]

Commit 6d2426b2f258 ("kunit: Support skipped tests") switched to using
`enum kunit_status` to track the result of running a test/suite since we
now have more than just pass/fail.

This callsite wasn't updated, silently converting to enum to a bool and
then back.

Fixes: 6d2426b2f258 ("kunit: Support skipped tests")
Signed-off-by: Daniel Latypov 
Reviewed-by: Brendan Higgins 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin

kunit: fix executor OOM error handling logic on non-UML

2022-06-09T08:25:31+00:00

[ Upstream commit 1b11063d32d7e11366e48be64215ff517ce32217 ]

The existing logic happens to work fine on UML, but is not correct when
running on other arches.

1. We didn't initialize `int err`, and kunit_filter_suites() doesn't
   explicitly set it to 0 on success. So we had false "failures".
   Note: it doesn't happen on UML, causing this to get overlooked.
2. If we error out, we do not call kunit_handle_shutdown().
   This makes kunit.py timeout when using a non-UML arch, since the QEMU
   process doesn't ever exit.

Fixes: a02353f49162 ("kunit: bail out of test filtering logic quicker if OOM")
Signed-off-by: Daniel Latypov 
Reviewed-by: Brendan Higgins 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin

kunit: bail out of test filtering logic quicker if OOM

2022-06-09T08:25:26+00:00

[ Upstream commit a02353f491622e49c7ddedc6a6dc4f1d6ed2150a ]

When filtering what tests to run (suites and/or cases) via
kunit.filter_glob (e.g. kunit.py run ), we allocate copies of
suites.

These allocations can fail, and we largely don't handle that.
Note: realistically, this probably doesn't matter much.
We're not allocating much memory and this happens early in boot, so if
we can't do that, then there's likely far bigger problems.

This patch makes us immediately bail out from the top-level function
(kunit_filter_suites) with -ENOMEM if any of the underlying kmalloc()
calls return NULL.

Implementation note: we used to return NULL pointers from some functions
to indicate either that all suites/tests were filtered out or there was
an error allocating the new array.

We'll log a short error in this case and not run any tests or print a
TAP header. From a kunit.py user's perspective, they'll get a message
about missing/invalid TAP output and have to dig into the test.log to
see it. Since hitting this error seems so unlikely, it's probably fine
to not invent a way to plumb this error message more visibly.

See also: https://lore.kernel.org/linux-kselftest/20220329103919.2376818-1-lv.ruyi@zte.com.cn/

Signed-off-by: Daniel Latypov 
Reported-by: Zeal Robot 
Reported-by: Lv Ruyi 
Reviewed-by: Brendan Higgins 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin