Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
MIME-Version: 1.0
References: <07c32bf1-6c1a-49d9-b97d-f0ae4a2b42ab@p183> <CAHk-=whO1+-4ALjFWSE0kzytz1kEbWPvy3xWvcUP1dJ4t-QqkA@mail.gmail.com>
 <CACMJSetxQi+t3SBXu6OvBbmxV8AbX2CfdSA9JvF1chLJSU9Ppw@mail.gmail.com>
 <CAHk-=wgRHiV5VSxtfXA4S6aLUmcQYEuB67u3BJPJPtuESs1JyA@mail.gmail.com>
 <CACMJSevZQgik7S-62fz9H7+Mib+W0CgYMV4GyWjYV7N_E6iHVQ@mail.gmail.com>
 <CACMJSevrJ5KSPAZVheXkNaYj8KQFD8ck55kU_E4vEj4vzR8wnQ@mail.gmail.com>
 <CAHk-=wicfvWPuRVDG5R1mZSxD8Xg=-0nLOiHay2T_UJ0yDX42g@mail.gmail.com> <20230915210851.GA23174@noisy.programming.kicks-ass.net>
In-Reply-To: <20230915210851.GA23174@noisy.programming.kicks-ass.net>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 15 Sep 2023 14:22:02 -0700
Message-ID: <CAHk-=whvOGL3aNhtps0YksGtzvaob_bvZpbaTcVEqGwNMxB6xg@mail.gmail.com>
Subject: Re: Buggy __free(kfree) usage pattern already in tree
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
        Alexey Dobriyan <adobriyan@gmail.com>,
        linux-kernel@vger.kernel.org,
        Linus Walleij <linus.walleij@linaro.org>,
        akpm@linux-foundation.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 15 Sept 2023 at 14:08, Peter Zijlstra <peterz@infradead.org> wrote:
>
> So in the perf-event conversion patches I do have this:
>
>         struct task_struct *task __free(put_task) = NULL;
>
>         ...
>
>         if (pid != -1) {
>                 task = find_lively_task_by_vpid(pid);
>                 if (!task)
>                         return -ESRCH;
>         }
>
>         ...
>
> pattern. The having of task is fully optional in the code-flow.

Yeah, if you end up having conditional initialization, you can't have
the cleanup declaration in the same place, since it would be in an
inner scope and get free'd immediately.

Still, I think that's likely the exception rather than the rule.

Side note: I hope your code snippets are "something like this" rather
than the real deal.

Because code like this:

> 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);
>
>              struct rw_semaphore *exec_update_lock __free(up_read) = NULL;

is just garbage. That's not a "freeing" function. That should be "__cleanup()".

The last thing we want is misleading naming, making people think that
you are "freeing" a lock.

Naming is hard, let's not make it worse by making it actively misleading.

And honestly, I think the above is actually a *HORIBLE* argument for
doing that "initialize to NULL, change later". I think the above is
exactly the kind of code that we ABSOLUTELY DO NOT WANT.

You should aim for a nice

        struct rw_semaphore *struct rw_semaphore *exec_update_lock
            __cleanup(release_exec_update_lock) = get_exec_update_lock(task);

and simply have proper constructors and destructors. It's going to be
much cleaner.

You can literally do something like

    static inline void release_exec_update_lock(struct rw_semaphore *sem)
    { if (!IS_ERR_OR_NULL(sem)) up_read(sem); }

    static inline void get_exec_update_lock(struct task_struct *tsk)
    {
        if (!task)
                return NULL;
        if (down_read_interruptible(&task->signal->exec_update_lock))
                return ERR_PTR(-EINTR);
        retuin &task->signal->exec_update_lock;
    }

and the code will be *much* cleaner, wouldn't you say?

Please use proper constructors and destructors when you do these kinds
of automatic cleanup things. Don't write ad-hoc garbage.

You'll thank me a year from now when the code is actually legible.

                 Linus