Messages in this thread | | | Date | Fri, 15 Sep 2023 23:32:31 +0200 | From | Peter Zijlstra <> | Subject | Re: Buggy __free(kfree) usage pattern already in tree |
| |
On Fri, Sep 15, 2023 at 02:22:02PM -0700, Linus Torvalds wrote:
> Naming is hard, let's not make it worse by making it actively misleading.
I actually did use the DEFINE_FREE() helper, will go fix. Because yes, free is not the right word in this case.
> 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);
Ah, that might be nicer still than the class thing I proposed in a follow up email.
It also got me thinking about named_guard() for the myriad of conditional locks we have.
named_guard(try_mutex, foo_guard)(&foo->lock); if (foo_guard) { // we got the lock, do our thing }
or
named_guard(interruptible_mutex, foo_guard)(&foo->lock); if (!foo_guard) return -EINTR;
Are these sane patterns?
| |