Bug 204937

Kernel panic when using EIP97 (mtk-crypto.ko) hardware crypto accelerator on Banana PI R2. I have a code which encrypts the data with AF_ALG and libaio. It works just fine with smaller packet size (ok for 4096 bytes), but large packets, lead to kernel error. Attaching the stacktrace:
>
> [   80.421216] ------------[ cut here ]------------
> [   80.425817] WARNING: CPU: 3 PID: 0 at lib/percpu-refcount.c:155
> percpu_ref_switch_to_atomic_rcu+0xc8/0x19c
> [   80.435415] percpu ref (free_ioctx_reqs) <= 0 (0) after switching to
> atomic
> [   80.435418] Modules linked in: pppoe ppp_async pppox ppp_generic
> nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211
> iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state
> xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS
> xt_REDIRECT xt_LOG xt_FLOWOFFLOAD slhc nf_reject_ipv4 nf_nat_redirect
> nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4
> nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4
> nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables
> crc_ccitt compat cryptodev ip6t_REJECT nf_reject_ipv6 nf_log_ipv6
> nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables tun
> algif_skcipher algif_hash af_alg ghash_generic gf128mul gcm authenc leds_gpio
> gpio_button_hotplug [last unloaded: tpm]
> [   80.513750] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.14.145 #0
> [   80.519789] Hardware name: Mediatek Cortex-A7 (Device Tree)
> [   80.525329] [<c010e99c>] (unwind_backtrace) from [<c010aa78>]
> (show_stack+0x10/0x14)
> [   80.533014] [<c010aa78>] (show_stack) from [<c05369dc>]
> (dump_stack+0x78/0x8c)
> [   80.540181] [<c05369dc>] (dump_stack) from [<c0116f00>]
> (__warn+0xe4/0x100)
> [   80.547087] [<c0116f00>] (__warn) from [<c0116f54>]
> (warn_slowpath_fmt+0x38/0x48)
> [   80.554510] [<c0116f54>] (warn_slowpath_fmt) from [<c02d79d4>]
> (percpu_ref_switch_to_atomic_rcu+0xc8/0x19c)
> [   80.564178] [<c02d79d4>] (percpu_ref_switch_to_atomic_rcu) from
> [<c0163658>] (rcu_process_callbacks+0x308/0x48c)
> [   80.574272] [<c0163658>] (rcu_process_callbacks) from [<c010155c>]
> (__do_softirq+0xe4/0x250)
> [   80.582643] [<c010155c>] (__do_softirq) from [<c011babc>]
> (irq_exit+0xac/0xf4)
> [   80.589807] [<c011babc>] (irq_exit) from [<c015591c>]
> (__handle_domain_irq+0xbc/0xe4)
> [   80.597575] [<c015591c>] (__handle_domain_irq) from [<c0101440>]
> (gic_handle_irq+0x5c/0x90)
> [   80.605857] [<c0101440>] (gic_handle_irq) from [<c010b64c>]
> (__irq_svc+0x6c/0xa8)
> [   80.613275] Exception stack(0xef075f88 to 0xef075fd0)
> [   80.618284] 5f80:                   00000003 c06bfd7c 2d9fc000 c0113be0
> ffffe000 c1e03c74
> [   80.626394] 5fa0: c1e03c28 c1e2ac90 8000406a 410fc073 00000000 00000000
> 00001668 ef075fd8
> [   80.634504] 5fc0: c01081a8 c01081ac 60000013 ffffffff
> [   80.639514] [<c010b64c>] (__irq_svc) from [<c01081ac>]
> (arch_cpu_idle+0x34/0x38)
> [   80.646851] [<c01081ac>] (arch_cpu_idle) from [<c014acb0>]
> (do_idle+0xa8/0x11c)
> [   80.654102] [<c014acb0>] (do_idle) from [<c014afa8>]
> (cpu_startup_entry+0x18/0x1c)
> [   80.661610] [<c014afa8>] (cpu_startup_entry) from [<8010176c>]
> (0x8010176c)
> [   80.668525] ---[ end trace 0097fd000901180a ]---