CVS log for src/sys/kern/subr_psref.c

Up to [cvs.NetBSD.org] / src / sys / kern

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

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.

Sync with HEAD.

need <sys/param.h> for COHERENCY_UNIT

Minor KNF along the way.

Sync w/ HEAD.

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...

Sync with HEAD

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.

Pull up following revision(s) (requested by ozaki-r in ticket #556):
	sys/sys/xcall.h: 1.6
	share/man/man9/xcall.9: 1.11-1.12
	sys/kern/subr_xcall.c: 1.21-1.25
Refer softint(9)
--
Support arbitrary softint IPLs in high priority xcall
The high priority xcall supported only a softint of IPL_SOFTSERIAL. It meant
that it didn't work for xcall callbacks depending on lower IPLs than
IPL_SOFTSERIAL.
The change makes xcall have multiple softints of IPLs and allow users to specify
arbitrary IPLs. Users can specify an IPL by XC_HIGHPRI_IPL passed to the 1st
argument of xc_broadcast or xc_unicast.
Note that xcall still serves requests one by one (i.e., doesn't run them
concurrently) even if requests have different IPLs.
Proposed on tech-kern@
--
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.
--
Try to fix the build: avoid duplicate case labels when IPL_SOFT* are
all the same.
--
Fix build of kernels that some (or all) IPL_SOFT* share a value (e.g., mips)
--
Avoid allocating unused softints that share a value of IPL between another
Sort XC_IPL_* in order of priority (NFC)

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.

Pull up following revision(s) (requested by jdolecek in ticket #506):
	sys/kern/kern_softint.c: revision 1.45
	sys/rump/librump/rumpkern/rump.c: revision 1.331
	sys/kern/subr_pserialize.c: revision 1.10
	sys/kern/subr_psref.c: revision 1.10
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
Set mp_online = true. This change might fix PR#52886.

Pull up following revision(s) (requested by ozaki-r in ticket #458):
	sys/sys/psref.h: 1.3
	sys/kern/subr_psref.c: 1.8-1.9
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.
--
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

 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

update from HEAD

Sync with HEAD

file subr_psref.c was added on branch tls-maxphys on 2017-12-03 11:38:45 +0000

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.

Sync with HEAD.  (Note that most of these changes are simply $NetBSD$
tag issues.)

Sync with HEAD

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.

Sync with HEAD

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@

Sync with HEAD

file subr_psref.c was added on branch nick-nhusb on 2016-04-22 15:44:16 +0000

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!