Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Kalle Valo <kvalo@kernel.org>
To:     Ping-Ke Shih <pkshih@realtek.com>
Cc:     <tony0620emma@gmail.com>, <linux-wireless@vger.kernel.org>,
        <megi@xff.cz>, <phhuang@realtek.com>
Subject: Re: [PATCH] rtw88: add a work to correct atomic scheduling warning of ::set_tim
References: <20220526051251.281905-1-pkshih@realtek.com>
Date:   Fri, 27 May 2022 09:29:13 +0300
In-Reply-To: <20220526051251.281905-1-pkshih@realtek.com> (Ping-Ke Shih's
        message of "Thu, 26 May 2022 13:12:51 +0800")
Message-ID: <871qwfwksm.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Ping-Ke Shih <pkshih@realtek.com> writes:

> The set_tim is supposed to be atomic, but we should download beacon
> context to firmware with a mutex lock. To avoid warning, do the thing in
> another work.
>
> BUG: scheduling while atomic: swapper/1/0/0x00000700
> Modules linked in:
> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W         5.18.0-rc7-0070=
3-g33b5ee09a0c1 #4
> Hardware name: Pine64 RK3566 Quartz64-A Board (DT)
> Call trace:
>  dump_backtrace.part.0+0xc4/0xd0
>  show_stack+0x14/0x60
>  dump_stack_lvl+0x60/0x78
>  dump_stack+0x14/0x2c
>  __schedule_bug+0x5c/0x70
>  __schedule+0x5c4/0x630
>  schedule+0x44/0xb0
>  schedule_preempt_disabled+0xc/0x14
>  __mutex_lock.constprop.0+0x538/0x56c
>  __mutex_lock_slowpath+0x10/0x20
>  mutex_lock+0x54/0x60
>  rtw_ops_set_tim+0x20/0x40
>  __sta_info_recalc_tim+0x150/0x250
>  sta_info_recalc_tim+0x10/0x20
>  invoke_tx_handlers_early+0x4e4/0x5c0
>  ieee80211_tx+0x78/0x110
>  ieee80211_xmit+0x94/0xc0
>  __ieee80211_subif_start_xmit+0x818/0xd20
>  ieee80211_subif_start_xmit+0x44/0x2d0
>  dev_hard_start_xmit+0xd0/0x150
>  __dev_queue_xmit+0x250/0xb30
>  dev_queue_xmit+0x10/0x20
>  br_dev_queue_push_xmit+0x94/0x174
>  br_forward_finish+0x90/0xa0
>  __br_forward+0xc0/0x13c
>  br_forward+0x108/0x134
>  br_dev_xmit+0x1cc/0x3a4
>  dev_hard_start_xmit+0xd0/0x150
>  __dev_queue_xmit+0x250/0xb30
>  dev_queue_xmit+0x10/0x20
>  arp_xmit+0x6c/0x7c
>  arp_send_dst+0x8c/0xc0
>  arp_solicit+0xd4/0x1e0
>  neigh_probe+0x58/0xa0
>  neigh_timer_handler+0x27c/0x380
>  call_timer_fn.constprop.0+0x20/0x80
>  __run_timers.part.0+0x230/0x280
>  run_timer_softirq+0x38/0x70
>  _stext+0x104/0x278
>  __irq_exit_rcu+0xa4/0xdc
>  irq_exit_rcu+0xc/0x14
>  el1_interrupt+0x34/0x50
>  el1h_64_irq_handler+0x14/0x20
>  el1h_64_irq+0x64/0x68
>  arch_cpu_idle+0x14/0x20
>  do_idle+0x208/0x290
>  cpu_startup_entry+0x20/0x30
>  secondary_start_kernel+0x130/0x144
>  __secondary_switched+0x54/0x58
>
> Fixes: f2217968ffda ("rtw88: Add update beacon flow for AP mode")
> Reported-by: Ond=C5=99ej Jirman <megi@xff.cz>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Should I queue this to v5.19 (ie. take to wireles tree)?

--=20
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatc=
hes