[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACMJSetxQi+t3SBXu6OvBbmxV8AbX2CfdSA9JvF1chLJSU9Ppw@mail.gmail.com>
Date: Fri, 15 Sep 2023 19:22:42 +0200
From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Alexey Dobriyan <adobriyan@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
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 19:04, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Fri, 15 Sept 2023 at 02:56, Alexey Dobriyan <adobriyan@...il.com> wrote:
> >
> > __free() got some usage and some of the usage is buggy:
>
> Yeah, that's sad.
>
> I think the '__free(kfree)' thing should *only* be used in the form
>
> struct obj *p __free(kfree) = kmalloc(...);
>
> which is what our docs mention. Anything else is simply buggy.
>
> But how do we *notice* this?
>
> I do want to stress how I was unhappy about this conversion to begin with
>
> https://lore.kernel.org/lkml/CAHk-=wigZt6kVkY0HU1j_LJ5H1KzwPiYnwwk6CbqXqT=sGenjg@mail.gmail.com/
>
> but I reacted to the wrong issue.
>
> This stuff needs to be done *way* more carefully.
>
> Linus
This is why I started with a *testing* driver. It's got "simulator" in
the name for a reason. It doesn't deal with real HW and is mostly run
in VMs anyway. Few people even build it at all so it makes for good
testing grounds for experimental features.
IMO this feature has much more potential at fixing existing memory
leaks than introducing new ones. I agree, I should have been more
careful, but I wouldn't exaggerate the issue. It's a bug, I sent a
fix, it'll be fine in a few days. I hope it won't be seen as an
argument against __free(). It just needs some time to mature.
Bartosz
Powered by blists - more mailing lists