Let's suppose damon_start() and damon_call() are executed in parallel for the same DAMON context. Then, damon_call() could show ctx->damon_calls_obsolte set while ctx->kdamond is unset. If damon_start() sets ctx->kdamond before damon_call() starts the cancelling, damon_call() can indefinitely hang. No DAMON API caller does such parallel execution of damon_start() and damon_call(), so the issue doesn't exist. But who knows what will happen in future. Add a clarification comment for caution. Signed-off-by: SJ Park --- mm/damon/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/damon/core.c b/mm/damon/core.c index dd27068cb83e3..080355b1f2d9f 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2251,6 +2251,9 @@ int damon_kdamond_pid(struct damon_ctx *ctx) * * When this function is failed, the @ctx is guaranteed to be stopped. * + * This function should not be called in parallel to damon_start() for the + * @ctx. In the case, this function could indefinitely hang. + * * Return: 0 on success, negative error code otherwise. */ int damon_call(struct damon_ctx *ctx, struct damon_call_control *control) -- 2.47.3