On Mon, Dec 18, 2023 at 10:04:39PM -0500, Waiman Long wrote: > > On 12/18/23 20:46, Kent Overstreet wrote: > > On Mon, Dec 18, 2023 at 11:53:08AM -0500, Waiman Long wrote: > > > On 12/15/23 22:26, Kent Overstreet wrote: > > > > -#include <linux/rtmutex.h> > > > Including rtmutex.h here means that mutex_types.h is no longer a simple > > > header for types only. So unless you also break out a rtmutex_types.h, it is > > > inconsistent. > > good observation, I'll have to leave it for the next round of cleanups > > though since the merge window is approaching and I'll have to redo all > > the testing. > > > > > Besides, the kernel/sched code does use mutex_lock/unlock calls quite > > > frequently. With this patch, mutex.h will not be directly included. I > > > suspect that it is indirectly included via other header files. This may be > > > an issue with some configurations. > > I've now put it through randconfig testing on every arch that debian > > includes a compiler for (excluding sh and xtensa, which throw internal > > compiler errors) and that one hasn't come up yet. > > > > could still be included indirectly though - I haven't checked for that > > one specifically yet. > > If you are replacing mutex.h in include/linux/sched.h by mutex_types.h, I > would suggest you add mutex.h to kernel/sched/sched.h to ensure this header > file is included by the scheduler code. It already does, via mutex_api.h...