more __diagused to appease clang

kern: Mark some functions __diagused to pacify clang.

These functions are called only in KASSERT. This shouldn't be a
problem since the recent change to make KASSERT compile (but not run)
the expression, via sizeof, so the functions are referenced -- which
I did in order to avoid having #ifdefs and regular build breakage
because someone forgot to build with or without DIAGNOSTIC. But
apparently clang decided to make it a problem.

Maybe we should just set -Wno-unneeded-internal-declaration -- not
clear it flags any real problems, but it takes effort to research
because apparently clang has no documentation about what else it does
or why anyone decided this is objectionable enough to turn it on by
default. (The only documentation it seems to have, two example
warning messages with no elaboration at
<https://releases.llvm.org/13.0.0/tools/clang/docs/DiagnosticsReference.html#wunneeded-internal-declaration>,
seems to indicate it is mixed up with warning about static non-inline
functions in header files.)

libkern: Make KASSERT verify expression is valid if !DIAGNOSTIC.

This way it is no longer necessary to mark variables __diagused if
they are used in KASSERT conditions.

Fix fallout from this by removing now-unnecessary and `#ifdef
DIAGNOSTIC'.

Don't do the same for KDASSERT if !DEBUG -- unlike KASSERT and
DIAGNOSTIC, variables needed by KDASSERT and DEBUG are likely to be
expensive to compute (and potentially difficult for a compiler to
prove flushable), so we don't want to require them under !DEBUG.

need <sys/param.h> for COHERENCY_UNIT

Minor KNF along the way.

psref(9): Make use-after-free panic message more obvious.

Previously it would almost always manifest as

mismatched psref target class: 0x0 (ref) != 0x... (expected)

and now it will manifest as

psref target already destroyed: 0x...

branches: 1.13.14;
Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence of a
leak.

Investigating of psref leaks is hard because once a leak occurs a percpu list of
psref that tracks references can be corrupted. A reference to a tracking object
is memorized in the list via an intermediate object (struct psref) that is
normally allocated on a stack of a thread. Thus, the intermediate object can be
overwritten on a leak resulting in corruption of the list.

The tracker makes a shadow entry to an intermediate object and stores some hints
into it (currently it's a caller address of psref_acquire). We can detect a
leak by checking the entries on certain points where any references should be
released such as the return point of syscalls and the end of each softint
handler.

The feature is expensive and enabled only if the kernel is built with
PSREF_DEBUG.

Proposed on tech-kern

Implement a simple psref leak detector

It detects leaks by counting up the number of held psref by an LWP and checking
its zeroness at the end of syscalls and softint handlers. For the counter, a
unused field of struct lwp is reused.

The detector runs only if DIAGNOSTIC is turned on.

branches: 1.11.4;
Use high priority xcall with a softint of an IPL the same as psref class's one

This mitigates undesired delay of psref_target_destroy under load such as heavy
netowrk traffic that loads softint.

Prevent panic or hangup in softint_disestablish(), pserialize_perform() or
psref_target_destroy() while mp_online == false.

See http://mail-index.netbsd.org/tech-kern/2017/12/25/msg022829.html

Improve debugging functions

- Make psref_check_duplication check just if a given psref is on the list
- It checked both psref and target
- Suggested by riastradh@ some time ago
- Add psref_check_existence that checks a releasing psref is surely on the list

Fix psref(9) part of PR kern/52515. It is complete to fix the PR now.

implementated by ozaki-r@n.o, reviewed by riastradh@n.o, thanks.

XXX need pullup-8

branches: 1.7.2; 1.7.8;
remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

kern: Mark some functions __diagused to pacify clang.

These functions are called only in KASSERT. This shouldn't be a
problem since the recent change to make KASSERT compile (but not run)
the expression, via sizeof, so the functions are referenced -- which
I did in order to avoid having #ifdefs and regular build breakage
because someone forgot to build with or without DIAGNOSTIC. But
apparently clang decided to make it a problem.

Maybe we should just set -Wno-unneeded-internal-declaration -- not
clear it flags any real problems, but it takes effort to research
because apparently clang has no documentation about what else it does
or why anyone decided this is objectionable enough to turn it on by
default. (The only documentation it seems to have, two example
warning messages with no elaboration at
<https://releases.llvm.org/13.0.0/tools/clang/docs/DiagnosticsReference.html#wunneeded-internal-declaration>,
seems to indicate it is mixed up with warning about static non-inline
functions in header files.)

libkern: Make KASSERT verify expression is valid if !DIAGNOSTIC.

This way it is no longer necessary to mark variables __diagused if
they are used in KASSERT conditions.

Fix fallout from this by removing now-unnecessary and `#ifdef
DIAGNOSTIC'.

