[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZCfO90WwyS6JwaHi@kroah.com>
Date: Sat, 1 Apr 2023 08:28:07 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Mirsad Goran Todorovac <mirsad.todorovac@....unizg.hr>
Cc: LKML <linux-kernel@...r.kernel.org>,
Thorsten Leemhuis <regressions@...mhuis.info>,
Maxim Levitsky <maximlevitsky@...il.com>,
Alex Dubov <oakad@...oo.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Jens Axboe <axboe@...nel.dk>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Hannes Reinecke <hare@...e.de>,
Jiasheng Jiang <jiasheng@...as.ac.cn>,
ye xingchen <ye.xingchen@....com.cn>, linux-mmc@...r.kernel.org
Subject: Re: BUG FIX: [PATCH RFC v3] memstick_check() memleak in kernel
6.1.0+ introduced pre 4.17
On Sat, Apr 01, 2023 at 08:23:26AM +0200, Mirsad Goran Todorovac wrote:
> > This patch is implying that anyone who calls "dev_set_name()" also has
> > to do this hack, which shouldn't be the case at all.
> >
> > thanks,
> >
> > greg k-h
>
> This is my best guess. Unless there is dev_free_name() or kobject_free_name(), I don't
> see a more sensible way to patch this up.
In sleeping on this, I think this has to move to the driver core. I
don't understand why we haven't seen this before, except maybe no one
has really noticed before (i.e. we haven't had good leak detection tools
that run with removable devices?)
Anyway, let me see if I can come up with something this weekend, give me
a chance...
thanks,
greg k-h
Powered by blists - more mailing lists