Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Debug Message show fps allways 0 in fbtft_update_display #328

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Debug Message show fps allways 0 in fbtft_update_display #328

wants to merge 1 commit into from

Conversation

gdampf
Copy link

@gdampf gdampf commented Sep 27, 2016

Switching on Debug=32 (DEBUG_TIME_EACH_UPDATE) shows allways 0 FPS. Compared to earlier Version shows, that the if statement in 394 has been negated and the assigment in 397 (par->update_time = ts_start;) has to be moved (now 408) after the usage in 398 (now 397). Now the value of fps is correctly calculated.

@gdampf
Debug Message show fps allways 0 in fbtft_update_display
0f93ce6 
Switching on Debug=32 (DEBUG_TIME_EACH_UPDATE) shows allways 0 FPS. Compared to earlier Version shows, that the if statement in 394 has been negated and the assigment in 397 (par->update_time = ts_start;) has to be moved (now 408) after the usage in 398 (now 397). Now the value of fps is correctly calculated.
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Aug 18, 2020
@morimoto @intel-lab-lkp
ASoC: soc-core: use client_mutex for snd_soc_find_dai()
39e4bfe 
commit 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.

	struct snd_soc_dai *snd_soc_find_dai(xxx)
	{
		...
(B)		lockdep_assert_held(&client_mutex);
		...
	}

	void snd_soc_dai_link_set_capabilities(xxx)
	{
		...
		for_each_pcm_streams(direction) {
			...
			for_each_link_cpus(dai_link, i, cpu) {
(A)				dai = snd_soc_find_dai(cpu);
				...
			}
			...
			for_each_link_codecs(dai_link, i, codec) {
(A)				dai = snd_soc_find_dai(codec);
				...
			}
		}
		...
	}

Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.

	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ torvalds#328
	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
	Workqueue: events deferred_probe_work_func
	pstate: 60000005 (nZCv daif -PAN -UAO)
	pc : snd_soc_find_dai+0xf8/0x100
	lr : snd_soc_find_dai+0xf4/0x100
	...
	Call trace:
	 snd_soc_find_dai+0xf8/0x100
	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
	 graph_dai_link_of_dpcm+0x390/0x3c0
	 graph_for_each_link+0x134/0x200
	 graph_probe+0x144/0x230
	 platform_drv_probe+0x5c/0xb0
	 really_probe+0xe4/0x430
	 driver_probe_device+0x60/0xf4

