Re: kern/53884: fs/vfs/t_rmdirrace:lfs_race test case fails randomly on real hardware

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR kern/53884; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: dholland%NetBSD.org@localhost
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: kern/53884: fs/vfs/t_rmdirrace:lfs_race test case fails randomly on real hardware
Date: Sun, 20 Jan 2019 14:21:19 +0200

 I can make the test fail reliably by increasing the sleep(10) in
 src/tests/fs/vfs/t_rmdirrace.c to sleep(100).
 
 My current theory is that the test is falling victim to the
 following rump behavior documented in rump_lwproc(3):
  
      An implicit thread context is created every time the rump kernel
      is entered and disbanded upon exit.
 
 and this comment in rump_schedule():
 
 	/*
 	 * If there is no dedicated lwp, allocate a temp one and
 	 * set it to be free'd upon unschedule().  Use lwp0 context
 	 * for reserving the necessary resources.  Don't optimize
 	 * for this case -- anyone who cares about performance will
 	 * start a real thread.
 	 */
 
 That is, every call to lfs_bmapv() from the cleaner thread gets a new
 rump kernel lwp object (despite being made from the same host pthread),
 so second call will always fail the assertion that the lwp is the same
 as in the first call.
 
 I'm now testing a patch that adds a call to rump_pub_lwproc_newlwp()
 from the cleaner thread, like those that already exist in the worker
 threads of the tmpfs test in tests/fs/tmpfs/t_renamerace.c.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost