please use the smr_accessors. I would really like that idiom to spread. People will copy this pattern.

smr accessor.

linker_root_mounted() seems like a more accurate name.

Why is it useful to have distinct LOCKED and XLOCKED accessors? Just so we can strengthen the assertion? It seems like overkill to me since the distinction doesn't matter wrt to SMR.

I like that the intent is expressed here. There is no problem stemming from having this macro.

Don't we only really need this in other headers? Do we need the accessors too?

Can you do else /* !KERNEL */ above this.

thank you for converting

I wonder if there is a fancier way to express this.

Is there no assert here? And if not, does it need to be serialized? Is a barrier necessary?

For this kind of synchronization I would like to try to reinforce either documenting with assert or comment what is expected.

Are we guaranteed by the write order that we won't spin? The entry is cleared before ref reaches zero?

This is for const prop?

can you add all fields are const after initialization?

If we move these out I would want a stronger comment directing readers. Or possibly even make this sys/smr.h and the rest sys/smrapi.h or smr_int.h or something. Let's discuss.

Is there any reason we can't have an anonymous smr pointer type, akin to what TAILQ_ENTRY and TAILQ_HEAD do? For radix we need a type, but I don't see its purpose here.

My point is that the intent doesn't matter from the perspective of SMR, but the existence of separate macros makes it seem otherwise.

SMR queue macros will have to go somewhere as well. _smr.h seems like the wrong place if it's going to continue growing, so I like the idea of having a separate header. smr_accessors.h maybe.

We could also add a SMR_POINTER(struct foo) bar or something.

I'm not totally sure I understand the objection either. I guess in some sense we are using the smr assert for a dual purpose here but I think this is in the spirit of the thing.

Smr as it stands is more user facing already. There is very little in the way of implementation exposed other than the structs and I would prefer to keep smr_enter() inline.

For a case like pwd that really wants these macros we might just bend the header rules and let it include sys/smr.h. Many system headers include sys/queue.h already.

Here the struct is never used, should be clear from the context.

The code replaces the struct, releases the lock and only then drops the old one. Meaning the replacement is published before the old object is freed.

This is not going to spin practice, even if several threads continuously keep changing pwd. For that to loop more than once pwd_hold consumer would have to keep getting incredibly unlucky with interrupts getting in the way so that it never manages to catch a non-zero object.

If you mean to avoid a trip through memset in uma and let the compiler generate (and elide) some movs here, yes. In fact I would argue the M_ZERO flag for uma should be avoided.

We do, see pwd_set which is an inline in filedesc.h otherwise i would have to code it up as a macro or a function.

An anonymous type will be probably useful, but for a consumer like this it would just remove type checking by the compiler. As it is the difference to the stock kernel is that apart from the type being checked we also assert on smr.

there probably is but i think this falls beyond the scope of this patch. should someone come up with a good idea this is easy to convert.

these macros are intended to be used with struct filedesc and all patched xlocked consumers intend to replace the original. In particular should the code get refactored to get a pointer to fdp, it can avoid:

FILEDESC_XLOCK(fdp);
pwd = FILEDESC_LOCKED_LOAD_PWD(fdp);

I don't think it's a significant deal one way or the other and I prefer this style.

I have no opinion, just a requirement that I can use these in filedesc.h without trouble which on stock kernel is not possible due to inlines in the smr.h header. Attempts to add missing headers run into drastic issues, thus the initial _smr.h approach. Tl;dr I would prefer if someone dealt with the problem however they see fit, as long as the above requirement is met. It's definitely going to cause trouble for others.

I don't object, but I don't really see the point of having multiple macros to do the same thing. If the idea is to be as specific as possible, why don't we also have FILEDESC_SLOCKED_LOAD_PWD()? It just seems a bit confusing to me.

It might become trickier over time. smr_enter_preempt() uses sched_pin(), which pulls in sched.h, for instance. Maybe the solution there is to just not have it be an inline.

The SMR accessors and type declaration macros are much more likely to be used in a header than smr_enter(), so I do think it is preferable in the long term to have them be in separate headers, whether that's _smr.h or something else.

I can't see the advantage of having smrpwd_t instead of

struct filedesc {
    ...
    SMR_POINTER(struct pwd *) fd_pwd;
    ...

with D23988. What type-checking does it provide?

Ok, I added smr_types.h in D23988. I also changed SMR_TYPE_DECLARE a bit.

I have a patch which adds a

#define __smr_ex_eval(x) __builtin_choose_expr(__builtin_types_compatible_p(__typeof(x), void), ((x), 1), (x))

so the expression can be a void function call and you don't need the ", true". I tried to do it with _Generic but I don't think it's possible, you can't match on "void".

ok, but then the comment which gives an example with mtx_owned somewhere in smr headers should be augmented. that is, the recommendation should be to use the actual assertion routine and only resort to directly testing something if that's absent.

given that asserts here got abstracted into few places i think this can be patched later after the above is sorted out. I'm trying to reduce my patch queue due to the fast path lookup work.