[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACMJSevrJ5KSPAZVheXkNaYj8KQFD8ck55kU_E4vEj4vzR8wnQ@mail.gmail.com>
Date: Fri, 15 Sep 2023 22:03:51 +0200
From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>
Cc: 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 21:27, Bartosz Golaszewski
<bartosz.golaszewski@...aro.org> wrote:
>
[snip!]
>
> Understood. I'll go with a modified version of maybe-sane. I'll send a
> v2 tomorrow and make sure to Cc you.
>
[snip!]
One more question wrt the __free() coding style.
Is the following acceptable:
void foo(void)
{
char *s __free(kfree) = NULL;
do_stuff();
s = kmalloc(42, GFP_KERNEL);
}
Or does it always have to be:
void foo(void)
{
do_stuff();
char *s __free(kfree) = kmalloc(42, GFP_KERNEL);
}
?
I guess it would be useful to get these rules into
Documentation/process/coding-style.rst at some point as we also have
an ongoing discussion about whether scoped guards should always
require curly braces[1] even for single statements.
Bartosz
[1] https://lore.kernel.org/lkml/CAMuHMdVYDSPGP48OXxi-s4GFegfzUu900ASBnRmMo=18UzmCrQ@mail.gmail.com/
Powered by blists - more mailing lists