Otherwise the compiler may reorder these around loads and stores,
which mostly defeats the purpose. `asm volatile' just ensures the
instruction isn't _deleted_; it may still move around.
Can probably delete some of the round-trips between bus addresses and
physical addresses -- did these only to copy the logic already in
_bus_dmamap_load_buffer.
The MD device enumeration sets the property on, e.g., PCI devices --
not on drm framebuffer children, which are mostly a software
abstraction. Not sure examining the nouveaufb, intelfb, &c., device
properties is worthwhile at all, but in case it breaks something
let's just leave it in while we're fixing other things.
This way acpica.h always exists unconditionally, so MI code can be
conditional on NACPICA.
It is not great to have such conditionals, but it's better to have
#include "acpica.h"
#ifdef NACPICA > 0
than to have
#if defined(__i386__) || defined(__x86_64__) || defined(__arm__)
#include "acpica.h"
#endif
#ifdef NACPICA > 0
and we can still grep for NACPICA to find places that could be
factored better.
Except as a fast path in an RCU reader.
The array sizes appear to be reasonably small and not trivially
controlled by userland, from what I can tell, so if my impression is
accurate, it is reasonable to sleep for allocation here.
I'm not documenting this to encourage anyone to use it. I'm only
documenting this to remind myself what the semantics is, because it's
kind of confusing and not at all like mutex(9).
This reverts i915_active.c 1.11. ref->retire might free the object,
so touching it is not allowed -- that would use-after-free. Linux
uses the object only for its address with wake_up_var.
The reason I made this change was that I guessed i915_active_wait has
to wait until after ref->retire finishes -- after all, Linux seems to
defer the wakeup until then. However, even the Linux code doesn't
guarantee this, because i915_active_wait could be called _during_
ref->retire, and would witness ref->count == 0, and would not wait
until it has completed in that case. So maybe my guess was wrong,
and it is OK for i915_active_wait to return while ref->retire is
still in flight -- I don't see any logic that obviously requires it
to wait for ref->retire, in any case.
Or maybe something does rely on i915_active_wait to wait for
ref->retire to finish, in which case we need a different mechanism
for i915_active_release itself to wait until i915_active_retire has
woken up, without dereferencing ref since it might be dead after
ref->retire.
Just to make sure I didn't get the sense of the lookup reversed,
which is quite likely, because I've done it probably more than once
in this code before...
Not sure why this error branch is getting hit, but let's not make the
problem worse by choking on stack garbage.
Candidate fix for symptom of PR kern/56565, PR kern/56711.
Underlying problem -- that ttm_bo_mem_space fails with ENOMEM --
remains.
script -e -c /usr/bin/true
script -e -c /usr/bin/false
exit with the proper exit code.
2. handle system return value correctly (nabijaczleweli)
3. factor out the conversion of wait status -> shell return code.
- idt_vec_free/alloc are obviously supposed to synchronize with a
happens-before relation, so use release/acquire.
- There is no store-before-load ordering needed, so omit membar_sync.
It is the caller's responsibility to arrange that thmap_create, and,
if THMAP_SETROOT is set, thmap_root, happen before any use of the
thmap. No need for them to issue fences internally.
...or atomic_load_relaxed, when the config is locked. (Not necessary
to use atomic_* at all in NetBSD, but in C11 it will be cheaper to
say atomic_load_relaxed explicitly so an _Atomic-qualified object
doesn't cause the load to be surrounded by unnecessary membars.)
No need for store-before-load ordering here, so no need to
membar_sync.
andvar