On Wed, 30 Mar 2022 at 13:54, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
That's a lot of userspace logs, any kernel logs showing that anything failed?
I do not see kernel logs failures here.
Great, then the kernel is working just fine! :)
Seriously, without some sort of hint, it's going to be impossible for us to know what to do here...
Ander is bisecting this problem.
OTOH, I am looking into test history and found the head commit is booting pass. The problem report I have sent is a head-1 test report.
This means that, current Linus master boot pass.
Do you see any relation of top fix commit vs the report I sent.
BAD: 965181d7ef7e (head -1 ) GOOD: d888c83fcec75194a8 ( head)
git log 965181d7ef7e..d888c83fcec75194a8
commit d888c83fcec75194a8a48ccd283953bdba7b2550 (HEAD -> linux-master, linux/master) Author: Linus Torvalds torvalds@linux-foundation.org Date: Tue Mar 29 23:29:18 2022 -0700
fs: fix fd table size alignment properly
Jason Donenfeld reports that my commit 1c24a186398f ("fs: fd tables have to be multiples of BITS_PER_LONG") doesn't work, and the reason is an embarrassing brown-paper-bag bug.
Yes, we want to align the number of fds to BITS_PER_LONG, and yes, the reason they might not be aligned is because the incoming 'max_fd' argument might not be aligned.
But aligining the argument - while simple - will cause a "infinitely big" maxfd (eg NR_OPEN_MAX) to just overflow to zero. Which most definitely isn't what we want either.
The obvious fix was always just to do the alignment last, but I had moved it earlier just to make the patch smaller and the code look simpler. Duh. It certainly made _me_ look simple.
Fixes: 1c24a186398f ("fs: fd tables have to be multiples of BITS_PER_LONG") Reported-and-tested-by: Jason A. Donenfeld Jason@zx2c4.com Cc: Fedor Pchelkin aissur0002@gmail.com Cc: Alexey Khoroshilov khoroshilov@ispras.ru Cc: Christian Brauner brauner@kernel.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org
- Naresh