kunit stopped working

kunit stopped working

[Andy Shevchenko]

Hi!

For last few weeks KUnit stopped working. Any insight?

P.S. I guess no need to tell that my kernel on which I run tests has not been
changed as well as command line for wrapper:

	tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR

-- 
With Best Regards,
Andy Shevchenko

Re: kunit stopped working

[Andy Shevchenko]

On Mon, Dec 21, 2020 at 04:43:02PM +0200, Andy Shevchenko wrote:
> Hi!
> 
> For last few weeks KUnit stopped working. Any insight?
> 
> P.S. I guess no need to tell that my kernel on which I run tests has not been
> changed as well as command line for wrapper:
> 
> 	tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR

Current output (expected 18 tests to be run from several modules):

$ tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR
[16:42:24] Configuring KUnit Kernel ...
[16:42:24] Building KUnit Kernel ...
[16:42:28] Starting KUnit Kernel ...
[ERROR] no tests run!
[16:42:28] ============================================================
[16:42:28] Testing complete. 0 tests run. 0 failed. 0 crashed.
[16:42:28] Elapsed time: 3.563s total, 0.002s configuring, 3.441s building, 0.000s running



-- 
With Best Regards,
Andy Shevchenko

Re: kunit stopped working

[Shuah Khan]

On 12/21/20 7:45 AM, Andy Shevchenko wrote:
> On Mon, Dec 21, 2020 at 04:43:02PM +0200, Andy Shevchenko wrote:
>> Hi!
>>
>> For last few weeks KUnit stopped working. Any insight?
>>
>> P.S. I guess no need to tell that my kernel on which I run tests has not been
>> changed as well as command line for wrapper:
>>
>> 	tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR
> 
> Current output (expected 18 tests to be run from several modules):
> 
> $ tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR
> [16:42:24] Configuring KUnit Kernel ...
> [16:42:24] Building KUnit Kernel ...
> [16:42:28] Starting KUnit Kernel ...
> [ERROR] no tests run!
> [16:42:28] ============================================================
> [16:42:28] Testing complete. 0 tests run. 0 failed. 0 crashed.
> [16:42:28] Elapsed time: 3.563s total, 0.002s configuring, 3.441s building, 0.000s running
> 
> 
> 

Hi Andy,

Please give more details on which repo you are using and the what's
the top commit.

thanks,
-- Shuah

Re: kunit stopped working

[Andy Shevchenko]

On Mon, Dec 21, 2020 at 11:37:44AM -0700, Shuah Khan wrote:
> On 12/21/20 7:45 AM, Andy Shevchenko wrote:
> > On Mon, Dec 21, 2020 at 04:43:02PM +0200, Andy Shevchenko wrote:
> > > Hi!
> > > 
> > > For last few weeks KUnit stopped working. Any insight?
> > > 
> > > P.S. I guess no need to tell that my kernel on which I run tests has not been
> > > changed as well as command line for wrapper:
> > > 
> > > 	tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR
> > 
> > Current output (expected 18 tests to be run from several modules):
> > 
> > $ tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR
> > [16:42:24] Configuring KUnit Kernel ...
> > [16:42:24] Building KUnit Kernel ...
> > [16:42:28] Starting KUnit Kernel ...
> > [ERROR] no tests run!
> > [16:42:28] ============================================================
> > [16:42:28] Testing complete. 0 tests run. 0 failed. 0 crashed.
> > [16:42:28] Elapsed time: 3.563s total, 0.002s configuring, 3.441s building, 0.000s running

> Please give more details on which repo you are using and the what's
> the top commit.

v5.10 - OK

[21:24:14] Testing complete. 14 tests run. 0 failed. 0 crashed.

Linux Next 20201221 - Not OK.

I'm expecting that v5.11-rc1 will be broken.

-- 
With Best Regards,
Andy Shevchenko

Re: kunit stopped working

[Andy Shevchenko]

+Cc people from culprit commit

