All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Duoming Zhou <duoming@zju.edu.cn>
Cc: linux-wireless@vger.kernel.org, amitkarwar@gmail.com,
	ganapathi017@gmail.com, sharvari.harisangam@nxp.com,
	huxinming820@gmail.com, kvalo@kernel.org, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org, rafael@kernel.org
Subject: Re: [PATCH v3] mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv
Date: Mon, 23 May 2022 09:20:28 -0500	[thread overview]
Message-ID: <87o7zoxrdf.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20220523052810.24767-1-duoming@zju.edu.cn> (Duoming Zhou's message of "Mon, 23 May 2022 13:28:10 +0800")

Duoming Zhou <duoming@zju.edu.cn> writes:

> There are sleep in atomic context bugs when uploading device dump
> data in mwifiex. The root cause is that dev_coredumpv could not
> be used in atomic contexts, because it calls dev_set_name which
> include operations that may sleep. The call tree shows execution
> paths that could lead to bugs:
>
>    (Interrupt context)
> fw_dump_timer_fn
>   mwifiex_upload_device_dump
>     dev_coredumpv(..., GFP_KERNEL)
>       dev_coredumpm()
>         kzalloc(sizeof(*devcd), gfp); //may sleep
>         dev_set_name
>           kobject_set_name_vargs
>             kvasprintf_const(GFP_KERNEL, ...); //may sleep
>             kstrdup(s, GFP_KERNEL); //may sleep
>
> In order to let dev_coredumpv support atomic contexts, this patch
> changes the gfp_t parameter of kvasprintf_const and kstrdup in
> kobject_set_name_vargs from GFP_KERNEL to GFP_ATOMIC. What's more,
> In order to mitigate bug, this patch changes the gfp_t parameter
> of dev_coredumpv from GFP_KERNEL to GFP_ATOMIC.

vmalloc in atomic context?

Not only does dev_coredumpm set a device name dev_coredumpm creates an
entire device to hold the device dump.

My sense is that either dev_coredumpm needs to be rebuilt on a
completely different principle that does not need a device to hold the
coredump (so that it can be called from interrupt context) or that
dev_coredumpm should never be called in an context that can not sleep.


Looking at fw_dump_timer_fn the only purpose of the timer is to trigger
a device dump after a certain amount of time.  So I suspect all that is
needed to fix this issue is to change the type of devdump_timer to
struct delayed_work and use scheduled_delayed_work instead of mod_timer.


Eric

p.s.  I looked at this because there was coredump in the infrastructure
name, and I do some of the work to keep coredumps working.  Device dump
seems like a much better term, and I wished the designer of the api had
used that instead.




  parent reply	other threads:[~2022-05-23 14:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23  5:28 [PATCH v3] mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv Duoming Zhou
2022-05-23  6:31 ` Greg KH
     [not found]   ` <41a266af.2abb6.180efa8594d.Coremail.duoming@zju.edu.cn>
2022-05-23 11:31     ` Kalle Valo
2022-05-23 13:41       ` Greg KH
2022-05-23 16:27         ` Kalle Valo
2022-05-23 13:43       ` Johannes Berg
2022-05-23 14:20 ` Eric W. Biederman [this message]
2022-05-23 15:58   ` duoming
2022-05-23 16:31     ` Kalle Valo
2022-05-24  2:08       ` duoming
2022-05-23 19:42     ` Brian Norris
2022-05-24  1:54       ` duoming
2022-05-23 17:55 ` Brian Norris
  -- strict thread matches above, loose matches on Subject: below --
2022-05-23  8:03 duoming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7zoxrdf.fsf@email.froward.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=amitkarwar@gmail.com \
    --cc=davem@davemloft.net \
    --cc=duoming@zju.edu.cn \
    --cc=edumazet@google.com \
    --cc=ganapathi017@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=huxinming820@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rafael@kernel.org \
    --cc=sharvari.harisangam@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.