[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e778cb1.22654.180decbcb8e.Coremail.duoming@zju.edu.cn>
Date: Fri, 20 May 2022 08:08:59 +0800 (GMT+08:00)
From: duoming@....edu.cn
To: "Jeff Johnson" <quic_jjohnson@...cinc.com>
Cc: "Kalle Valo" <kvalo@...nel.org>, linux-kernel@...r.kernel.org,
amitkarwar@...il.com, ganapathi017@...il.com,
sharvari.harisangam@....com, huxinming820@...il.com,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, linux-wireless@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH net v2] net: wireless: marvell: mwifiex: fix sleep in
atomic context bugs
Hello,
On Thu, 19 May 2022 08:48:44 -0700 Jeff Johnson wrote:
> >>> There are sleep in atomic context bugs when uploading device dump
> >>> data on usb interface. The root cause is that the operations that
> >>> may sleep are called in fw_dump_timer_fn which is a timer handler.
> >>> The call tree shows the execution paths that could lead to bugs:
> >>>
> >>> (Interrupt context)
> >>> fw_dump_timer_fn
> >>> mwifiex_upload_device_dump
> >>> dev_coredumpv(..., GFP_KERNEL)
>
> just looking at this description, why isn't the simple fix just to
> change this call to use GFP_ATOMIC?
Because change the parameter of dev_coredumpv() to GFP_ATOMIC could only solve
partial problem. The following GFP_KERNEL parameters are in /lib/kobject.c
which is not influenced by dev_coredumpv().
kobject_set_name_vargs
kvasprintf_const(GFP_KERNEL, ...); //may sleep
kstrdup(s, GFP_KERNEL); //may sleep
Best regards,
Duoming Zhou
Powered by blists - more mailing lists