[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230915211815.GA34041@noisy.programming.kicks-ass.net>
Date: Fri, 15 Sep 2023 23:18:15 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
Alexey Dobriyan <adobriyan@...il.com>,
linux-kernel@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>,
akpm@...ux-foundation.org
Subject: Re: Buggy __free(kfree) usage pattern already in tree
On Fri, Sep 15, 2023 at 11:08:51PM +0200, Peter Zijlstra wrote:
> But a little later in that same function I then have:
>
> do {
> struct rw_semaphore *exec_update_lock __free(up_read) = NULL;
> if (task) {
> err = down_read_interruptible(&task->signal->exec_update_lock);
> if (err)
> return err;
>
> exec_update_lock = &task->signal->exec_update_lock;
>
> if (!perf_check_permissions(&attr, task))
> return -EACCESS;
> }
>
> ... stuff serialized against exec *if* this is a task event ...
>
> } while (0);
>
>
> And that might be a little harder to 'fix'.
Hmm, perhaps I can do a class for it and write the thing like:
do {
CLASS(cond_exec_update_lock, exec_lock_guard)(task); /* allow task == NULL */
if (task && !exec_lock_guard)
return -EINTR;
if (task && !perf_check_permissions(&attr, task))
return -EACCESS;
... the rest ...
} while (0);
that might be nicer..
Powered by blists - more mailing lists