On Mon, Dec 21, 2020 at 09:27:57PM +0200, Andy Shevchenko wrote:
> On Mon, Dec 21, 2020 at 11:37:44AM -0700, Shuah Khan wrote:
> > On 12/21/20 7:45 AM, Andy Shevchenko wrote:
> > > On Mon, Dec 21, 2020 at 04:43:02PM +0200, Andy Shevchenko wrote:
> > > > Hi!
> > > > 
> > > > For last few weeks KUnit stopped working. Any insight?
> > > > 
> > > > P.S. I guess no need to tell that my kernel on which I run tests has not been
> > > > changed as well as command line for wrapper:
> > > > 
> > > > 	tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR
> > > 
> > > Current output (expected 18 tests to be run from several modules):
> > > 
> > > $ tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR
> > > [16:42:24] Configuring KUnit Kernel ...
> > > [16:42:24] Building KUnit Kernel ...
> > > [16:42:28] Starting KUnit Kernel ...
> > > [ERROR] no tests run!
> > > [16:42:28] ============================================================
> > > [16:42:28] Testing complete. 0 tests run. 0 failed. 0 crashed.
> > > [16:42:28] Elapsed time: 3.563s total, 0.002s configuring, 3.441s building, 0.000s running
> 
> > Please give more details on which repo you are using and the what's
> > the top commit.
> 
> v5.10 - OK
> 
> [21:24:14] Testing complete. 14 tests run. 0 failed. 0 crashed.
> 
> Linux Next 20201221 - Not OK.
> 
> I'm expecting that v5.11-rc1 will be broken.

Luckily it's easy to bisect:

# bad: [3b45c156c48f6fa078789df83c3174f96d01ecb8] defconfig: remove everything that is not needed for netboot
# good: [2c85ebc57b3e1817b6ce1a6b703928e113a90442] Linux 5.10
# good: [2cffa11e2aa76a0560c890f057858b68fe744d03] Merge tag 'irq-core-2020-12-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
# bad: [9805529ec544ea7a82d891d5239a8ebd3dbb2a3e] Merge tag 'arm-soc-dt-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
# bad: [ac7ac4618cf25e0d5cd8eba83d5f600084b65b9a] Merge tag 'for-5.11/block-2020-12-14' of git://git.kernel.dk/linux-block
# good: [8958b2491104d7f254cff0698505392582dbc13a] mm: fix some spelling mistakes in comments
# good: [6febd8bef36e64fc1f4aaff1f6302be5c653ad64] Merge branch 'signal-for-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
# bad: [8312f41f08edc641aa927d31fb71319694ae9c42] Merge tag 'mips_5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
# bad: [ca5b877b6ccc7b989614f3f541e9a1fe2ff7f75a] Merge tag 'selinux-pr-20201214' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux
# good: [157807123c94acc8dcddd08a2335bd0173c5d68d] Merge tag 'asm-generic-mmu-context-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
# good: [7194850efa47c8dac6e805087dd23c7b03af019d] Merge tag 'linux-kselftest-next-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
# bad: [d3eb52113d162cc88975fbd03c9e6f9cf2f8a771] Merge tag 'printk-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux
# good: [5e60366d56c630e32befce7ef05c569e04391ca3] Merge tag 'fallthrough-fixes-clang-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux
# bad: [5f3b8d398601055f29f32986a94d55955cd48f09] Merge branch 'for-5.11-null-console' into for-linus
# bad: [3cffa06aeef7ece30f6b5ac0ea51f264e8fea4d0] printk/console: Allow to disable console output by using console="" or console=null
# bad: [757055ae8dedf5333af17b3b5b4b70ba9bc9da4e] init/console: Use ttynull as a fallback when there is no console
# first bad commit: [757055ae8dedf5333af17b3b5b4b70ba9bc9da4e] init/console: Use ttynull as a fallback when there is no console



-- 
With Best Regards,
Andy Shevchenko

Re: kunit stopped working

[Andy Shevchenko]

On Mon, Dec 21, 2020 at 09:40:08PM +0200, Andy Shevchenko wrote:
> +Cc people from culprit commit

