add MTX_NEW to creation of mutex after uma_zalloc...

[jmg]

Summary

Make sure that mtx_init does not assume clean memory.. If D2725,
this will no longer be the case, and the init will fail...

I have tested that this change compiles and boots w/o issues...
even a tail -f works w/o issue..

[kib]

sys/kern/vfs_subr.c

3598 ↗

(On Diff #6392)

Add spaces around '|'.

[jmg]

tomorrow..

sys/kern/vfs_subr.c

3598 ↗

(On Diff #6392)

I'm confused, I do know the rule about spaces around binary ops, but often for flags like these, the spaces are omitted.. Hmm... it does look like spaces wins 52k lines vs 8k lines..

I'll add the spaces as that is the style the file adds..

[mjg]

This particular piece of code actually expects a zeroed struct. In particular, you can see that neither mtx_init nor knlist_init initialize the whole struct, leaving e.g.vpi_events and vpi_revents indeterminate. Then vn_pollrecord immediately examines vpi_revents of a newly added object and we are in trouble.

In other words, while it was mtx_init which complained about junk-filled memory, the issue is bigger. initialisation here needs to either be done with M_ZERO or extended to cover missed fields. Uninitialised parts also include something from struct knlist, so it's more than zeroing 2 shorts, but I'm too lazy to check how to do deal with that knlist.

[jmg]

In D2890#56145, @mjg wrote:

This particular piece of code actually expects a zeroed struct. In particular, you can see that neither mtx_init nor knlist_init initialize the whole struct, leaving e.g.vpi_events and vpi_revents indeterminate. Then vn_pollrecord immediately examines vpi_revents of a newly added object and we are in trouble.

In other words, while it was mtx_init which complained about junk-filled memory, the issue is bigger. initialisation here needs to either be done with M_ZERO or extended to cover missed fields. Uninitialised parts also include something from struct knlist, so it's more than zeroing 2 shorts, but I'm too lazy to check how to do deal with that knlist.

umm... knlist_init fully initializes the whole struct, where do you get this info?

In D2890#56145, @mjg wrote:

This particular piece of code actually expects a zeroed struct. In particular, you can see that neither mtx_init nor knlist_init initialize the whole struct, leaving e.g.vpi_events and vpi_revents indeterminate. Then vn_pollrecord immediately examines vpi_revents of a newly added object and we are in trouble.

In other words, while it was mtx_init which complained about junk-filled memory, the issue is bigger. initialisation here needs to either be done with M_ZERO or extended to cover missed fields. Uninitialised parts also include something from struct knlist, so it's more than zeroing 2 shorts, but I'm too lazy to check how to do deal with that knlist.

Agreed, testing patch w/ M_ZERO now.

I assume you mean selinfo isn't fully initialized? I verified that knlist_init fully initializes it's part... The problem is that selinfo doesn't have an initializer, and really, we should create an API that combines selinfo and knlist together, but that's another review/time.

[jmg]

switch to zero'ing all of memory, as selinfo and other fields aren't
properly initalized..

[jmg]

changed to using M_ZERO instead... Maintainer should clean this up more.

[mjg]

I assume you mean selinfo isn't fully initialized? I verified that knlist_init fully initializes it's part... The problem is that selinfo doesn't have an initializer, and really, we should create an API that combines selinfo and knlist together, but that's another review/time.

yeah, that's what I meant. And yeah, I'm too lazy to come up with a solution and then do a sweep over the tree.

M_ZERO looks fine as a temporary (right) solution.