Many drivers are already calling snd_soc_find_dai() and/or snd_soc_dai_link_set_capabilities().
Thus, same thing can be happen on these drivers, too.

	> grep snd_soc_find_dai -rl sound/soc/*
	sound/soc/samsung/tm2_wm5110.c
	sound/soc/soc-core.c
	sound/soc/soc-dai.c
	sound/soc/soc-topology.c
	sound/soc/sof/topology.c

	> grep snd_soc_dai_link_set_capabilities -rl sound/soc/*
	sound/soc/generic/simple-card.c
	sound/soc/generic/audio-graph-card.c
	sound/soc/qcom/common.c
	sound/soc/soc-dai.c

This patch renames current snd_soc_find_dai() to _no_mutex(),
and new snd_soc_find_dai() uses client_mutex.

Fixes: 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Aug 18, 2020
@morimoto @intel-lab-lkp
ASoC: soc-core: move snd_soc_dai_link_set_capabilities() to soc-core.c
c2b7a78 
commit 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.

	struct snd_soc_dai *snd_soc_find_dai(xxx)
	{
		...
(B)		lockdep_assert_held(&client_mutex);
		...
	}

	void snd_soc_dai_link_set_capabilities(xxx)
	{
		...
		for_each_pcm_streams(direction) {
			...
			for_each_link_cpus(dai_link, i, cpu) {
(A)				dai = snd_soc_find_dai(cpu);
				...
			}
			...
			for_each_link_codecs(dai_link, i, codec) {
(A)				dai = snd_soc_find_dai(codec);
				...
			}
		}
		...
	}

Because of this, we will get WARNING.

	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ torvalds#328
	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
	Workqueue: events deferred_probe_work_func
	pstate: 60000005 (nZCv daif -PAN -UAO)
	pc : snd_soc_find_dai+0xf8/0x100
	lr : snd_soc_find_dai+0xf4/0x100
	...
	Call trace:
	 snd_soc_find_dai+0xf8/0x100
	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
	 graph_dai_link_of_dpcm+0x390/0x3c0
	 graph_for_each_link+0x134/0x200
	 graph_probe+0x144/0x230
	 platform_drv_probe+0x5c/0xb0
	 really_probe+0xe4/0x430
	 driver_probe_device+0x60/0xf4

Because not only snd_soc_dai_link_set_capabilities() but many drivers
are already using snd_soc_find_dai(),
1st idea for this issue was creating snd_soc_find_dai() of
_with_mutex / _without_mutex, but it was not enough and/or confusable.

soc-dai.c which is implemented snd_soc_dai_link_set_capabilities() currently is
mainly for snd_soc_dai related functions, not for snd_soc_dai_link.
Thus as 2nd idea, this patch moves snd_soc_dai_link_set_capabilities()
from soc-dai.c to soc-core.c, and use mutex_lock().

Fixes: 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Aug 27, 2020
@morimoto @intel-lab-lkp
ASoC: soc-core: add snd_soc_find_dai_with_mutex()
41b84e9 
commit 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.

	struct snd_soc_dai *snd_soc_find_dai(xxx)
	{
		...
(B)		lockdep_assert_held(&client_mutex);
		...
	}

	void snd_soc_dai_link_set_capabilities(xxx)
	{
		...
		for_each_pcm_streams(direction) {
			...
			for_each_link_cpus(dai_link, i, cpu) {
(A)				dai = snd_soc_find_dai(cpu);
				...
			}
			...
			for_each_link_codecs(dai_link, i, codec) {
(A)				dai = snd_soc_find_dai(codec);
				...
			}
		}
		...
	}

Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.

	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ torvalds#328
	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
	Workqueue: events deferred_probe_work_func
	pstate: 60000005 (nZCv daif -PAN -UAO)
	pc : snd_soc_find_dai+0xf8/0x100
	lr : snd_soc_find_dai+0xf4/0x100
	...
	Call trace:
	 snd_soc_find_dai+0xf8/0x100
	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
	 graph_dai_link_of_dpcm+0x390/0x3c0
	 graph_for_each_link+0x134/0x200
	 graph_probe+0x144/0x230
	 platform_drv_probe+0x5c/0xb0
	 really_probe+0xe4/0x430
	 driver_probe_device+0x60/0xf4

snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
mutex lock, and (Y) Card driver without mutex lock.
This snd_soc_dai_link_set_capabilities() is for Card driver,
this means called without mutex.
This patch adds snd_soc_find_dai_with_mutex() to solve it.

Fixes: 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
morimoto added a commit to morimoto/linux that referenced this pull request Aug 27, 2020
@morimoto
ASoC: soc-core: move snd_soc_dai_link_set_capabilities() to soc-core.c
d4a9cf1 
commit 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.

	struct snd_soc_dai *snd_soc_find_dai(xxx)
	{
		...
(B)		lockdep_assert_held(&client_mutex);
		...
	}

	void snd_soc_dai_link_set_capabilities(xxx)
	{
		...
		for_each_pcm_streams(direction) {
			...
			for_each_link_cpus(dai_link, i, cpu) {
(A)				dai = snd_soc_find_dai(cpu);
				...
			}
			...
			for_each_link_codecs(dai_link, i, codec) {
(A)				dai = snd_soc_find_dai(codec);
				...
			}
		}
		...
	}

Because of this, we will get WARNING.

	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ torvalds#328
	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
	Workqueue: events deferred_probe_work_func
	pstate: 60000005 (nZCv daif -PAN -UAO)
	pc : snd_soc_find_dai+0xf8/0x100
	lr : snd_soc_find_dai+0xf4/0x100
	...
	Call trace:
	 snd_soc_find_dai+0xf8/0x100
	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
	 graph_dai_link_of_dpcm+0x390/0x3c0
	 graph_for_each_link+0x134/0x200
	 graph_probe+0x144/0x230
	 platform_drv_probe+0x5c/0xb0
	 really_probe+0xe4/0x430
	 driver_probe_device+0x60/0xf4

soc-dai.c which is implemented snd_soc_dai_link_set_capabilities() currently is
mainly for snd_soc_dai related functions, not for snd_soc_dai_link.
This patch moves snd_soc_dai_link_set_capabilities() from soc-dai.c to soc-core.c
and use mutex_lock().

Fixes: 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
morimoto added a commit to morimoto/linux that referenced this pull request Aug 27, 2020
@morimoto
ASoC: soc-core: add snd_soc_find_dai_with_mutex()
cccf630 
commit 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.

	struct snd_soc_dai *snd_soc_find_dai(xxx)
	{
		...
(B)		lockdep_assert_held(&client_mutex);
		...
	}

	void snd_soc_dai_link_set_capabilities(xxx)
	{
		...
		for_each_pcm_streams(direction) {
			...
			for_each_link_cpus(dai_link, i, cpu) {
(A)				dai = snd_soc_find_dai(cpu);
				...
			}
			...
			for_each_link_codecs(dai_link, i, codec) {
(A)				dai = snd_soc_find_dai(codec);
				...
			}
		}
		...
	}

Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.

	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ torvalds#328
	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
	Workqueue: events deferred_probe_work_func
	pstate: 60000005 (nZCv daif -PAN -UAO)
	pc : snd_soc_find_dai+0xf8/0x100
	lr : snd_soc_find_dai+0xf4/0x100
	...
	Call trace:
	 snd_soc_find_dai+0xf8/0x100
	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
	 graph_dai_link_of_dpcm+0x390/0x3c0
	 graph_for_each_link+0x134/0x200
	 graph_probe+0x144/0x230
	 platform_drv_probe+0x5c/0xb0
	 really_probe+0xe4/0x430
	 driver_probe_device+0x60/0xf4

snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
mutex lock, and (Y) Card driver without mutex lock.
This snd_soc_dai_link_set_capabilities() is for Card driver,
this means called without mutex.
This patch adds snd_soc_find_dai_with_mutex() to solve it.

Fixes: 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
plbossart pushed a commit to plbossart/sound that referenced this pull request Aug 27, 2020
@morimoto @broonie
ASoC: soc-core: add snd_soc_find_dai_with_mutex()
c1c277b 
commit 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.

	struct snd_soc_dai *snd_soc_find_dai(xxx)
	{
		...
(B)		lockdep_assert_held(&client_mutex);
		...
	}

	void snd_soc_dai_link_set_capabilities(xxx)
	{
		...
		for_each_pcm_streams(direction) {
			...
			for_each_link_cpus(dai_link, i, cpu) {
(A)				dai = snd_soc_find_dai(cpu);
				...
			}
			...
			for_each_link_codecs(dai_link, i, codec) {
(A)				dai = snd_soc_find_dai(codec);
				...
			}
		}
		...
	}

Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.

	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ torvalds#328
	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
	Workqueue: events deferred_probe_work_func
	pstate: 60000005 (nZCv daif -PAN -UAO)
	pc : snd_soc_find_dai+0xf8/0x100
	lr : snd_soc_find_dai+0xf4/0x100
	...
	Call trace:
	 snd_soc_find_dai+0xf8/0x100
	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
	 graph_dai_link_of_dpcm+0x390/0x3c0
	 graph_for_each_link+0x134/0x200
	 graph_probe+0x144/0x230
	 platform_drv_probe+0x5c/0xb0
	 really_probe+0xe4/0x430
	 driver_probe_device+0x60/0xf4

snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
mutex lock, and (Y) Card driver without mutex lock.
This snd_soc_dai_link_set_capabilities() is for Card driver,
this means called without mutex.
This patch adds snd_soc_find_dai_with_mutex() to solve it.

Fixes: 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blixvuab.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Aug 28, 2020
@morimoto @broonie
ASoC: soc-core: add snd_soc_find_dai_with_mutex()
20d9fde 
commit 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.

	struct snd_soc_dai *snd_soc_find_dai(xxx)
	{
		...
(B)		lockdep_assert_held(&client_mutex);
		...
	}

	void snd_soc_dai_link_set_capabilities(xxx)
	{
		...
		for_each_pcm_streams(direction) {
			...
			for_each_link_cpus(dai_link, i, cpu) {
(A)				dai = snd_soc_find_dai(cpu);
				...
			}
			...
			for_each_link_codecs(dai_link, i, codec) {
(A)				dai = snd_soc_find_dai(codec);
				...
			}
		}
		...
	}

Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.

	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ torvalds#328
	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
	Workqueue: events deferred_probe_work_func
	pstate: 60000005 (nZCv daif -PAN -UAO)
	pc : snd_soc_find_dai+0xf8/0x100
	lr : snd_soc_find_dai+0xf4/0x100
	...
	Call trace:
	 snd_soc_find_dai+0xf8/0x100
	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
	 graph_dai_link_of_dpcm+0x390/0x3c0
	 graph_for_each_link+0x134/0x200
	 graph_probe+0x144/0x230
	 platform_drv_probe+0x5c/0xb0
	 really_probe+0xe4/0x430
	 driver_probe_device+0x60/0xf4

snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
mutex lock, and (Y) Card driver without mutex lock.
This snd_soc_dai_link_set_capabilities() is for Card driver,
this means called without mutex.
This patch adds snd_soc_find_dai_with_mutex() to solve it.

Fixes: 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blixvuab.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
jackpot51 referenced this pull request in pop-os/linux Oct 19, 2020
@morimoto @piso77
ASoC: soc-core: add snd_soc_find_dai_with_mutex()
c9af2e9 
BugLink: https://bugs.launchpad.net/bugs/1896795

[ Upstream commit 20d9fde ]

commit 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.

	struct snd_soc_dai *snd_soc_find_dai(xxx)
	{
		...
(B)		lockdep_assert_held(&client_mutex);
		...
	}

	void snd_soc_dai_link_set_capabilities(xxx)
	{
		...
		for_each_pcm_streams(direction) {
			...
			for_each_link_cpus(dai_link, i, cpu) {
(A)				dai = snd_soc_find_dai(cpu);
				...
			}
			...
			for_each_link_codecs(dai_link, i, codec) {
(A)				dai = snd_soc_find_dai(codec);
				...
			}
		}
		...
	}

Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.

	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ #328
	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
	Workqueue: events deferred_probe_work_func
	pstate: 60000005 (nZCv daif -PAN -UAO)
	pc : snd_soc_find_dai+0xf8/0x100
	lr : snd_soc_find_dai+0xf4/0x100
	...
	Call trace:
	 snd_soc_find_dai+0xf8/0x100
	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
	 graph_dai_link_of_dpcm+0x390/0x3c0
	 graph_for_each_link+0x134/0x200
	 graph_probe+0x144/0x230
	 platform_drv_probe+0x5c/0xb0
	 really_probe+0xe4/0x430
	 driver_probe_device+0x60/0xf4

snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
mutex lock, and (Y) Card driver without mutex lock.
This snd_soc_dai_link_set_capabilities() is for Card driver,
this means called without mutex.
This patch adds snd_soc_find_dai_with_mutex() to solve it.

Fixes: 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blixvuab.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 12, 2021
@intel-lab-lkp
staging: rtl8723bs: remove typedefs in HalBtcOutSrc.h
2c3189b 
This commit fixes the following checkpatch.pl warnings:

    WARNING: do not add new typedefs
    torvalds#47: FILE: hal/HalBtcOutSrc.h:47:
    +typedef enum _BTC_POWERSAVE_TYPE {

    WARNING: do not add new typedefs
    torvalds#54: FILE: hal/HalBtcOutSrc.h:54:
    +typedef enum _BTC_BT_REG_TYPE {

    WARNING: do not add new typedefs
    torvalds#63: FILE: hal/HalBtcOutSrc.h:63:
    +typedef enum _BTC_CHIP_INTERFACE {

    WARNING: do not add new typedefs
    torvalds#71: FILE: hal/HalBtcOutSrc.h:71:
    +typedef enum _BTC_CHIP_TYPE {

    WARNING: do not add new typedefs
    torvalds#81: FILE: hal/HalBtcOutSrc.h:81:
    +typedef enum _BTC_MSG_TYPE {

    WARNING: do not add new typedefs
    torvalds#167: FILE: hal/HalBtcOutSrc.h:167:
    +typedef struct _BTC_BOARD_INFO {

    WARNING: do not add new typedefs
    torvalds#177: FILE: hal/HalBtcOutSrc.h:177:
    +typedef enum _BTC_DBG_OPCODE {

    WARNING: do not add new typedefs
    torvalds#187: FILE: hal/HalBtcOutSrc.h:187:
    +typedef enum _BTC_RSSI_STATE {

    WARNING: do not add new typedefs
    torvalds#200: FILE: hal/HalBtcOutSrc.h:200:
    +typedef enum _BTC_WIFI_ROLE {

    WARNING: do not add new typedefs
    torvalds#208: FILE: hal/HalBtcOutSrc.h:208:
    +typedef enum _BTC_WIFI_BW_MODE {

    WARNING: do not add new typedefs
    torvalds#215: FILE: hal/HalBtcOutSrc.h:215:
    +typedef enum _BTC_WIFI_TRAFFIC_DIR {

    WARNING: do not add new typedefs
    torvalds#221: FILE: hal/HalBtcOutSrc.h:221:
    +typedef enum _BTC_WIFI_PNP {

    WARNING: do not add new typedefs
    torvalds#228: FILE: hal/HalBtcOutSrc.h:228:
    +typedef enum _BT_WIFI_COEX_STATE {

    WARNING: do not add new typedefs
    torvalds#239: FILE: hal/HalBtcOutSrc.h:239:
    +typedef enum _BTC_GET_TYPE {

    WARNING: do not add new typedefs
    torvalds#281: FILE: hal/HalBtcOutSrc.h:281:
    +typedef enum _BTC_SET_TYPE {

    WARNING: do not add new typedefs
    torvalds#321: FILE: hal/HalBtcOutSrc.h:321:
    +typedef enum _BTC_DBG_DISP_TYPE {

    WARNING: do not add new typedefs
    torvalds#328: FILE: hal/HalBtcOutSrc.h:328:
    +typedef enum _BTC_NOTIFY_TYPE_IPS {

    WARNING: do not add new typedefs
    torvalds#334: FILE: hal/HalBtcOutSrc.h:334:
    +typedef enum _BTC_NOTIFY_TYPE_LPS {

    WARNING: do not add new typedefs
    torvalds#340: FILE: hal/HalBtcOutSrc.h:340:
    +typedef enum _BTC_NOTIFY_TYPE_SCAN {

    WARNING: do not add new typedefs
    torvalds#346: FILE: hal/HalBtcOutSrc.h:346:
    +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE {

    WARNING: do not add new typedefs
    torvalds#352: FILE: hal/HalBtcOutSrc.h:352:
    +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS {

    WARNING: do not add new typedefs
    torvalds#358: FILE: hal/HalBtcOutSrc.h:358:
    +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET {

    WARNING: do not add new typedefs
    torvalds#366: FILE: hal/HalBtcOutSrc.h:366:
    +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION {

    WARNING: do not add new typedefs
    torvalds#374: FILE: hal/HalBtcOutSrc.h:374:
    +typedef enum _BTC_ANTENNA_POS {

    WARNING: do not add new typedefs
    torvalds#412: FILE: hal/HalBtcOutSrc.h:412:
    +typedef struct _BTC_BT_INFO {

    WARNING: do not add new typedefs
    torvalds#440: FILE: hal/HalBtcOutSrc.h:440:
    +typedef struct _BTC_STACK_INFO {

    WARNING: do not add new typedefs
    torvalds#455: FILE: hal/HalBtcOutSrc.h:455:
    +typedef struct _BTC_BT_LINK_INFO {

    WARNING: do not add new typedefs
    torvalds#468: FILE: hal/HalBtcOutSrc.h:468:
    +typedef struct _BTC_STATISTICS {

    WARNING: do not add new typedefs
    torvalds#487: FILE: hal/HalBtcOutSrc.h:487:
    +typedef struct _BTC_COEXIST {

Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 12, 2021
@intel-lab-lkp
staging: rtl8723bs: remove typedefs in odm.h
3b7b1fb 
This commit fixes the following checkpatch.pl warnings:

    WARNING: do not add new typedefs
    torvalds#95: FILE: hal/odm.h:95:
    +typedef struct _Rate_Adaptive_Table_ {

    WARNING: do not add new typedefs
    torvalds#99: FILE: hal/odm.h:99:
    +typedef struct _RX_High_Power_ {

    WARNING: do not add new typedefs
    torvalds#129: FILE: hal/odm.h:129:
    +typedef struct _SW_Antenna_Switch_ {

    WARNING: do not add new typedefs
    torvalds#181: FILE: hal/odm.h:181:
    +typedef struct _ODM_RATE_ADAPTIVE {

    WARNING: do not add new typedefs
    torvalds#280: FILE: hal/odm.h:280:
    +typedef enum tag_Dynamic_ODM_Support_Ability_Type {

    WARNING: do not add new typedefs
    torvalds#300: FILE: hal/odm.h:300:
    +typedef struct _ODM_STA_INFO {

    WARNING: do not add new typedefs
    torvalds#328: FILE: hal/odm.h:328:
    +typedef enum _ODM_Common_Info_Definition {

    WARNING: do not add new typedefs
    torvalds#418: FILE: hal/odm.h:418:
    +typedef enum _ODM_Support_Ability_Definition {

    WARNING: do not add new typedefs
    torvalds#449: FILE: hal/odm.h:449:
    +typedef enum tag_ODM_Support_Interface_Definition {

    WARNING: do not add new typedefs
    torvalds#455: FILE: hal/odm.h:455:
    +typedef enum tag_ODM_Support_IC_Type_Definition {

    WARNING: do not add new typedefs
    torvalds#460: FILE: hal/odm.h:460:
    +typedef enum tag_ODM_Cut_Version_Definition {

    WARNING: do not add new typedefs
    torvalds#475: FILE: hal/odm.h:475:
    +typedef enum tag_ODM_Fab_Version_Definition {

    WARNING: do not add new typedefs
    torvalds#484: FILE: hal/odm.h:484:
    +typedef enum tag_ODM_RF_Path_Bit_Definition {

    WARNING: do not add new typedefs
    torvalds#495: FILE: hal/odm.h:495:
    +typedef enum tag_ODM_RF_Type_Definition {

    WARNING: do not add new typedefs
    torvalds#516: FILE: hal/odm.h:516:
    +typedef enum tag_ODM_MAC_PHY_Mode_Definition {

    WARNING: do not add new typedefs
    torvalds#522: FILE: hal/odm.h:522:
    +typedef enum tag_BT_Coexist_Definition {

    WARNING: do not add new typedefs
    torvalds#530: FILE: hal/odm.h:530:
    +typedef enum tag_Operation_Mode_Definition {

    WARNING: do not add new typedefs
    torvalds#543: FILE: hal/odm.h:543:
    +typedef enum tag_Wireless_Mode_Definition {

    WARNING: do not add new typedefs
    torvalds#555: FILE: hal/odm.h:555:
    +typedef enum tag_Band_Type_Definition {

    WARNING: do not add new typedefs
    torvalds#563: FILE: hal/odm.h:563:
    +typedef enum tag_Secondary_Channel_Offset_Definition {

    WARNING: do not add new typedefs
    torvalds#570: FILE: hal/odm.h:570:
    +typedef enum tag_Security_Definition {

    WARNING: do not add new typedefs
    torvalds#582: FILE: hal/odm.h:582:
    +typedef enum tag_Bandwidth_Definition {

    WARNING: do not add new typedefs
    torvalds#593: FILE: hal/odm.h:593:
    +typedef enum tag_Board_Definition {

    WARNING: do not add new typedefs
    torvalds#605: FILE: hal/odm.h:605:
    +typedef enum tag_ODM_Package_Definition {

    WARNING: do not add new typedefs
    torvalds#612: FILE: hal/odm.h:612:
    +typedef enum tag_ODM_TYPE_GPA_Definition {

    WARNING: do not add new typedefs
    torvalds#617: FILE: hal/odm.h:617:
    +typedef enum tag_ODM_TYPE_APA_Definition {

    WARNING: do not add new typedefs
    torvalds#622: FILE: hal/odm.h:622:
    +typedef enum tag_ODM_TYPE_GLNA_Definition {

    WARNING: do not add new typedefs
    torvalds#629: FILE: hal/odm.h:629:
    +typedef enum tag_ODM_TYPE_ALNA_Definition {

    WARNING: do not add new typedefs
    torvalds#637: FILE: hal/odm.h:637:
    +typedef enum tag_CCA_Path {

    WARNING: do not add new typedefs
    torvalds#643: FILE: hal/odm.h:643:
    +typedef struct _ODM_RA_Info_ {

    WARNING: do not add new typedefs
    torvalds#675: FILE: hal/odm.h:675:
    +typedef struct _IQK_MATRIX_REGS_SETTING {

    WARNING: do not add new typedefs
    torvalds#683: FILE: hal/odm.h:683:
    +typedef struct ODM_RF_Calibration_Structure {

    WARNING: do not add new typedefs
    #788: FILE: hal/odm.h:788:
    +typedef struct _FAST_ANTENNA_TRAINNING_ {

    WARNING: do not add new typedefs
    torvalds#828: FILE: hal/odm.h:828:
    +typedef enum _FAT_STATE {

    WARNING: do not add new typedefs
    torvalds#833: FILE: hal/odm.h:833:
    +typedef enum _ANT_DIV_TYPE {

    WARNING: do not add new typedefs
    torvalds#843: FILE: hal/odm.h:843:
    +typedef struct _ODM_PATH_DIVERSITY_ {

    WARNING: do not add new typedefs
    torvalds#852: FILE: hal/odm.h:852:
    +typedef enum _BASEBAND_CONFIG_PHY_REG_PG_VALUE_TYPE {

    WARNING: do not add new typedefs
    torvalds#860: FILE: hal/odm.h:860:
    +typedef struct _ANT_DETECTED_INFO {

    WARNING: do not add new typedefs
    torvalds#870: FILE: hal/odm.h:870:
    +typedef  struct DM_Out_Source_Dynamic_Mechanism_Structure {

    WARNING: do not add new typedefs
    #1229: FILE: hal/odm.h:1229:
    + typedef enum _ODM_RF_CONTENT {

    WARNING: do not add new typedefs
    #1236: FILE: hal/odm.h:1236:
    +typedef enum _ODM_BB_Config_Type {

    WARNING: do not add new typedefs
    #1246: FILE: hal/odm.h:1246:
    +typedef enum _ODM_RF_Config_Type {

    WARNING: do not add new typedefs
    #1251: FILE: hal/odm.h:1251:
    +typedef enum _ODM_FW_Config_Type {

    WARNING: do not add new typedefs
    #1262: FILE: hal/odm.h:1262:
    +typedef enum _RT_STATUS {

    WARNING: do not add new typedefs
    #1319: FILE: hal/odm.h:1319:
    +typedef enum tag_1R_CCA_Type_Definition {

    WARNING: do not add new typedefs
    #1325: FILE: hal/odm.h:1325:
    +typedef enum tag_RF_Type_Definition {

    WARNING: do not add new typedefs
    #1334: FILE: hal/odm.h:1334:
    +typedef enum tag_SW_Antenna_Switch_Definition {

Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 13, 2021
@gregkh
staging: rtl8723bs: remove typedefs in HalBtcOutSrc.h
29a91bc 
This commit fixes the following checkpatch.pl warnings:

    WARNING: do not add new typedefs
    torvalds#47: FILE: hal/HalBtcOutSrc.h:47:
    +typedef enum _BTC_POWERSAVE_TYPE {

    WARNING: do not add new typedefs
    torvalds#54: FILE: hal/HalBtcOutSrc.h:54:
    +typedef enum _BTC_BT_REG_TYPE {

    WARNING: do not add new typedefs
    torvalds#63: FILE: hal/HalBtcOutSrc.h:63:
    +typedef enum _BTC_CHIP_INTERFACE {

    WARNING: do not add new typedefs
    torvalds#71: FILE: hal/HalBtcOutSrc.h:71:
    +typedef enum _BTC_CHIP_TYPE {

    WARNING: do not add new typedefs
    torvalds#81: FILE: hal/HalBtcOutSrc.h:81:
    +typedef enum _BTC_MSG_TYPE {

    WARNING: do not add new typedefs
    torvalds#167: FILE: hal/HalBtcOutSrc.h:167:
    +typedef struct _BTC_BOARD_INFO {

    WARNING: do not add new typedefs
    torvalds#177: FILE: hal/HalBtcOutSrc.h:177:
    +typedef enum _BTC_DBG_OPCODE {

    WARNING: do not add new typedefs
    torvalds#187: FILE: hal/HalBtcOutSrc.h:187:
    +typedef enum _BTC_RSSI_STATE {

    WARNING: do not add new typedefs
    torvalds#200: FILE: hal/HalBtcOutSrc.h:200:
    +typedef enum _BTC_WIFI_ROLE {

    WARNING: do not add new typedefs
    torvalds#208: FILE: hal/HalBtcOutSrc.h:208:
    +typedef enum _BTC_WIFI_BW_MODE {

    WARNING: do not add new typedefs
    torvalds#215: FILE: hal/HalBtcOutSrc.h:215:
    +typedef enum _BTC_WIFI_TRAFFIC_DIR {

    WARNING: do not add new typedefs
    torvalds#221: FILE: hal/HalBtcOutSrc.h:221:
    +typedef enum _BTC_WIFI_PNP {

    WARNING: do not add new typedefs
    torvalds#228: FILE: hal/HalBtcOutSrc.h:228:
    +typedef enum _BT_WIFI_COEX_STATE {

    WARNING: do not add new typedefs
    torvalds#239: FILE: hal/HalBtcOutSrc.h:239:
    +typedef enum _BTC_GET_TYPE {

    WARNING: do not add new typedefs
    torvalds#281: FILE: hal/HalBtcOutSrc.h:281:
    +typedef enum _BTC_SET_TYPE {

    WARNING: do not add new typedefs
    torvalds#321: FILE: hal/HalBtcOutSrc.h:321:
    +typedef enum _BTC_DBG_DISP_TYPE {

    WARNING: do not add new typedefs
    torvalds#328: FILE: hal/HalBtcOutSrc.h:328:
    +typedef enum _BTC_NOTIFY_TYPE_IPS {

    WARNING: do not add new typedefs
    torvalds#334: FILE: hal/HalBtcOutSrc.h:334:
    +typedef enum _BTC_NOTIFY_TYPE_LPS {

    WARNING: do not add new typedefs
    torvalds#340: FILE: hal/HalBtcOutSrc.h:340:
    +typedef enum _BTC_NOTIFY_TYPE_SCAN {

    WARNING: do not add new typedefs
    torvalds#346: FILE: hal/HalBtcOutSrc.h:346:
    +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE {

    WARNING: do not add new typedefs
    torvalds#352: FILE: hal/HalBtcOutSrc.h:352:
    +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS {

    WARNING: do not add new typedefs
    torvalds#358: FILE: hal/HalBtcOutSrc.h:358:
    +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET {

    WARNING: do not add new typedefs
    torvalds#366: FILE: hal/HalBtcOutSrc.h:366:
    +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION {

    WARNING: do not add new typedefs
    torvalds#374: FILE: hal/HalBtcOutSrc.h:374:
    +typedef enum _BTC_ANTENNA_POS {

    WARNING: do not add new typedefs
    torvalds#412: FILE: hal/HalBtcOutSrc.h:412:
    +typedef struct _BTC_BT_INFO {

    WARNING: do not add new typedefs
    torvalds#440: FILE: hal/HalBtcOutSrc.h:440:
    +typedef struct _BTC_STACK_INFO {

    WARNING: do not add new typedefs
    torvalds#455: FILE: hal/HalBtcOutSrc.h:455:
    +typedef struct _BTC_BT_LINK_INFO {

    WARNING: do not add new typedefs
    torvalds#468: FILE: hal/HalBtcOutSrc.h:468:
    +typedef struct _BTC_STATISTICS {

    WARNING: do not add new typedefs
    torvalds#487: FILE: hal/HalBtcOutSrc.h:487:
    +typedef struct _BTC_COEXIST {

Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210312082638.25512-2-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 13, 2021
@gregkh
staging: rtl8723bs: remove typedefs in odm.h
694a76b 
This commit fixes the following checkpatch.pl warnings:

    WARNING: do not add new typedefs
    torvalds#95: FILE: hal/odm.h:95:
    +typedef struct _Rate_Adaptive_Table_ {

    WARNING: do not add new typedefs
    torvalds#99: FILE: hal/odm.h:99:
    +typedef struct _RX_High_Power_ {

    WARNING: do not add new typedefs
    torvalds#129: FILE: hal/odm.h:129:
    +typedef struct _SW_Antenna_Switch_ {

    WARNING: do not add new typedefs
    torvalds#181: FILE: hal/odm.h:181:
    +typedef struct _ODM_RATE_ADAPTIVE {

    WARNING: do not add new typedefs
    torvalds#280: FILE: hal/odm.h:280:
    +typedef enum tag_Dynamic_ODM_Support_Ability_Type {

    WARNING: do not add new typedefs
    torvalds#300: FILE: hal/odm.h:300:
    +typedef struct _ODM_STA_INFO {

    WARNING: do not add new typedefs
    torvalds#328: FILE: hal/odm.h:328:
    +typedef enum _ODM_Common_Info_Definition {

    WARNING: do not add new typedefs
    torvalds#418: FILE: hal/odm.h:418:
    +typedef enum _ODM_Support_Ability_Definition {

    WARNING: do not add new typedefs
    torvalds#449: FILE: hal/odm.h:449:
    +typedef enum tag_ODM_Support_Interface_Definition {

    WARNING: do not add new typedefs
    torvalds#455: FILE: hal/odm.h:455:
    +typedef enum tag_ODM_Support_IC_Type_Definition {

    WARNING: do not add new typedefs
    torvalds#460: FILE: hal/odm.h:460:
    +typedef enum tag_ODM_Cut_Version_Definition {

    WARNING: do not add new typedefs
    torvalds#475: FILE: hal/odm.h:475:
    +typedef enum tag_ODM_Fab_Version_Definition {

    WARNING: do not add new typedefs
    torvalds#484: FILE: hal/odm.h:484:
    +typedef enum tag_ODM_RF_Path_Bit_Definition {

    WARNING: do not add new typedefs
    torvalds#495: FILE: hal/odm.h:495:
    +typedef enum tag_ODM_RF_Type_Definition {

    WARNING: do not add new typedefs
    torvalds#516: FILE: hal/odm.h:516:
    +typedef enum tag_ODM_MAC_PHY_Mode_Definition {

    WARNING: do not add new typedefs
    torvalds#522: FILE: hal/odm.h:522:
    +typedef enum tag_BT_Coexist_Definition {

    WARNING: do not add new typedefs
    torvalds#530: FILE: hal/odm.h:530:
    +typedef enum tag_Operation_Mode_Definition {

    WARNING: do not add new typedefs
    torvalds#543: FILE: hal/odm.h:543:
    +typedef enum tag_Wireless_Mode_Definition {

    WARNING: do not add new typedefs
    torvalds#555: FILE: hal/odm.h:555:
    +typedef enum tag_Band_Type_Definition {

    WARNING: do not add new typedefs
    torvalds#563: FILE: hal/odm.h:563:
    +typedef enum tag_Secondary_Channel_Offset_Definition {

    WARNING: do not add new typedefs
    torvalds#570: FILE: hal/odm.h:570:
    +typedef enum tag_Security_Definition {

    WARNING: do not add new typedefs
    torvalds#582: FILE: hal/odm.h:582:
    +typedef enum tag_Bandwidth_Definition {

    WARNING: do not add new typedefs
    torvalds#593: FILE: hal/odm.h:593:
    +typedef enum tag_Board_Definition {

    WARNING: do not add new typedefs
    torvalds#605: FILE: hal/odm.h:605:
    +typedef enum tag_ODM_Package_Definition {

    WARNING: do not add new typedefs
    torvalds#612: FILE: hal/odm.h:612:
    +typedef enum tag_ODM_TYPE_GPA_Definition {

    WARNING: do not add new typedefs
    torvalds#617: FILE: hal/odm.h:617:
    +typedef enum tag_ODM_TYPE_APA_Definition {

    WARNING: do not add new typedefs
    torvalds#622: FILE: hal/odm.h:622:
    +typedef enum tag_ODM_TYPE_GLNA_Definition {

    WARNING: do not add new typedefs
    torvalds#629: FILE: hal/odm.h:629:
    +typedef enum tag_ODM_TYPE_ALNA_Definition {

    WARNING: do not add new typedefs
    torvalds#637: FILE: hal/odm.h:637:
    +typedef enum tag_CCA_Path {

    WARNING: do not add new typedefs
    torvalds#643: FILE: hal/odm.h:643:
    +typedef struct _ODM_RA_Info_ {

    WARNING: do not add new typedefs
    torvalds#675: FILE: hal/odm.h:675:
    +typedef struct _IQK_MATRIX_REGS_SETTING {

    WARNING: do not add new typedefs
    torvalds#683: FILE: hal/odm.h:683:
    +typedef struct ODM_RF_Calibration_Structure {

    WARNING: do not add new typedefs
    #788: FILE: hal/odm.h:788:
    +typedef struct _FAST_ANTENNA_TRAINNING_ {

    WARNING: do not add new typedefs
    torvalds#828: FILE: hal/odm.h:828:
    +typedef enum _FAT_STATE {

    WARNING: do not add new typedefs
    torvalds#833: FILE: hal/odm.h:833:
    +typedef enum _ANT_DIV_TYPE {

    WARNING: do not add new typedefs
    torvalds#843: FILE: hal/odm.h:843:
    +typedef struct _ODM_PATH_DIVERSITY_ {

    WARNING: do not add new typedefs
    torvalds#852: FILE: hal/odm.h:852:
    +typedef enum _BASEBAND_CONFIG_PHY_REG_PG_VALUE_TYPE {

    WARNING: do not add new typedefs
    torvalds#860: FILE: hal/odm.h:860:
    +typedef struct _ANT_DETECTED_INFO {

    WARNING: do not add new typedefs
    torvalds#870: FILE: hal/odm.h:870:
    +typedef  struct DM_Out_Source_Dynamic_Mechanism_Structure {

    WARNING: do not add new typedefs
    #1229: FILE: hal/odm.h:1229:
    + typedef enum _ODM_RF_CONTENT {

    WARNING: do not add new typedefs
    #1236: FILE: hal/odm.h:1236:
    +typedef enum _ODM_BB_Config_Type {

    WARNING: do not add new typedefs
    #1246: FILE: hal/odm.h:1246:
    +typedef enum _ODM_RF_Config_Type {

    WARNING: do not add new typedefs
    #1251: FILE: hal/odm.h:1251:
    +typedef enum _ODM_FW_Config_Type {

    WARNING: do not add new typedefs
    #1262: FILE: hal/odm.h:1262:
    +typedef enum _RT_STATUS {

    WARNING: do not add new typedefs
    #1319: FILE: hal/odm.h:1319:
    +typedef enum tag_1R_CCA_Type_Definition {

    WARNING: do not add new typedefs
    #1325: FILE: hal/odm.h:1325:
    +typedef enum tag_RF_Type_Definition {

    WARNING: do not add new typedefs
    #1334: FILE: hal/odm.h:1334:
    +typedef enum tag_SW_Antenna_Switch_Definition {

Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210312082638.25512-4-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
morimoto added a commit to morimoto/linux that referenced this pull request Apr 5, 2021
@morimoto
ASoC: soc-core: move snd_soc_dai_link_set_capabilities() to soc-core.c
e82f23d 
commit 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.

	struct snd_soc_dai *snd_soc_find_dai(xxx)
	{
		...
(B)		lockdep_assert_held(&client_mutex);
		...
	}

	void snd_soc_dai_link_set_capabilities(xxx)
	{
		...
		for_each_pcm_streams(direction) {
			...
			for_each_link_cpus(dai_link, i, cpu) {
(A)				dai = snd_soc_find_dai(cpu);
				...
			}
			...
			for_each_link_codecs(dai_link, i, codec) {
(A)				dai = snd_soc_find_dai(codec);
				...
			}
		}
		...
	}

Because of this, we will get WARNING.

	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ torvalds#328
	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
	Workqueue: events deferred_probe_work_func
	pstate: 60000005 (nZCv daif -PAN -UAO)
	pc : snd_soc_find_dai+0xf8/0x100
	lr : snd_soc_find_dai+0xf4/0x100
	...
	Call trace:
	 snd_soc_find_dai+0xf8/0x100
	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
	 graph_dai_link_of_dpcm+0x390/0x3c0
	 graph_for_each_link+0x134/0x200
	 graph_probe+0x144/0x230
	 platform_drv_probe+0x5c/0xb0
	 really_probe+0xe4/0x430
	 driver_probe_device+0x60/0xf4

soc-dai.c which is implemented snd_soc_dai_link_set_capabilities() currently is
mainly for snd_soc_dai related functions, not for snd_soc_dai_link.
This patch moves snd_soc_dai_link_set_capabilities() from soc-dai.c to soc-core.c
and use mutex_lock().

Fixes: 2561247 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request May 19, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
653e5ac 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  We will simply loop to create block groups until we have
space_info->full set or no tickets.  Unfortunately if we aborted the
transaction then we will never allocate chunks and thus never get
->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by also checking if we have BTRFS_FS_STATE_TRANS_ABORTED set on
the fs_info and bail out accordingly.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request May 21, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
8cca570 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request May 25, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
d2a189c 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request May 26, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
d92bcec 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Jun 1, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
8eb8657 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Jun 16, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
1312df8 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Jun 18, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
10b091c 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Jun 21, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
e5b4611 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Jun 30, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
2401f51 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Jul 27, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
53c2786 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Jul 28, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
2a37fd5 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Jul 28, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
e6a67e7 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Aug 11, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
26eb3ab 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Aug 18, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
a27713a 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Aug 24, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
232b0dd 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
pipcet pushed a commit to pipcet/linux that referenced this pull request Sep 1, 2021
@josefbacik @pipcet
fs/btrfs/space-info.c:
ea6e687 
#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Sep 13, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
cc64e01 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Oct 6, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
0bd9add 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this:

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
  CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: events_unbound btrfs_async_reclaim_data_space
  RIP: 0010:btrfs_join_transaction+0x12/0x20
  RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
  RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
  RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
  R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
  R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
  FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
  Call Trace:
   flush_space+0x4a8/0x660
   btrfs_async_reclaim_data_space+0x55/0x130
   process_one_work+0x1e9/0x380
   worker_thread+0x53/0x3e0
   ? process_one_work+0x380/0x380
   kthread+0x118/0x140
   ? __kthread_bind_mask+0x60/0x60
   ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Oct 6, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
a2943a3 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this:

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
  CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: events_unbound btrfs_async_reclaim_data_space
  RIP: 0010:btrfs_join_transaction+0x12/0x20
  RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
  RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
  RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
  R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
  R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
  FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
  Call Trace:
   flush_space+0x4a8/0x660
   btrfs_async_reclaim_data_space+0x55/0x130
   process_one_work+0x1e9/0x380
   worker_thread+0x53/0x3e0
   ? process_one_work+0x380/0x380
   kthread+0x118/0x140
   ? __kthread_bind_mask+0x60/0x60
   ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Oct 9, 2021
@josefbacik @intel-lab-lkp
btrfs: do not infinite loop in data reclaim if we aborted
4d626ae 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Oct 9, 2021
@josefbacik @intel-lab-lkp
btrfs: do not infinite loop in data reclaim if we aborted
dc05f0d 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this

watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: events_unbound btrfs_async_reclaim_data_space
RIP: 0010:btrfs_join_transaction+0x12/0x20
RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
Call Trace:
 flush_space+0x4a8/0x660
 btrfs_async_reclaim_data_space+0x55/0x130
 process_one_work+0x1e9/0x380
 worker_thread+0x53/0x3e0
 ? process_one_work+0x380/0x380
 kthread+0x118/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Oct 11, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
b668d34 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this:

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
  CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: events_unbound btrfs_async_reclaim_data_space
  RIP: 0010:btrfs_join_transaction+0x12/0x20
  RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
  RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
  RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
  R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
  R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
  FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
  Call Trace:
   flush_space+0x4a8/0x660
   btrfs_async_reclaim_data_space+0x55/0x130
   process_one_work+0x1e9/0x380
   worker_thread+0x53/0x3e0
   ? process_one_work+0x380/0x380
   kthread+0x118/0x140
   ? __kthread_bind_mask+0x60/0x60
   ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Oct 14, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
d5f9de6 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this:

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
  CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: events_unbound btrfs_async_reclaim_data_space
  RIP: 0010:btrfs_join_transaction+0x12/0x20
  RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
  RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
  RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
  R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
  R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
  FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
  Call Trace:
   flush_space+0x4a8/0x660
   btrfs_async_reclaim_data_space+0x55/0x130
   process_one_work+0x1e9/0x380
   worker_thread+0x53/0x3e0
   ? process_one_work+0x380/0x380
   kthread+0x118/0x140
   ? __kthread_bind_mask+0x60/0x60
   ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Oct 18, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
c243cb7 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this:

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
  CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: events_unbound btrfs_async_reclaim_data_space
  RIP: 0010:btrfs_join_transaction+0x12/0x20
  RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
  RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
  RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
  R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
  R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
  FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
  Call Trace:
   flush_space+0x4a8/0x660
   btrfs_async_reclaim_data_space+0x55/0x130
   process_one_work+0x1e9/0x380
   worker_thread+0x53/0x3e0
   ? process_one_work+0x380/0x380
   kthread+0x118/0x140
   ? __kthread_bind_mask+0x60/0x60
   ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Oct 25, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
1871904 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this:

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
  CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: events_unbound btrfs_async_reclaim_data_space
  RIP: 0010:btrfs_join_transaction+0x12/0x20
  RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
  RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
  RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
  R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
  R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
  FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
  Call Trace:
   flush_space+0x4a8/0x660
   btrfs_async_reclaim_data_space+0x55/0x130
   process_one_work+0x1e9/0x380
   worker_thread+0x53/0x3e0
   ? process_one_work+0x380/0x380
   kthread+0x118/0x140
   ? __kthread_bind_mask+0x60/0x60
   ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Oct 25, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
197643e 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this:

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
  CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: events_unbound btrfs_async_reclaim_data_space
  RIP: 0010:btrfs_join_transaction+0x12/0x20
  RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
  RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
  RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
  R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
  R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
  FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
  Call Trace:
   flush_space+0x4a8/0x660
   btrfs_async_reclaim_data_space+0x55/0x130
   process_one_work+0x1e9/0x380
   worker_thread+0x53/0x3e0
   ? process_one_work+0x380/0x380
   kthread+0x118/0x140
   ? __kthread_bind_mask+0x60/0x60
   ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Oct 25, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
5729d8c 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this:

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
  CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: events_unbound btrfs_async_reclaim_data_space
  RIP: 0010:btrfs_join_transaction+0x12/0x20
  RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
  RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
  RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
  R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
  R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
  FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
  Call Trace:
   flush_space+0x4a8/0x660
   btrfs_async_reclaim_data_space+0x55/0x130
   process_one_work+0x1e9/0x380
   worker_thread+0x53/0x3e0
   ? process_one_work+0x380/0x380
   kthread+0x118/0x140
   ? __kthread_bind_mask+0x60/0x60
   ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Oct 26, 2021
@josefbacik @kdave
btrfs: do not infinite loop in data reclaim if we aborted
0e24f6d 
Error injection stressing uncovered a busy loop in our data reclaim
loop.  There are two cases here, one where we loop creating block groups
until space_info->full is set, or in the main loop we will skip erroring
out any tickets if space_info->full == 0.  Unfortunately if we aborted
the transaction then we will never allocate chunks or reclaim any space
and thus never get ->full, and you'll see stack traces like this:

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [kworker/u4:4:139]
  CPU: 0 PID: 139 Comm: kworker/u4:4 Tainted: G        W         5.13.0-rc1+ torvalds#328
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: events_unbound btrfs_async_reclaim_data_space
  RIP: 0010:btrfs_join_transaction+0x12/0x20
  RSP: 0018:ffffb2b780b77de0 EFLAGS: 00000246
  RAX: ffffb2b781863d58 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000801 RSI: ffff987952b57400 RDI: ffff987940aa3000
  RBP: ffff987954d55000 R08: 0000000000000001 R09: ffff98795539e8f0
  R10: 000000000000000f R11: 000000000000000f R12: ffffffffffffffff
  R13: ffff987952b574c8 R14: ffff987952b57400 R15: 0000000000000008
  FS:  0000000000000000(0000) GS:ffff9879bbc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f0703da4000 CR3: 0000000113398004 CR4: 0000000000370ef0
  Call Trace:
   flush_space+0x4a8/0x660
   btrfs_async_reclaim_data_space+0x55/0x130
   process_one_work+0x1e9/0x380
   worker_thread+0x53/0x3e0
   ? process_one_work+0x380/0x380
   kthread+0x118/0x140
   ? __kthread_bind_mask+0x60/0x60
   ret_from_fork+0x1f/0x30

Fix this by checking to see if we have a btrfs fs error in either of the
reclaim loops, and if so fail the tickets and bail.  In addition to
this, fix maybe_fail_all_tickets() to not try to grant tickets if we've
aborted, simply fail everything.

Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Oct 13, 2022
@guoren83 @intel-lab-lkp
net: Fixup virtnet_set_affinity() cause cpumask warning
2b7b5c3 
Don't pass nr_bits-1 as arg1 for cpumask_next_wrap, which would
cause warning now.

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at include/linux/cpumask.h:110 cpumask_next_wrap+0x5c/0x80
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-11659-ge7e38f6cce55-dirty torvalds#328
Hardware name: riscv-virtio,qemu (DT)
epc : cpumask_next_wrap+0x5c/0x80
 ra : virtnet_set_affinity+0x1ba/0x1fc
epc : ffffffff808992ca ra : ffffffff805d84ca sp : ff60000002327a50
 gp : ffffffff81602390 tp : ff600000023a0000 t0 : 5f74656e74726976
 t1 : 0000000000000000 t2 : 735f74656e747269 s0 : ff60000002327a90
 s1 : 0000000000000003 a0 : 0000000000000003 a1 : ffffffff816051c0
 a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000000
 a5 : 0000000000000004 a6 : 0000000000000000 a7 : 0000000000000000
 s2 : 0000000000000000 s3 : ffffffff816051c0 s4 : ffffffff8160224c
 s5 : 0000000000000004 s6 : 0000000000000004 s7 : 0000000000000000
 s8 : 0000000000000003 s9 : ffffffff810aa398 s10: ffffffff80e97d20
 s11: 0000000000000004 t3 : ffffffff819acc97 t4 : ffffffff819acc97
 t5 : ffffffff819acc98 t6 : ff60000002327878
status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003
[<ffffffff805d84ca>] virtnet_set_affinity+0x1ba/0x1fc
[<ffffffff805da7ac>] virtnet_probe+0x832/0xf1e
[<ffffffff804fe61c>] virtio_dev_probe+0x164/0x2de
[<ffffffff8054c4c4>] really_probe+0x82/0x224
[<ffffffff8054c6c0>] __driver_probe_device+0x5a/0xaa
[<ffffffff8054c73c>] driver_probe_device+0x2c/0xb8
[<ffffffff8054cd66>] __driver_attach+0x76/0x108
[<ffffffff8054a482>] bus_for_each_dev+0x52/0x9a
[<ffffffff8054be8c>] driver_attach+0x1a/0x28
[<ffffffff8054b996>] bus_add_driver+0x154/0x1c2
[<ffffffff8054d592>] driver_register+0x52/0x108
[<ffffffff804fe120>] register_virtio_driver+0x1c/0x2c
[<ffffffff80a29142>] virtio_net_driver_init+0x7a/0xb0
[<ffffffff80002854>] do_one_initcall+0x66/0x2e4
[<ffffffff80a01222>] kernel_init_freeable+0x28a/0x304
[<ffffffff808cb1be>] kernel_init+0x1e/0x110
[<ffffffff80003c4e>] ret_from_exception+0x0/0x10
---[ end trace 0000000000000000 ]---

Fixes: 78e5a33 ("cpumask: fix checking valid cpu range")
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Guo Ren <guoren@kernel.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Oct 14, 2022
@guoren83 @intel-lab-lkp
net: Fixup virtnet_set_affinity() cause cpumask warning
43cd630 
Don't pass nr_bits-1 as arg1 for cpumask_next_wrap, which would
cause warning now 78e5a33 ("cpumask: fix checking valid
cpu range").

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at include/linux/cpumask.h:110 cpumask_next_wrap+0x5c/0x80
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-11659-ge7e38f6cce55-dirty torvalds#328
Hardware name: riscv-virtio,qemu (DT)
epc : cpumask_next_wrap+0x5c/0x80
 ra : virtnet_set_affinity+0x1ba/0x1fc
epc : ffffffff808992ca ra : ffffffff805d84ca sp : ff60000002327a50
 gp : ffffffff81602390 tp : ff600000023a0000 t0 : 5f74656e74726976
 t1 : 0000000000000000 t2 : 735f74656e747269 s0 : ff60000002327a90
 s1 : 0000000000000003 a0 : 0000000000000003 a1 : ffffffff816051c0
 a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000000
 a5 : 0000000000000004 a6 : 0000000000000000 a7 : 0000000000000000
 s2 : 0000000000000000 s3 : ffffffff816051c0 s4 : ffffffff8160224c
 s5 : 0000000000000004 s6 : 0000000000000004 s7 : 0000000000000000
 s8 : 0000000000000003 s9 : ffffffff810aa398 s10: ffffffff80e97d20
 s11: 0000000000000004 t3 : ffffffff819acc97 t4 : ffffffff819acc97
 t5 : ffffffff819acc98 t6 : ff60000002327878
status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003
[<ffffffff805d84ca>] virtnet_set_affinity+0x1ba/0x1fc
[<ffffffff805da7ac>] virtnet_probe+0x832/0xf1e
[<ffffffff804fe61c>] virtio_dev_probe+0x164/0x2de
[<ffffffff8054c4c4>] really_probe+0x82/0x224
[<ffffffff8054c6c0>] __driver_probe_device+0x5a/0xaa
[<ffffffff8054c73c>] driver_probe_device+0x2c/0xb8
[<ffffffff8054cd66>] __driver_attach+0x76/0x108
[<ffffffff8054a482>] bus_for_each_dev+0x52/0x9a
[<ffffffff8054be8c>] driver_attach+0x1a/0x28
[<ffffffff8054b996>] bus_add_driver+0x154/0x1c2
[<ffffffff8054d592>] driver_register+0x52/0x108
[<ffffffff804fe120>] register_virtio_driver+0x1c/0x2c
[<ffffffff80a29142>] virtio_net_driver_init+0x7a/0xb0
[<ffffffff80002854>] do_one_initcall+0x66/0x2e4
[<ffffffff80a01222>] kernel_init_freeable+0x28a/0x304
[<ffffffff808cb1be>] kernel_init+0x1e/0x110
[<ffffffff80003c4e>] ret_from_exception+0x0/0x10
---[ end trace 0000000000000000 ]---

Fixes: 2ca653d ("virtio_net: Stripe queue affinities across cores.")
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Guo Ren <guoren@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@gdampf