[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yv5TefZcrUPY1Qjc@kroah.com>
Date: Thu, 18 Aug 2022 16:58:01 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: duoming@....edu.cn
Cc: linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
briannorris@...omium.org, amitkarwar@...il.com,
ganapathi017@...il.com, sharvari.harisangam@....com,
huxinming820@...il.com, kvalo@...nel.org, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, johannes@...solutions.net,
rafael@...nel.org
Subject: Re: [PATCH v7 1/2] devcoredump: remove the useless gfp_t parameter
in dev_coredumpv and dev_coredumpm
On Wed, Aug 17, 2022 at 10:05:37PM +0800, duoming@....edu.cn wrote:
> Hello,
>
> On Wed, 17 Aug 2022 14:43:29 +0200 Greg KH wrote:
>
> > On Wed, Aug 17, 2022 at 08:39:12PM +0800, Duoming Zhou wrote:
> > > The dev_coredumpv() and dev_coredumpm() could not be used in atomic
> > > context, because they call kvasprintf_const() and kstrdup() with
> > > GFP_KERNEL parameter. The process is shown below:
> > >
> > > dev_coredumpv(.., gfp_t gfp)
> > > dev_coredumpm(.., gfp_t gfp)
> > > dev_set_name
> > > kobject_set_name_vargs
> > > kvasprintf_const(GFP_KERNEL, ...); //may sleep
> > > kstrdup(s, GFP_KERNEL); //may sleep
> > >
> > > This patch removes gfp_t parameter of dev_coredumpv() and dev_coredumpm()
> > > and changes the gfp_t parameter of kzalloc() in dev_coredumpm() to
> > > GFP_KERNEL in order to show they could not be used in atomic context.
> > >
> > > Fixes: 833c95456a70 ("device coredump: add new device coredump class")
> > > Reviewed-by: Brian Norris <briannorris@...omium.org>
> > > Reviewed-by: Johannes Berg <johannes@...solutions.net>
> > > Signed-off-by: Duoming Zhou <duoming@....edu.cn>
> > > ---
> > > Changes in v7:
> > > - Remove gfp_t flag in amdgpu device.
> >
> > Again, this creates a "flag day" where we have to be sure we hit all
> > users of this api at the exact same time. This will prevent any new
> > driver that comes into a maintainer tree during the next 3 months from
> > ever being able to use this api without cauing build breakages in the
> > linux-next tree.
> >
> > Please evolve this api to work properly for everyone at the same time,
> > like was previously asked for so that we can take this change. It will
> > take 2 releases, but that's fine.
>
> Thank you for your reply, I will evolve this api to work properly for everyone.
> If there are not any new drivers that use this api during the next 3 months,
> I will send this patch again. Otherwise, I will wait until there are not new
> users anymore.
No, that is not necessary. Do the work now so that there is no flag day
and you don't have to worry about new users, it will all "just work".
thanks,
greg k-h
Powered by blists - more mailing lists