@@ -331,7 +331,7 @@ Several macros exist to validate arguments:
331
331
API structure.
332
332
333
333
If any check fails, the macros will return a nonzero value. The macro
334
- :c:macro: `Z_OOPS () ` can be used to induce a kernel oops which will kill the
334
+ :c:macro: `K_OOPS () ` can be used to induce a kernel oops which will kill the
335
335
calling thread. This is done instead of returning some error condition to
336
336
keep the APIs the same when calling from supervisor mode.
337
337
@@ -357,7 +357,7 @@ For example:
357
357
358
358
static int z_vrfy_k_sem_take(struct k_sem *sem, int32_t timeout)
359
359
{
360
- Z_OOPS (K_SYSCALL_OBJ(sem, K_OBJ_SEM));
360
+ K_OOPS (K_SYSCALL_OBJ(sem, K_OBJ_SEM));
361
361
return z_impl_k_sem_take(sem, timeout);
362
362
}
363
363
#include <syscalls/k_sem_take_mrsh.c>
@@ -397,7 +397,7 @@ for some integral value:
397
397
int ret;
398
398
399
399
ret = z_impl_some_syscall(&local_out_param);
400
- Z_OOPS (k_usermode_to_copy(out_param, &local_out_param, sizeof(*out_param)));
400
+ K_OOPS (k_usermode_to_copy(out_param, &local_out_param, sizeof(*out_param)));
401
401
return ret;
402
402
}
403
403
@@ -411,7 +411,7 @@ It might be tempting to do something more concise:
411
411
412
412
int z_vrfy_some_syscall(int *out_param)
413
413
{
414
- Z_OOPS (K_SYSCALL_MEMORY_WRITE(out_param, sizeof(*out_param)));
414
+ K_OOPS (K_SYSCALL_MEMORY_WRITE(out_param, sizeof(*out_param)));
415
415
return z_impl_some_syscall(out_param);
416
416
}
417
417
@@ -433,9 +433,9 @@ bytes processed. This too should use a stack copy:
433
433
size_t size;
434
434
int ret;
435
435
436
- Z_OOPS (k_usermode_from_copy(&size, size_ptr, sizeof(size));
436
+ K_OOPS (k_usermode_from_copy(&size, size_ptr, sizeof(size));
437
437
ret = z_impl_in_out_syscall(&size);
438
- Z_OOPS (k_usermode_to_copy(size_ptr, &size, sizeof(size)));
438
+ K_OOPS (k_usermode_to_copy(size_ptr, &size, sizeof(size)));
439
439
return ret;
440
440
}
441
441
@@ -461,11 +461,11 @@ be copied. Typically this is done by allocating copies on the stack:
461
461
struct bar bar_right_copy;
462
462
struct bar bar_left_copy;
463
463
464
- Z_OOPS (k_usermode_from_copy(&foo_copy, foo, sizeof(*foo)));
465
- Z_OOPS (k_usermode_from_copy(&bar_right_copy, foo_copy.bar_right,
464
+ K_OOPS (k_usermode_from_copy(&foo_copy, foo, sizeof(*foo)));
465
+ K_OOPS (k_usermode_from_copy(&bar_right_copy, foo_copy.bar_right,
466
466
sizeof(struct bar)));
467
467
foo_copy.bar_right = &bar_right_copy;
468
- Z_OOPS (k_usermode_from_copy(&bar_left_copy, foo_copy.bar_left,
468
+ K_OOPS (k_usermode_from_copy(&bar_left_copy, foo_copy.bar_left,
469
469
sizeof(struct bar)));
470
470
foo_copy.bar_left = &bar_left_copy;
471
471
@@ -478,7 +478,7 @@ memory from the caller's resource pool via :c:func:`z_thread_malloc()`. This
478
478
should always be considered last resort. Functional safety programming
479
479
guidelines heavily discourage usage of heap and the fact that a resource pool is
480
480
used must be clearly documented. Any issues with allocation must be
481
- reported, to a caller, with returning the ``-ENOMEM `` . The ``Z_OOPS () ``
481
+ reported, to a caller, with returning the ``-ENOMEM `` . The ``K_OOPS () ``
482
482
should never be used to verify if resource allocation has been successful.
483
483
484
484
.. code-block :: c
@@ -500,7 +500,7 @@ should never be used to verify if resource allocation has been successful.
500
500
size_t bar_list_bytes;
501
501
502
502
/* Safely copy foo into foo_copy */
503
- Z_OOPS (k_usermode_from_copy(&foo_copy, foo, sizeof(*foo)));
503
+ K_OOPS (k_usermode_from_copy(&foo_copy, foo, sizeof(*foo)));
504
504
505
505
/* Bounds check the count member, in the copy we made */
506
506
if (foo_copy.count > 32) {
@@ -514,7 +514,7 @@ should never be used to verify if resource allocation has been successful.
514
514
if (bar_list_copy == NULL) {
515
515
return -ENOMEM;
516
516
}
517
- Z_OOPS (k_usermode_from_copy(bar_list_copy, foo_copy.bar_list,
517
+ K_OOPS (k_usermode_from_copy(bar_list_copy, foo_copy.bar_list,
518
518
bar_list_bytes));
519
519
foo_copy.bar_list = bar_list_copy;
520
520
@@ -549,7 +549,7 @@ The following constraints need to be met:
549
549
550
550
int z_vrfy_get_data_from_kernel(void *buf, size_t size)
551
551
{
552
- Z_OOPS (K_SYSCALL_MEMORY_WRITE(buf, size));
552
+ K_OOPS (K_SYSCALL_MEMORY_WRITE(buf, size));
553
553
return z_impl_get_data_from_kernel(buf, size);
554
554
}
555
555
@@ -558,16 +558,16 @@ Verification Return Value Policies
558
558
559
559
When verifying system calls, it's important to note which kinds of verification
560
560
failures should propagate a return value to the caller, and which should
561
- simply invoke :c:macro: `Z_OOPS () ` which kills the calling thread. The current
561
+ simply invoke :c:macro: `K_OOPS () ` which kills the calling thread. The current
562
562
conventions are as follows:
563
563
564
564
#. For system calls that are defined but not compiled, invocations of these
565
565
missing system calls are routed to :c:func: `handler_no_syscall() ` which
566
- invokes :c:macro: `Z_OOPS () `.
566
+ invokes :c:macro: `K_OOPS () `.
567
567
568
568
#. Any invalid access to memory found by the set of ``K_SYSCALL_MEMORY `` APIs,
569
569
:c:func: `k_usermode_from_copy() `, :c:func: `k_usermode_to_copy() `
570
- should trigger a :c:macro: `Z_OOPS `. This happens when the caller doesn't have
570
+ should trigger a :c:macro: `K_OOPS `. This happens when the caller doesn't have
571
571
appropriate permissions on the memory buffer or some size calculation
572
572
overflowed.
573
573
@@ -576,7 +576,7 @@ conventions are as follows:
576
576
manually using :c:func: `k_object_validate() `. These can fail for a variety
577
577
of reasons: missing driver API, bad kernel object pointer, wrong kernel
578
578
object type, or improper initialization state. These issues should always
579
- invoke :c:macro: `Z_OOPS () `.
579
+ invoke :c:macro: `K_OOPS () `.
580
580
581
581
#. Any error resulting from a failed memory heap allocation, often from
582
582
invoking :c:func: `z_thread_malloc() `, should propagate ``-ENOMEM `` to the
@@ -594,7 +594,7 @@ conventions are as follows:
594
594
be registered from user mode. APIs which simply install callbacks shall not
595
595
be exposed as system calls. Some driver subsystem APIs may take optional
596
596
function callback pointers. User mode verification functions for these APIs
597
- must enforce that these are NULL and should invoke :c:macro: `Z_OOPS () ` if
597
+ must enforce that these are NULL and should invoke :c:macro: `K_OOPS () ` if
598
598
not.
599
599
600
600
#. Some parameter checks are enforced only from user mode. These should be
@@ -608,14 +608,14 @@ There are some known exceptions to these policies currently in Zephyr:
608
608
initialization bit pulls double-duty to indicate whether a thread is
609
609
running, cleared upon exit. See #23030.
610
610
611
- * :c:func: `k_thread_create() ` invokes :c:macro: `Z_OOPS () ` for parameter
611
+ * :c:func: `k_thread_create() ` invokes :c:macro: `K_OOPS () ` for parameter
612
612
checks, due to a great deal of existing code ignoring the return value.
613
613
This will also be addressed by #23030.
614
614
615
- * :c:func: `k_thread_abort() ` invokes :c:macro: `Z_OOPS () ` if an essential
615
+ * :c:func: `k_thread_abort() ` invokes :c:macro: `K_OOPS () ` if an essential
616
616
thread is aborted, as the function has no return value.
617
617
618
- * Various system calls related to logging invoke :c:macro: `Z_OOPS () `
618
+ * Various system calls related to logging invoke :c:macro: `K_OOPS () `
619
619
when bad parameters are passed in as they do not propagate errors.
620
620
621
621
Configuration Options
@@ -635,7 +635,7 @@ Helper macros for creating system call verification functions are provided in
635
635
* :c:macro: `K_SYSCALL_OBJ() `
636
636
* :c:macro: `K_SYSCALL_OBJ_INIT() `
637
637
* :c:macro: `K_SYSCALL_OBJ_NEVER_INIT() `
638
- * :c:macro: `Z_OOPS () `
638
+ * :c:macro: `K_OOPS () `
639
639
* :c:macro: `K_SYSCALL_MEMORY_READ() `
640
640
* :c:macro: `K_SYSCALL_MEMORY_WRITE() `
641
641
* :c:macro: `K_SYSCALL_MEMORY_ARRAY_READ() `
0 commit comments