Don't do the same for KDASSERT if !DEBUG -- unlike KASSERT and
DIAGNOSTIC, variables needed by KDASSERT and DEBUG are likely to be
expensive to compute (and potentially difficult for a compiler to
prove flushable), so we don't want to require them under !DEBUG.

need <sys/param.h> for COHERENCY_UNIT

Minor KNF along the way.

psref(9): Make use-after-free panic message more obvious.

Previously it would almost always manifest as

mismatched psref target class: 0x0 (ref) != 0x... (expected)

and now it will manifest as

psref target already destroyed: 0x...

branches: 1.13.14;
Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence of a
leak.

Investigating of psref leaks is hard because once a leak occurs a percpu list of
psref that tracks references can be corrupted. A reference to a tracking object
is memorized in the list via an intermediate object (struct psref) that is
normally allocated on a stack of a thread. Thus, the intermediate object can be
overwritten on a leak resulting in corruption of the list.

The tracker makes a shadow entry to an intermediate object and stores some hints
into it (currently it's a caller address of psref_acquire). We can detect a
leak by checking the entries on certain points where any references should be
released such as the return point of syscalls and the end of each softint
handler.

The feature is expensive and enabled only if the kernel is built with
PSREF_DEBUG.

Proposed on tech-kern

Implement a simple psref leak detector

It detects leaks by counting up the number of held psref by an LWP and checking
its zeroness at the end of syscalls and softint handlers. For the counter, a
unused field of struct lwp is reused.

The detector runs only if DIAGNOSTIC is turned on.

branches: 1.11.4;
Use high priority xcall with a softint of an IPL the same as psref class's one

This mitigates undesired delay of psref_target_destroy under load such as heavy
netowrk traffic that loads softint.

Prevent panic or hangup in softint_disestablish(), pserialize_perform() or
psref_target_destroy() while mp_online == false.

See http://mail-index.netbsd.org/tech-kern/2017/12/25/msg022829.html

Improve debugging functions

- Make psref_check_duplication check just if a given psref is on the list
- It checked both psref and target
- Suggested by riastradh@ some time ago
- Add psref_check_existence that checks a releasing psref is surely on the list

Fix psref(9) part of PR kern/52515. It is complete to fix the PR now.

implementated by ozaki-r@n.o, reviewed by riastradh@n.o, thanks.

XXX need pullup-8

branches: 1.7.2; 1.7.8;
remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

libkern: Make KASSERT verify expression is valid if !DIAGNOSTIC.

This way it is no longer necessary to mark variables __diagused if
they are used in KASSERT conditions.

Fix fallout from this by removing now-unnecessary and `#ifdef
DIAGNOSTIC'.

Don't do the same for KDASSERT if !DEBUG -- unlike KASSERT and
DIAGNOSTIC, variables needed by KDASSERT and DEBUG are likely to be
expensive to compute (and potentially difficult for a compiler to
prove flushable), so we don't want to require them under !DEBUG.

need <sys/param.h> for COHERENCY_UNIT

Minor KNF along the way.

psref(9): Make use-after-free panic message more obvious.

Previously it would almost always manifest as

mismatched psref target class: 0x0 (ref) != 0x... (expected)

and now it will manifest as

psref target already destroyed: 0x...

branches: 1.13.14;
Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence of a
leak.

Investigating of psref leaks is hard because once a leak occurs a percpu list of
psref that tracks references can be corrupted. A reference to a tracking object
is memorized in the list via an intermediate object (struct psref) that is
normally allocated on a stack of a thread. Thus, the intermediate object can be
overwritten on a leak resulting in corruption of the list.

The tracker makes a shadow entry to an intermediate object and stores some hints
into it (currently it's a caller address of psref_acquire). We can detect a
leak by checking the entries on certain points where any references should be
released such as the return point of syscalls and the end of each softint
handler.

The feature is expensive and enabled only if the kernel is built with
PSREF_DEBUG.

Proposed on tech-kern

Implement a simple psref leak detector

It detects leaks by counting up the number of held psref by an LWP and checking
its zeroness at the end of syscalls and softint handlers. For the counter, a
unused field of struct lwp is reused.

The detector runs only if DIAGNOSTIC is turned on.

branches: 1.11.4;
Use high priority xcall with a softint of an IPL the same as psref class's one

This mitigates undesired delay of psref_target_destroy under load such as heavy
netowrk traffic that loads softint.

Prevent panic or hangup in softint_disestablish(), pserialize_perform() or
psref_target_destroy() while mp_online == false.

See http://mail-index.netbsd.org/tech-kern/2017/12/25/msg022829.html

Improve debugging functions

- Make psref_check_duplication check just if a given psref is on the list
- It checked both psref and target
- Suggested by riastradh@ some time ago
- Add psref_check_existence that checks a releasing psref is surely on the list

Fix psref(9) part of PR kern/52515. It is complete to fix the PR now.

implementated by ozaki-r@n.o, reviewed by riastradh@n.o, thanks.

XXX need pullup-8

branches: 1.7.2; 1.7.8;
remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

need <sys/param.h> for COHERENCY_UNIT

Minor KNF along the way.

psref(9): Make use-after-free panic message more obvious.

Previously it would almost always manifest as

mismatched psref target class: 0x0 (ref) != 0x... (expected)

and now it will manifest as

psref target already destroyed: 0x...

branches: 1.13.14;
Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence of a
leak.

Investigating of psref leaks is hard because once a leak occurs a percpu list of
psref that tracks references can be corrupted. A reference to a tracking object
is memorized in the list via an intermediate object (struct psref) that is
normally allocated on a stack of a thread. Thus, the intermediate object can be
overwritten on a leak resulting in corruption of the list.

The tracker makes a shadow entry to an intermediate object and stores some hints
into it (currently it's a caller address of psref_acquire). We can detect a
leak by checking the entries on certain points where any references should be
released such as the return point of syscalls and the end of each softint
handler.

The feature is expensive and enabled only if the kernel is built with
PSREF_DEBUG.

Proposed on tech-kern

Implement a simple psref leak detector

It detects leaks by counting up the number of held psref by an LWP and checking
its zeroness at the end of syscalls and softint handlers. For the counter, a
unused field of struct lwp is reused.

The detector runs only if DIAGNOSTIC is turned on.

branches: 1.11.4;
Use high priority xcall with a softint of an IPL the same as psref class's one

This mitigates undesired delay of psref_target_destroy under load such as heavy
netowrk traffic that loads softint.

Prevent panic or hangup in softint_disestablish(), pserialize_perform() or
psref_target_destroy() while mp_online == false.

See http://mail-index.netbsd.org/tech-kern/2017/12/25/msg022829.html

Improve debugging functions

- Make psref_check_duplication check just if a given psref is on the list
- It checked both psref and target
- Suggested by riastradh@ some time ago
- Add psref_check_existence that checks a releasing psref is surely on the list

Fix psref(9) part of PR kern/52515. It is complete to fix the PR now.

implementated by ozaki-r@n.o, reviewed by riastradh@n.o, thanks.

XXX need pullup-8

branches: 1.7.2; 1.7.8;
remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

psref(9): Make use-after-free panic message more obvious.

Previously it would almost always manifest as

mismatched psref target class: 0x0 (ref) != 0x... (expected)

and now it will manifest as

psref target already destroyed: 0x...

Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence of a
leak.

Investigating of psref leaks is hard because once a leak occurs a percpu list of
psref that tracks references can be corrupted. A reference to a tracking object
is memorized in the list via an intermediate object (struct psref) that is
normally allocated on a stack of a thread. Thus, the intermediate object can be
overwritten on a leak resulting in corruption of the list.

The tracker makes a shadow entry to an intermediate object and stores some hints
into it (currently it's a caller address of psref_acquire). We can detect a
leak by checking the entries on certain points where any references should be
released such as the return point of syscalls and the end of each softint
handler.

The feature is expensive and enabled only if the kernel is built with
PSREF_DEBUG.

Proposed on tech-kern

Implement a simple psref leak detector

It detects leaks by counting up the number of held psref by an LWP and checking
its zeroness at the end of syscalls and softint handlers. For the counter, a
unused field of struct lwp is reused.

The detector runs only if DIAGNOSTIC is turned on.

branches: 1.11.4;
Use high priority xcall with a softint of an IPL the same as psref class's one

This mitigates undesired delay of psref_target_destroy under load such as heavy
netowrk traffic that loads softint.

Prevent panic or hangup in softint_disestablish(), pserialize_perform() or
psref_target_destroy() while mp_online == false.

See http://mail-index.netbsd.org/tech-kern/2017/12/25/msg022829.html

Improve debugging functions

- Make psref_check_duplication check just if a given psref is on the list
- It checked both psref and target
- Suggested by riastradh@ some time ago
- Add psref_check_existence that checks a releasing psref is surely on the list

Fix psref(9) part of PR kern/52515. It is complete to fix the PR now.

implementated by ozaki-r@n.o, reviewed by riastradh@n.o, thanks.

XXX need pullup-8

branches: 1.7.2; 1.7.8;
remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence of a
leak.

Investigating of psref leaks is hard because once a leak occurs a percpu list of
psref that tracks references can be corrupted. A reference to a tracking object
is memorized in the list via an intermediate object (struct psref) that is
normally allocated on a stack of a thread. Thus, the intermediate object can be
overwritten on a leak resulting in corruption of the list.

The tracker makes a shadow entry to an intermediate object and stores some hints
into it (currently it's a caller address of psref_acquire). We can detect a
leak by checking the entries on certain points where any references should be
released such as the return point of syscalls and the end of each softint
handler.

The feature is expensive and enabled only if the kernel is built with
PSREF_DEBUG.

Proposed on tech-kern

Implement a simple psref leak detector

It detects leaks by counting up the number of held psref by an LWP and checking
its zeroness at the end of syscalls and softint handlers. For the counter, a
unused field of struct lwp is reused.

The detector runs only if DIAGNOSTIC is turned on.

Use high priority xcall with a softint of an IPL the same as psref class's one

This mitigates undesired delay of psref_target_destroy under load such as heavy
netowrk traffic that loads softint.

Prevent panic or hangup in softint_disestablish(), pserialize_perform() or
psref_target_destroy() while mp_online == false.

See http://mail-index.netbsd.org/tech-kern/2017/12/25/msg022829.html

Improve debugging functions

- Make psref_check_duplication check just if a given psref is on the list
- It checked both psref and target
- Suggested by riastradh@ some time ago
- Add psref_check_existence that checks a releasing psref is surely on the list

Fix psref(9) part of PR kern/52515. It is complete to fix the PR now.

implementated by ozaki-r@n.o, reviewed by riastradh@n.o, thanks.

XXX need pullup-8

branches: 1.7.2; 1.7.8;
remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

Implement a simple psref leak detector

It detects leaks by counting up the number of held psref by an LWP and checking
its zeroness at the end of syscalls and softint handlers. For the counter, a
unused field of struct lwp is reused.

The detector runs only if DIAGNOSTIC is turned on.

Use high priority xcall with a softint of an IPL the same as psref class's one

This mitigates undesired delay of psref_target_destroy under load such as heavy
netowrk traffic that loads softint.

Prevent panic or hangup in softint_disestablish(), pserialize_perform() or
psref_target_destroy() while mp_online == false.

See http://mail-index.netbsd.org/tech-kern/2017/12/25/msg022829.html

Improve debugging functions

- Make psref_check_duplication check just if a given psref is on the list
- It checked both psref and target
- Suggested by riastradh@ some time ago
- Add psref_check_existence that checks a releasing psref is surely on the list

Fix psref(9) part of PR kern/52515. It is complete to fix the PR now.

implementated by ozaki-r@n.o, reviewed by riastradh@n.o, thanks.

XXX need pullup-8

branches: 1.7.2; 1.7.8;
remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

Use high priority xcall with a softint of an IPL the same as psref class's one

This mitigates undesired delay of psref_target_destroy under load such as heavy
netowrk traffic that loads softint.

Prevent panic or hangup in softint_disestablish(), pserialize_perform() or
psref_target_destroy() while mp_online == false.

See http://mail-index.netbsd.org/tech-kern/2017/12/25/msg022829.html

Improve debugging functions

- Make psref_check_duplication check just if a given psref is on the list
- It checked both psref and target
- Suggested by riastradh@ some time ago
- Add psref_check_existence that checks a releasing psref is surely on the list

Fix psref(9) part of PR kern/52515. It is complete to fix the PR now.

implementated by ozaki-r@n.o, reviewed by riastradh@n.o, thanks.

XXX need pullup-8

branches: 1.7.2; 1.7.8;
remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

Prevent panic or hangup in softint_disestablish(), pserialize_perform() or
psref_target_destroy() while mp_online == false.

See http://mail-index.netbsd.org/tech-kern/2017/12/25/msg022829.html

Improve debugging functions

- Make psref_check_duplication check just if a given psref is on the list
- It checked both psref and target
- Suggested by riastradh@ some time ago
- Add psref_check_existence that checks a releasing psref is surely on the list

Fix psref(9) part of PR kern/52515. It is complete to fix the PR now.

implementated by ozaki-r@n.o, reviewed by riastradh@n.o, thanks.

XXX need pullup-8

branches: 1.7.2; 1.7.8;
remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

remove checks for failure after memory allocation calls that cannot fail:

kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()

all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!

Add a new sanity check to psref

It checks if a target being acquired is already acquired with
the same psref. It is usable but not lightweight, so enabled
only if DEBUG.

Fix an assertion in _psref_held

The assertion, psref->psref_lwp == curlwp, is valid only if the target
is held by the caller.

Reviewed by riastradh@

branches: 1.4.2; 1.4.4;
Split psref_held into internal and public variants.

For internal use, we expect psrefs to be held by other LWPs when
asking in the cross-call thread whether the target in question is
referenced.

For public use, the caller should not assert about some other LWP
holding a psref.

But the rest of the logic is the same.

Back out previous -- <sys/intr.h> does provide splraiseipl.

Man page says <sys/param.h>, but that's wrong.

The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!

Need <sys/param.h> for splraiseipl.

How did this pass the releng autobuilds before? We went through
several full builds of HEAD after I committed subr_psref.c.

Add passive references, intermediate between pserialize and refcount.

Discussed on tech-kern:

https://mail-index.netbsd.org/tech-kern/2016/01/24/msg020069.html

API is still experimental and likely to change. (Obvious changes:
either remove extra arguments everywhere, or shrink psref_target to a
single bit, at the expense of possibly valuable diagnostic checks.)
Should do some real testing before we use this in anger!