Guys, revert helps. I am open to test any solution you may propose, thanks!

...

> # first bad commit: [757055ae8dedf5333af17b3b5b4b70ba9bc9da4e] init/console: Use ttynull as a fallback when there is no console

-- 
With Best Regards,
Andy Shevchenko

Re: kunit stopped working

[David Gow]

On Tue, Dec 22, 2020 at 4:02 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Dec 21, 2020 at 09:40:08PM +0200, Andy Shevchenko wrote:
> > +Cc people from culprit commit
>
> Guys, revert helps. I am open to test any solution you may propose, thanks!
>
> ...
>
> > # first bad commit: [757055ae8dedf5333af17b3b5b4b70ba9bc9da4e] init/console: Use ttynull as a fallback when there is no console
>
> --

+CC linux-um

There appear to be two problems here:
1. UML now no longer has console output by default (which KUnit needs
to get results)
2. UML now seems to crash on startup when ttynull is used (which is now default)

This can be worked around for KUnit by passing console=tty to the
kernel. I don't think this is a "correct" fix, as UML seems to be
crashing out-of-the-box anyway (see below), but it may be worth us
forcing this as we require the console output as well.

In any case, this patch fixes it in kunit_tool for now. I may submit
this as a proper patch anyway, but that won't fix UML in general:

diff --git a/tools/testing/kunit/kunit_kernel.py
b/tools/testing/kunit/kunit_kernel.py
index 57c1724b7e5d..698358c9c0d6 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -198,7 +198,7 @@ class LinuxSourceTree(object):
               return self.validate_config(build_dir)

       def run_kernel(self, args=[], build_dir='', timeout=None):
-               args.extend(['mem=1G'])
+               args.extend(['mem=1G', 'console=tty'])
               self._ops.linux_bin(args, timeout, build_dir)
               outfile = get_outfile_path(build_dir)
               subprocess.call(['stty', 'sane'])

---

