* [dvyukov:dvyukov-rseq-pkey 3/3] kernel/rseq.c:406:2: error: use of undeclared identifier 'pkey_reg_t'
@ 2025-02-08 12:31 kernel test robot
0 siblings, 0 replies; only message in thread
From: kernel test robot @ 2025-02-08 12:31 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: llvm, oe-kbuild-all
tree: https://github.com/dvyukov/linux dvyukov-rseq-pkey
head: b991732d23294a961eed6a4a2758c16f0430de9c
commit: b991732d23294a961eed6a4a2758c16f0430de9c [3/3] rseq: Make rseq work with protection keys
config: s390-allnoconfig (https://download.01.org/0day-ci/archive/20250208/202502082027.9ojuhmXl-lkp@intel.com/config)
compiler: clang version 21.0.0git (https://github.com/llvm/llvm-project 6807164500e9920638e2ab0cdb4bf8321d24f8eb)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250208/202502082027.9ojuhmXl-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202502082027.9ojuhmXl-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/rseq.c:406:2: error: use of undeclared identifier 'pkey_reg_t'
406 | pkey_reg_t saved;
| ^
kernel/rseq.c:426:3: error: call to undeclared function 'write_pkey_reg'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
426 | write_pkey_reg(saved);
| ^
>> kernel/rseq.c:426:18: error: use of undeclared identifier 'saved'
426 | write_pkey_reg(saved);
| ^
kernel/rseq.c:455:3: error: use of undeclared identifier 'saved'
455 | saved = switch_to_permissive_pkey_reg();
| ^
kernel/rseq.c:455:11: error: call to undeclared function 'switch_to_permissive_pkey_reg'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
455 | saved = switch_to_permissive_pkey_reg();
| ^
kernel/rseq.c:458:18: error: use of undeclared identifier 'saved'
458 | write_pkey_reg(saved);
| ^
6 errors generated.
vim +/pkey_reg_t +406 kernel/rseq.c
390
391 /*
392 * This resume handler must always be executed between any of:
393 * - preemption,
394 * - signal delivery,
395 * and return to user-space.
396 *
397 * This is how we can ensure that the entire rseq critical section
398 * will issue the commit instruction only if executed atomically with
399 * respect to other threads scheduled on the same CPU, and with respect
400 * to signal handlers.
401 */
402 void __rseq_handle_notify_resume(struct ksignal *ksig, struct pt_regs *regs)
403 {
404 struct task_struct *t = current;
405 int ret, sig;
> 406 pkey_reg_t saved;
407 bool switched_pkey_reg = false;
408
409 if (unlikely(t->flags & PF_EXITING))
410 return;
411
412 retry:
413 /*
414 * regs is NULL if and only if the caller is in a syscall path. Skip
415 * fixup and leave rseq_cs as is so that rseq_sycall() will detect and
416 * kill a misbehaving userspace on debug kernels.
417 */
418 if (regs) {
419 ret = rseq_ip_fixup(regs);
420 if (unlikely(ret < 0))
421 goto error;
422 }
423 if (unlikely(rseq_update_cpu_node_id(t)))
424 goto error;
425 if (switched_pkey_reg)
> 426 write_pkey_reg(saved);
427 return;
428
429 error:
430 /*
431 * If the application registers rseq, and ever switches to another
432 * pkey protection (such that the rseq becomes inaccessible), then
433 * any context switch will cause failure here attemping to read/write
434 * struct rseq and/or rseq_cs. Since context switches are
435 * asynchronous and are outside of the application control
436 * (not part of the restricted code scope), we temporarily switch
437 * to premissive pkey register to read/write rseq/rseq_cs,
438 * similarly to signal delivery.
439 *
440 * We don't bother to check if the failure really happened due to
441 * pkeys or not, since it does not matter (performance-wise and
442 * otherwise).
443 *
444 * If the restricted code installs rseq_cs in inaccessible to it
445 * due to pkeys page, we still let this function read the rseq_cs.
446 * It's unclear what benefits the resticted code gets by doing this
447 * (it probably already hijacked control flow at this point), and
448 * presumably any sane sandbox should prohibit restricted code
449 * from accessing struct rseq, and this is still better than
450 * terminating the app unconditionally (it always has a choice
451 * of not using rseq and pkeys together).
452 */
453 if (!switched_pkey_reg) {
454 switched_pkey_reg = true;
455 saved = switch_to_permissive_pkey_reg();
456 goto retry;
457 } else {
458 write_pkey_reg(saved);
459 }
460 sig = ksig ? ksig->sig : 0;
461 force_sigsegv(sig);
462 }
463
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2025-02-08 12:31 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-08 12:31 [dvyukov:dvyukov-rseq-pkey 3/3] kernel/rseq.c:406:2: error: use of undeclared identifier 'pkey_reg_t' kernel test robot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox