On Tue, Apr 30, 2019 at 11:10:48AM +0200, Petr Mladek wrote:
> WARN_ON_ONCE() could not be called safely under rq lock because
> of console deadlock issues. Fortunately, there is another check
> for the reliable stacktrace support in klp_enable_patch().
> 
> Signed-off-by: Petr Mladek <[email protected]>
> ---
>  kernel/livepatch/transition.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
> index 9c89ae8b337a..8e0274075e75 100644
> --- a/kernel/livepatch/transition.c
> +++ b/kernel/livepatch/transition.c
> @@ -263,8 +263,15 @@ static int klp_check_stack(struct task_struct *task, 
> char *err_buf)
>       trace.nr_entries = 0;
>       trace.max_entries = MAX_STACK_ENTRIES;
>       trace.entries = entries;
> +
>       ret = save_stack_trace_tsk_reliable(task, &trace);
> -     WARN_ON_ONCE(ret == -ENOSYS);
> +     /*
> +      * pr_warn() under task rq lock might cause a deadlock.
> +      * Fortunately, missing reliable stacktrace support has
> +      * already been handled when the livepatch was enabled.
> +      */
> +     if (ret == -ENOSYS)
> +             return ret;

I find the comment to be a bit wordy and confusing (and vague).

Also this check is effectively the same as the klp_have_reliable_stack()
check which is done in kernel/livepatch/core.c.  So I think it would be
clearer and more consistent if the same check is done here:

        if (!klp_have_reliable_stack())
                return -ENOSYS;

        ret = save_stack_trace_tsk_reliable(task, &trace);

        [ no need to check ret for ENOSYS here ]

Then, IMO, no comment is needed.

-- 
Josh

Reply via email to