It looks like this is breaking UML entirely by default, though: if I
start ./vmlinux, I get a SIGSEGV in n_tty_open() early on. It looks
like this is due to the ttynull driver trying to be opened and, for
whatever reason, `ldata' is pointing to invalid memory. I'm not sure
why this is broken but it definitely looks like ttynull is just
completely crashing UML at the moment.
The kernel output and stacktrace look like this:
Core dump limits :
       soft - 0
       hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking environment variables for a tempdir...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...OK
Program received signal SIGSEGV, Segmentation fault.
0x00000000601bf17c in n_tty_open (tty=0x6064d800) at
../drivers/tty/n_tty.c:1920
1920            ldata->overrun_time = jiffies;
(gdb) bt
#0  0x00000000601bf17c in n_tty_open (tty=0x6064d800) at
../drivers/tty/n_tty.c:1920
#1  0x00000000601c54e3 in tty_ldisc_open (ld=0x6041a020,
tty=0x6064d800) at ../drivers/tty/tty_ldisc.c:463
#2  tty_ldisc_setup (tty=tty@entry=0x6064d800, o_tty=0x0) at
../drivers/tty/tty_ldisc.c:773
#3  0x00000000601bcb36 in tty_init_dev
(driver=driver@entry=0x6040fb40, idx=0) at
../drivers/tty/tty_io.c:1366
#4  0x00000000601bd822 in tty_open_by_driver (filp=0x60407200,
device=5242881) at ../drivers/tty/tty_io.c:1987
#5  tty_open (inode=0x608050c0, filp=0x60407200) at ../drivers/tty/tty_io.c:2035
#6  0x00000000600ee087 in chrdev_open (inode=inode@entry=0x608050c0,
filp=filp@entry=0x60407200) at ../fs/char_dev.c:414
#7  0x00000000600e40c9 in do_dentry_open (f=f@entry=0x60407200,
inode=0x608050c0, open=0x600ee030 <chrdev_open>, open@entry=0x0) at
../fs/open.c:817
#8  0x00000000600e59d8 in vfs_open (path=path@entry=0x60433db0,
file=file@entry=0x60407200) at ../include/linux/dcache.h:552
#9  0x00000000600fa371 in do_open (op=0x60433ed0, file=0x60407200,
nd=0x60433db0) at ../fs/namei.c:3252
#10 path_openat (nd=nd@entry=0x60433db0, op=op@entry=0x60433ed0,
flags=flags@entry=65) at ../fs/namei.c:3369
#11 0x00000000600fa7ec in do_filp_open (dfd=dfd@entry=-100,
pathname=pathname@entry=0x60498000, op=op@entry=0x60433ed0) at
../fs/namei.c:3396
#12 0x00000000600e5f31 in file_open_name (name=name@entry=0x60498000,
flags=flags@entry=2, mode=mode@entry=0) at ../fs/open.c:1117
#13 0x00000000600e605e in filp_open
(filename=filename@entry=0x6025e26f "/dev/console",
flags=flags@entry=2, mode=mode@entry=0) at ../fs/open.c:1137
#14 0x0000000060001f03 in console_on_rootfs () at ../init/main.c:1480
#15 0x00000000600021b4 in kernel_init_freeable () at ../init/main.c:1536
#16 0x0000000060218bde in kernel_init (unused=<optimized out>) at
../init/main.c:1415
#17 0x00000000600184a1 in new_thread_handler () at
../arch/um/kernel/process.c:136
#18 0x0000000000000000 in ?? ()

Does anyone know why ttynull is being used by default on UML even when
there's the better 'tty' console driver to use? Either way, it'd be
nice if it didn't crash things, too.

Cheers,
-- David

Re: kunit stopped working

[David Gow]

On Tue, Dec 22, 2020 at 9:43 AM David Gow <davidgow@google.com> wrote:
>
> On Tue, Dec 22, 2020 at 4:02 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Dec 21, 2020 at 09:40:08PM +0200, Andy Shevchenko wrote:
> > > +Cc people from culprit commit
> >
> > Guys, revert helps. I am open to test any solution you may propose, thanks!
> >
> > ...
> >
> > > # first bad commit: [757055ae8dedf5333af17b3b5b4b70ba9bc9da4e] init/console: Use ttynull as a fallback when there is no console
> >
> > --
>
> +CC linux-um
>
> There appear to be two problems here:
> 1. UML now no longer has console output by default (which KUnit needs
> to get results)
> 2. UML now seems to crash on startup when ttynull is used (which is now default)

Whoops. I was wrong about number 2 here (thanks Johannes for pointing
that out). The segfault in n_tty_open() actually happens normally as
part of UML startup, and it's recovered from perfectly.

So the only real issue is that this is changing the default console
output to ttynull, and hence hiding the output.

>
> This can be worked around for KUnit by passing console=tty to the
> kernel. I don't think this is a "correct" fix, as UML seems to be
> crashing out-of-the-box anyway (see below), but it may be worth us
> forcing this as we require the console output as well.
>
> In any case, this patch fixes it in kunit_tool for now. I may submit
> this as a proper patch anyway, but that won't fix UML in general:
>
> diff --git a/tools/testing/kunit/kunit_kernel.py
> b/tools/testing/kunit/kunit_kernel.py
> index 57c1724b7e5d..698358c9c0d6 100644
> --- a/tools/testing/kunit/kunit_kernel.py
> +++ b/tools/testing/kunit/kunit_kernel.py
> @@ -198,7 +198,7 @@ class LinuxSourceTree(object):
>                return self.validate_config(build_dir)
>
>        def run_kernel(self, args=[], build_dir='', timeout=None):
> -               args.extend(['mem=1G'])
> +               args.extend(['mem=1G', 'console=tty'])
>                self._ops.linux_bin(args, timeout, build_dir)
>                outfile = get_outfile_path(build_dir)
>                subprocess.call(['stty', 'sane'])
>

I'll send this out properly as a patch to kunit_tool: while I still
think that the default console on UML shouldn't change, it probably
makes sense for KUnit to not rely on the default.

Cheers,
-- David

Re: kunit stopped working

[Andy Shevchenko]

On Tue, Dec 22, 2020 at 03:26:24PM +0800, David Gow wrote:
> On Tue, Dec 22, 2020 at 9:43 AM David Gow <davidgow@google.com> wrote:
> > On Tue, Dec 22, 2020 at 4:02 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Mon, Dec 21, 2020 at 09:40:08PM +0200, Andy Shevchenko wrote:

...

> > > Guys, revert helps. I am open to test any solution you may propose, thanks!

...

> I'll send this out properly as a patch to kunit_tool: while I still
> think that the default console on UML shouldn't change, it probably
> makes sense for KUnit to not rely on the default.

Thanks for fast response. I have tested and answered to the patch.

-- 
With Best Regards,
Andy Shevchenko

Re: kunit stopped working

[Brendan Higgins]

On Tue, Dec 22, 2020 at 5:33 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Dec 22, 2020 at 03:26:24PM +0800, David Gow wrote:
> > On Tue, Dec 22, 2020 at 9:43 AM David Gow <davidgow@google.com> wrote:
> > > On Tue, Dec 22, 2020 at 4:02 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Mon, Dec 21, 2020 at 09:40:08PM +0200, Andy Shevchenko wrote:
>
> ...
>
> > > > Guys, revert helps. I am open to test any solution you may propose, thanks!
>
> ...
>
> > I'll send this out properly as a patch to kunit_tool: while I still
> > think that the default console on UML shouldn't change, it probably
> > makes sense for KUnit to not rely on the default.
>
> Thanks for fast response. I have tested and answered to the patch.

Sorry all, I was and still am on vacation.

Looks like this was taken care of, nevertheless, I will make sure to
go and ACK David's fix.

Re: kunit stopped working

[Petr Mladek]

On Tue 2020-12-22 09:43:48, David Gow wrote:
> On Tue, Dec 22, 2020 at 4:02 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Dec 21, 2020 at 09:40:08PM +0200, Andy Shevchenko wrote:
> > > +Cc people from culprit commit
> >
> > Guys, revert helps. I am open to test any solution you may propose, thanks!
> >
> > ...
> >
> > > # first bad commit: [757055ae8dedf5333af17b3b5b4b70ba9bc9da4e] init/console: Use ttynull as a fallback when there is no console
> >
> > --
> 
> +CC linux-um
> 
> There appear to be two problems here:
> 1. UML now no longer has console output by default (which KUnit needs
> to get results)

> This can be worked around for KUnit by passing console=tty to the
> kernel. I don't think this is a "correct" fix

It is rather a workaround. ttynull was supposed to be an ultimate
fallback to provide a "valid" stdin, stdout, and stderr for
the init process. ttyX still should be used by default when
there is no console defined on the command line.

So the question is why ttyX was not registered with this patch.

I see the problem even when I revert the commit
757055ae8dedf5333af ("init/console: Use ttynull as a fallback when
there is no console") and enable the ttynull driver as built in:

     CONFIG_NULL_TTY=y

By other words, the problem existed even before. The commit only
made it visible by default.

I am still trying to understand arch/um and kunit code. I wonder
if it is somehow related to stdiocons implemented in
arch/um/drivers/stdio_console.c.

Best Regards,
Petr

Re: kunit stopped working

[Petr Mladek]

On Tue 2021-01-05 17:17:08, Petr Mladek wrote:
> On Tue 2020-12-22 09:43:48, David Gow wrote:
> > On Tue, Dec 22, 2020 at 4:02 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > On Mon, Dec 21, 2020 at 09:40:08PM +0200, Andy Shevchenko wrote:
> > > > +Cc people from culprit commit
> > >
> > > Guys, revert helps. I am open to test any solution you may propose, thanks!
> > >
> > > ...
> > >
> > > > # first bad commit: [757055ae8dedf5333af17b3b5b4b70ba9bc9da4e] init/console: Use ttynull as a fallback when there is no console
> > >
> > > --
> > 
> > +CC linux-um
> > 
> > There appear to be two problems here:
> > 1. UML now no longer has console output by default (which KUnit needs
> > to get results)
> 
> > This can be worked around for KUnit by passing console=tty to the
> > kernel. I don't think this is a "correct" fix
> 
> It is rather a workaround. ttynull was supposed to be an ultimate
> fallback to provide a "valid" stdin, stdout, and stderr for
> the init process. ttyX still should be used by default when
> there is no console defined on the command line.
> 
> So the question is why ttyX was not registered with this patch.
> 
> I see the problem even when I revert the commit
> 757055ae8dedf5333af ("init/console: Use ttynull as a fallback when
> there is no console") and enable the ttynull driver as built in:
> 
>      CONFIG_NULL_TTY=y
> 
> By other words, the problem existed even before. The commit only
> made it visible by default.
> 
> I am still trying to understand arch/um and kunit code. I wonder
> if it is somehow related to stdiocons implemented in
> arch/um/drivers/stdio_console.c.

The following change solved the problem for me as well. It causes
that ttynull is initialized after stdiocons console.

diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
index eced70ec54e1..602af4d30bd4 100644
--- a/drivers/tty/ttynull.c
+++ b/drivers/tty/ttynull.c
@@ -121,7 +121,6 @@ static void __exit ttynull_exit(void)
 	tty_port_destroy(&ttynull_port);
 }
 
-module_init(ttynull_init);
-module_exit(ttynull_exit);
+late_initcall_sync(ttynull_init);
 
 MODULE_LICENSE("GPL v2");

But I am not completely sure that it is the right solution.

It is strange. Console should get registered only when
it was added by add_preferred_console(). It means that
ttynull_init() should not register by default.

Some clue might be in stderr_console. It has
to be explicitly unregistered to avoid staying as
the default console, see unregister_stderr() in
arch/um/drivers/stderr_console.c

I am going to dig more into it.

Best Regards,
Petr

Re: kunit stopped working

[Sergey Senozhatsky]

On (21/01/05 17:49), Petr Mladek wrote:
> The following change solved the problem for me as well. It causes
> that ttynull is initialized after stdiocons console.
> 
> diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
> index eced70ec54e1..602af4d30bd4 100644
> --- a/drivers/tty/ttynull.c
> +++ b/drivers/tty/ttynull.c
> @@ -121,7 +121,6 @@ static void __exit ttynull_exit(void)
>  	tty_port_destroy(&ttynull_port);
>  }
>  
> -module_init(ttynull_init);
> -module_exit(ttynull_exit);
> +late_initcall_sync(ttynull_init);
>  
>  MODULE_LICENSE("GPL v2");
> 
> But I am not completely sure that it is the right solution.

Wow, hmm, puzzled. Why does it help?

> It is strange. Console should get registered only when
> it was added by add_preferred_console(). It means that
> ttynull_init() should not register by default.
[..]
> Some clue might be in stderr_console. It has
> to be explicitly unregistered to avoid staying as
> the default console, see unregister_stderr() in
> arch/um/drivers/stderr_console.c

Hmm... Some random thoughts:

Looking at arch/um/drivers/stderr_console.c - it doesn't have tty
driver and it doesn't register one. So as far as console_device()
concerned we still don't have a workable console - it will return
NULL to tty_lookup_driver(), which will eventually return an error
to filp_open("/dev/console"); hence we'd call register_ttynull_console()
from console_on_rootfs(). So now we register ttynull as preferred
console; hence when another console attempts to register itself we
don't set CON_CONSDEV on it, because of `has_preferred_console`.

But I still don't understand why the initcall patch helped.
Can you shed some light on it?

	-ss

Re: kunit stopped working

[Petr Mladek]

On Wed 2021-01-06 13:04:57, Sergey Senozhatsky wrote:
> On (21/01/05 17:49), Petr Mladek wrote:
> > The following change solved the problem for me as well. It causes
> > that ttynull is initialized after stdiocons console.
> > 
> > diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
> > index eced70ec54e1..602af4d30bd4 100644
> > --- a/drivers/tty/ttynull.c
> > +++ b/drivers/tty/ttynull.c
> > @@ -121,7 +121,6 @@ static void __exit ttynull_exit(void)
> >  	tty_port_destroy(&ttynull_port);
> >  }
> >  
> > -module_init(ttynull_init);
> > -module_exit(ttynull_exit);
> > +late_initcall_sync(ttynull_init);
> >  
> >  MODULE_LICENSE("GPL v2");
> > 
> > But I am not completely sure that it is the right solution.
> 
> Wow, hmm, puzzled. Why does it help?

I have been as well. But it seems that I got it, see below.

> > It is strange. Console should get registered only when
> > it was added by add_preferred_console(). It means that
> > ttynull_init() should not register by default.
> [..]
> > Some clue might be in stderr_console. It has
> > to be explicitly unregistered to avoid staying as
> > the default console, see unregister_stderr() in
> > arch/um/drivers/stderr_console.c
> 
> Hmm... Some random thoughts:
> 
> Looking at arch/um/drivers/stderr_console.c - it doesn't have tty
> driver and it doesn't register one.

stderr_console.c is used only during early boot.

stdio_console.c is the console that is supposed to print kunit
test results. And it has tty driver.

> But I still don't understand why the initcall patch helped.
> Can you shed some light on it?

The trick is that both stdio_init() and ttynull_init():

  + call register_console()
  + the console has tty driver

The first one is registered as a fallback when there is
no preferred console (has_preferred_console()).

It means that late_initcall_sync(ttynull_init) makes sense.
We need to call register_console() from ttynull_init() so that
it is registered when defined on the command line. But it should
be the last chance to register a fallback console with tty binding.

Alternative solution is to ignore ttynull as the fallback console
in register_console(). I mean the following:

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index ffdd0dc7ec6d..cdb77903b0af 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2816,8 +2816,12 @@ void register_console(struct console *newcon)
 	 *	See if we want to use this console driver. If we
 	 *	didn't select a console we take the first one
 	 *	that registers here.
+	 *
+	 *	Ignore ttynull console. It should be used only
+	 *	when explicitly configured or as an ultimate
+	 *	fallback when no better console gets registered at all.
 	 */
-	if (!has_preferred_console) {
+	if (!has_preferred_console && strcmp(newcon->name, "ttynull") != 0) {
 		if (newcon->index < 0)
 			newcon->index = 0;
 		if (newcon->setup == NULL ||


Best Regards,
Petr

Re: kunit stopped working

[Sergey Senozhatsky]

On (21/01/06 14:10), Petr Mladek wrote:
> > > 
> > > But I am not completely sure that it is the right solution.
> > 
> > Wow, hmm, puzzled. Why does it help?
> 
> I have been as well. But it seems that I got it, see below.

Thanks!

[..]
> 
> Alternative solution is to ignore ttynull as the fallback console
> in register_console(). I mean the following:

I personally would prefer a very explicit fix (IOW, the patch below),
rather than relying on some initcall trickery (which has already
failed on us)

> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index ffdd0dc7ec6d..cdb77903b0af 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2816,8 +2816,12 @@ void register_console(struct console *newcon)
>  	 *	See if we want to use this console driver. If we
>  	 *	didn't select a console we take the first one
>  	 *	that registers here.
> +	 *
> +	 *	Ignore ttynull console. It should be used only
> +	 *	when explicitly configured or as an ultimate
> +	 *	fallback when no better console gets registered at all.
>  	 */
> -	if (!has_preferred_console) {
> +	if (!has_preferred_console && strcmp(newcon->name, "ttynull") != 0) {
>  		if (newcon->index < 0)
>  			newcon->index = 0;
>  		if (newcon->setup == NULL ||

So IIUC in case of ttynull fallback (console= ) we still end up setting
CON_CONSDEV on nulltty console, but we do it in try_enable_new_console().

Feel free to add
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

	-ss