linux-kernel - Re: Buggy __free(kfree) usage pattern already in tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 15 Sep 2023 13:40:25 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Cc:     Peter Zijlstra <peterz@...radead.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, 15 Sept 2023 at 13:04, Bartosz Golaszewski
<bartosz.golaszewski@...aro.org> wrote:
>
> One more question wrt the __free() coding style.

I don't think we really have much of a coding style yet.

We currently literally have _one_ use of that __free() thing, and it
was problematic.

Which is why I'd like to start off fairly strict, but I'm not sure we
should make it a "coding style" yet.

IOW, my current thinking is "let's always have the constructor and
destructor together", and see how it ends up going.

Not because I think it's necessarily any kind of final rule, but
because I think our whole cleanup thing is new enough that I think
we're better off being a bit inflexible, and having a syntax where a
simple "grep" ends up showing pretty much exactly what is going on wrt
the pairing.

                  Linus