[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230315002608.sulru3taycwrmvki@treble>
Date: Tue, 14 Mar 2023 17:26:08 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Petr Mladek <pmladek@...e.com>
Cc: live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
Seth Forshee <sforshee@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Song Liu <song@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Joe Lawrence <joe.lawrence@...hat.com>,
Miroslav Benes <mbenes@...e.cz>,
Jiri Kosina <jikos@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Rik van Riel <riel@...riel.com>
Subject: Re: [PATCH 0.5/3] livepatch: Convert stack entries array to percpu
On Tue, Mar 14, 2023 at 11:50:21AM +0100, Petr Mladek wrote:
> > static int klp_check_stack(struct task_struct *task, const char **oldname)
> > {
> > - static unsigned long entries[MAX_STACK_ENTRIES];
> > + unsigned long *entries = this_cpu_ptr(klp_stack_entries);
> > struct klp_object *obj;
> > struct klp_func *func;
> > int ret, nr_entries;
> >
> > - ret = stack_trace_save_tsk_reliable(task, entries, ARRAY_SIZE(entries));
> > + /* Protect 'klp_stack_entries' */
> > + lockdep_assert_preemption_disabled();
>
> I think about adding:
>
> /*
> * Stay on the safe side even when cond_resched() is called from
> * an IRQ context by mistake.
> */
> if (!in_task())
> return -EINVAL;
>
> Or is this prevented another way, please?
An IRQ handler trying to schedule would be a pretty major bug, no?
I think there are already several different checks for that. For
example, the __might_resched() call in cond_resched().
--
Josh
Powered by blists - more mailing lists