On Wed, Jun 25, 2025 at 10:56:04AM +0200, Dmitry Vyukov wrote:
On Tue, 24 Jun 2025 at 22:04, Sasha Levin <sas...@kernel.org> wrote:
>9. I see that syscalls and ioctls say:
>KAPI_CONTEXT(KAPI_CTX_PROCESS | KAPI_CTX_SLEEPABLE)
>Can't we make this implicit? Are there any other options?
Maybe? I wasn't sure how we'd describe somthing like getpid() which
isn't supposed to sleep.
>Similarly an ioctl description says it releases a mutex (.released = true,),
>all ioctls/syscalls must release all acquired mutexes, no?
>Generally, the less verbose the descriptions are, the higher chances of their
survival.
>+Marco also works static compiler-enforced lock checking annotations,
>I wonder if they can be used to describe this in a more useful way.
I was thinking about stuff like futex or flock which can return with a
lock back to userspace.
I see, this makes sense. Then I would go with explicitly specifying
rare uncommon cases instead, and require 99% of common cases be the
default that does not require saying anything.
E.g. KAPI_CTX_NON_SLEEPABLE, .not_released = true.
KAPI_CTX_NON_SLEEPABLE looks useful, since it allows easy validation:
set current flag, and BUG on any attempt to sleep when the flag is set
(lockdep probably already has required pieces for this).
Yup, that makes sense. One of the reason I wrapped all the field
assignments with macros is that we can easily customize them based on
usage, so instead of:
#define KAPI_LOCK_ACQUIRED \
.acquired = true,
#define KAPI_LOCK_RELEASED \
.released = true,
We can add:
#define KAPI_LOCK_USED \
.acquired = true, \
.released = true,
--
Thanks,
Sasha
