Re: [PATCH v3] ath10k: add flag to protect napi operation to avoid dead loop hang

2020-12-09 Thread Kalle Valo
Krishna Chaitanya writes: > On Fri, Aug 28, 2020 at 5:53 PM Wen Gong wrote: >> >> It happened "Kernel panic - not syncing: hung_task: blocked tasks" when >> test simulate crash and ifconfig down/rmmod meanwhile. (editing out hundreds of lines of unnecessary text, please edit your quotes) >

Re: [PATCH v3] ath10k: add flag to protect napi operation to avoid dead loop hang

2020-12-09 Thread Kalle Valo
Wen Gong writes: > On 2020-09-08 00:22, Kalle Valo wrote: > >> Just like with the recent firmware restart patch, isn't >> ar->napi_enabled >> racy? Wouldn't test_and_set_bit() and test_and_clear_bit() be safer? >> >> Or are we holding a lock? But then that should be documented with >>

[ath6kl:ath-next] BUILD SUCCESS 8a71f34bb251d59e9d577df196c450cec14773ff

2020-12-09 Thread kernel test robot
defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201209 i386

[ath6kl:ath-qca] BUILD SUCCESS c0e22051b47e39d168f16de556d10bde1db52263

2020-12-09 Thread kernel test robot
allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201209 i386 randconfig-a005-20201209

Re: [PATCH v3] ath10k: add flag to protect napi operation to avoid dead loop hang

2020-12-09 Thread Ben Greear
On 12/9/20 1:24 AM, Kalle Valo wrote: Wen Gong writes: On 2020-09-08 00:22, Kalle Valo wrote: Just like with the recent firmware restart patch, isn't ar->napi_enabled racy? Wouldn't test_and_set_bit() and test_and_clear_bit() be safer? Or are we holding a lock? But then that should be

[ath6kl:master] BUILD SUCCESS a2e239540f0bd7bf6b8cd365af587e38f8fd329e

2020-12-09 Thread kernel test robot
allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201209 i386 randconfig-a005-20201209 i386 randconfig-a001-20201209

[ath6kl:pending] BUILD SUCCESS e0a466d296bd862080f7796b41349f9f586272c9

2020-12-09 Thread kernel test robot
allmodconfig powerpc allnoconfig i386 randconfig-a004-20201209 i386 randconfig-a005-20201209 i386 randconfig-a001-20201209 i386 randconfig-a002-20201209 i386 randconfig-a006

[ath6kl:master-pending] BUILD SUCCESS f540bbc67bb7f02c8cefdf37e90ef4d9259550d9

2020-12-09 Thread kernel test robot
allmodconfig powerpc allnoconfig i386 randconfig-a004-20201209 i386 randconfig-a005-20201209 i386 randconfig-a001-20201209 i386 randconfig-a002-20201209 i386 randconfig

Re: [PATCH v3] ath10k: add flag to protect napi operation to avoid dead loop hang

2020-12-09 Thread Wen Gong
On 2020-12-09 17:24, Kalle Valo wrote: Wen Gong writes: On 2020-09-08 00:22, Kalle Valo wrote: Just like with the recent firmware restart patch, isn't ar->napi_enabled racy? Wouldn't test_and_set_bit() and test_and_clear_bit() be safer? Or are we holding a lock? But then that should be

Re: [PATCH v3] ath10k: add flag to protect napi operation to avoid dead loop hang

2020-12-09 Thread Wen Gong
On 2020-12-09 23:00, Ben Greear wrote: On 12/9/20 1:24 AM, Kalle Valo wrote: Wen Gong writes: On 2020-09-08 00:22, Kalle Valo wrote: Just like with the recent firmware restart patch, isn't ar->napi_enabled racy? Wouldn't test_and_set_bit() and test_and_clear_bit() be safer? Or are we