Use mutex here instead of pserialize because using mutex is simpler than
using psz+ref, which is another solution, and key_checkspidup isn't called in
any performance-sensitive paths.
- Use a reference count on the nouveau_fence_chan object.
- Acquire it with kpreemption disabled.
- Use xcall to wait for kpreempt-disabled sections to complete.
PR kern/53441
XXX pullup-7
XXX pullup-8
we had incorrect usage of setstackmark()/popstackmark()
There was an ancient idiom (imported from CSRG in 1993) where code
can do:
setstackmark(&smark); loop until whatever condition {
/* do lots of code */ popstackmark(&smark);
} popstackmark(&smark);
The 1st (inner) popstackmark() resets the stack, conserving memory,
The 2nd one is needed just in case the "whatever condition" was never
true, and the first one was never executed.
This is (was) safe as all popstackmark() did was reset the stack.
That could be done over and over again with no harm.
That is, until 2000 when a fix from FreeBSD for another problem was
imported. That connected all the stack marks as a list (so they can be
located). That caused the problem, as the idiom was not changed, now
there is this list of marks, and popstackmark() was removing an entry.
It rarely (never?) caused any problems as the idiom was rarely used
(the shell used to do loops like above, mostly, without the inner
popstackmark()). Further, the stack mark list is only ever used when
a memory block is realloc'd.
That is, until last weekend - with the recent set of changes.
Part of that copied code from FreeBSD introduced the idiom above
into more functions - functions used much more, and with a greater
possibility of stack marks being set on blocks that are realloc'd
and so cause the problem. In the FreeBSD code, they changed the idiom,
and always do a setstackmark() immediately after the inner popstackmark().
But not for reasons related to a list of stack marks, as in the
intervening period, FreeBSD deleted that, but for another reason.
We do not have their issue, and I did not believe that their
updated idiom was needed (I did some analysis of exactly this issue -
just missed the important part!), and just continued using the old one.
Hence Patrick's core dump....
The solution used here is to split popstackmark() into 2 halves,
popstackmark() continues to do what it has (recently) done,
but is now implemented as a call of (a new func) rststackmark()
which does all the original work of popstackmark - but not removing
the entry from the stack mark list (which remains in popstackmark()).
Then in the idiom above, the inner popstackmark() turns into a call of
rststackmark() so the stack is reset, but the stack mark list is
unchanged. Tail recursion elimination makes this essentially free.
access. Example of output:
kASan: Unauthorized Access In 0xffffffff80e6219c: Addr 0xffffbb007a39fd03 [1 byte, read]
#0 0xffffffff80e6219c in ras_purgeall <netbsd>
#1 0xffffffff80e62330 in sys_rasctl <netbsd>
#2 0xffffffff80265008 in syscall <netbsd>
(I manually added a one-byte stack read overflow in rasctl to demonstrate.)
Softints are the only place where we "discard" a part of the stack: we may
have left the thread without allowing the asan instrumentation to clear
the poison, and in this case, we can get false positives when we hit a
poisoned area of the stack while executing another handler within the same
softint thread.
(I was actually getting a rare false positive in ip6intr.)
When these devices or hdmi are enabled, firmware turns off GPU functionality of
VideoCore, expecting OS drivers handle it appropriately:
https://github.com/raspberrypi/firmware/issues/763
This breaks userland applications using /dev/vchiq, such as omxplayer.
XXX We need enable them back when we import vc4 drm driver.
Fix PR port-evbarm/52984 and
PR port-arm/53042.
OK jmcneill, skrll
__nothing until maxv sorts out the type issues - kern_malloc()
(for historical reasons) takes an unsigned long parameter, not a
size_t - on 64 bit arch's this makes no difference (size_t is unsigned
long) but that's not true on 32 bit archs (or not all of them anyway).
This should unbreak the i386 build (others?) - hopefully without
damaging anything too badly. Note the type issues need fixing,
just making this change permanent is not the solution.
illegal memory accesses occuring there.
The compiler inlines a piece of code in each function that adds redzones
around the local variables and poisons them. The illegal accesses are then
detected using the usual kASan machinery.
The stack size is doubled, from 4 pages to 8 pages.
Several boot functions are marked with the __noasan flag, to prevent the
compiler from adding redzones in them (because we haven't yet initialized
kASan). The kasan_early_init function is called early at boot time to
quickly create the shadow for the current stack; after this is done, we
don't need __noasan anymore in the boot path.
We pass -fasan-shadow-offset=0xDFFF900000000000, because the compiler
wants to do
shad = shadow-offset + (addr >> 3)
and we do, in kasan_addr_to_shad
shad = KASAN_SHADOW_START + ((addr - CANONICAL_BASE) >> 3)
hence
shad = KASAN_SHADOW_START + (addr >> 3) - (CANONICAL_BASE >> 3)
= [KASAN_SHADOW_START - (CANONICAL_BASE >> 3)] + (addr >> 3)
implies
shadow-offset = KASAN_SHADOW_START - (CANONICAL_BASE >> 3)
= 0xFFFF800000000000 - (0xFFFF800000000000 >> 3)
= 0xDFFF900000000000
In UVM, we add a kasan_free (that is not preceded by a kasan_alloc). We
don't add poisoned redzones ourselves, but all the functions we execute
do, so we need to manually clear the poison before freeing the stack.
With the help of Kamil for the makefile stuff.
- Remove unused *_NAMES macros for sysctl.
- Remove unused *_MAXID for sysctls.
- Move CTL_MACHDEP sysctl definitions for m68k into m68k/include/cpu.h and
use them on all m68k machines.
shuffle code in xbd_handler() response loop so that req_bp is never
touched for non I/O responses; unknown commands are now just skipped, also
without touching neither xbdreq, nor req_bp
add some KASSERTS() for xbdreq->req_nr_segments and xbdreq->req_bp,
and reset req_bp after it's processed to ensure the buf can never
be processed twice
intended to simplify debugging in cases like PR port-xen/53506
EINVAL straight away
the condition doesn't seem to be actually hit for normal boots and
tools like fsck, which is good thing since it allocated memory
separately for each such I/O
interrupt handling in xbd_handler() - need to protect it with splbio()
fixes PR port-xen/53506 by Emmanuel Dreyfus, and likely also port-xen/53074
by Brad Spencer
and that any data supposedly copied out is valid before use.
prompted by maxv@, I have checked every usage of m_copydata() and made
the following corrections
hci_event.c:
hci_event_command_compl()
check that the packet does contain enough data for there to
be a status code before noting possible failures.
hci_event_num_compl_pkts()
check that the packet does contain data to cover the
stated number of handle/num pairs
l2cap_signal.c:
l2cap_recv_signal()
just ignore packets with not enough data rather than
trying to reject them (may not have cmd.ident)
l2cap_recv_command_rej()
check we have a valid reason and/or data before use
