Re: [PATCH v2 00/16] Convert FibreChannel bsg code to use bsg-lib
On Wed, Oct 12, 2016 at 05:54:45PM +0200, Steffen Maier wrote: > Hi Johannes, > > On 10/12/2016 03:06 PM, Johannes Thumshirn wrote: > > This series converts the current bsg usage in the FibreChannel drivers over > > to use bsg-lib. SAS will follow once FC is in a good enough shape. > > > > I did take some inspiration from a similar patchset from Mike Christie > > dating back to 2011 but it's not a 1:1 copy. Patch 15/16 is heavily based > > on his series and attribution is given to him in the commit message. > > > > It is currently regression tested on FCoE using the 'fcns' and > > 'fcrls' utilities. I'm still trying to figure out how to test the other > > LLDDs. So any pointer from the respective maintainers are appreciated > > The first thing that comes to mind for zfcp is libzfcphbaapi and simply run > its tools for starters. They issue a few different CT GLS requests. > http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_fcp_api_runappl.html > or > http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_fcp_api_runappl.html > (upstream: > http://www.ibm.com/developerworks/linux/linux390/zfcp-hbaapi.html) I'll give it a try, thanks. zfcp_show was the 1st hit on Google as well, when I was looking for a way to test it. > > Theoretically above tools could be built against libHBAAPI on other > architectures. > Currently I don't have anything handy for ELS requests. > > Maybe there is some common code tool (possibly building directly on BSG > IOCTL) to exercise more code paths? Yes this is something I had in mind as well and it could become handy later on anyways. > > Just as a heads up the result of my example run (need to dig deeper why it > crashed): > > # zfcp_show -n > > Local Port List: > <<>> > > [ 799.640378] Oops: 0038 ilc:3 [#1] [ 799.640387] PREEMPT SMP [ > > 799.640393] > > [ 799.640399] Modules linked in: nf_log_ipv6 xt_pkttype nf_log_ipv4 > > nf_log_common xt_LOG xt_limit ip6t_REJECT nf_reject_ipv6 xt_tcpudp > > nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 > > iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns > > nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables > > xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables ghash_s390 > > prng ecb aes_s390 des_s390 dm_mod des_generic sha512_s390 sha256_s390 > > qeth_l2 sha1_s390 qeth zfcp sha_common ccwgroup qdio autofs4 > > [ 799.640542] CPU: 1 PID: 2210 Comm: zfcp_show Not tainted 4.8.0fcbsg+ #6 > > [ 799.640550] Hardware name: IBM 2964 N96 702 > > (z/VM) > > [ 799.640558] task: 47b60008 task.stack: 62428000 > > [ 799.640567] Krnl PSW : 0404e0018000 001b125c[ 799.640581] > > (__lock_acquire+0x104/0x7d8) > > [ 799.640590] > > [ 799.640599]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 > > PM:0[ 799.640618] RI:0 EA:3 > > [ 799.640621] > > [ 799.640621] Krnl GPRS: 0008 > > 07f40707c004 > > [ 799.640624] > > 0001 > > [ 799.640627] 00355cb4 > > 47b60008 > > [ 799.640630]0300 009b17b0 > > 6242b800 6242b778 > > [ 799.640643] Krnl Code: 001b124c: b9040029lgr > > %r2,%r9 > > [ 799.640648]001b1250: c0e5d6a4brasl > > %r14,1abf98 > > #001b1256: ec28ffad007c cgij > > %r2,0,8,1b11b0 > > [ 799.640659] >001b125c: eb012198006aasi > > 408(%r2,1 > > 001b1262: 5830ba10 l > > %r3,2576(%r11) > > [ 799.640669]001b1266: 5030f0a4st > > %r3,164(%r15) > > 001b126a: c01000e3f9db larl > > %r1,1e30620 > > [ 799.640678]001b1270: e3101012lt > > %r1,0(%r1) > > [ 799.640682] > > [ 799.640684] Call Trace: > > [ 799.640687] ([] 0x) > > [ 799.640691] ([<001b21f4>] lock_acquire+0x30c/0x358) > > [ 799.640699] ([<0099fdae>] > > mutex_lock_interruptible_nested+0x7e/0x4f8) > > [ 799.640717] ([<03ff8047a090>] zfcp_fc_wka_port_get+0x40/0x128 [zfcp]) > > [ 799.640724] ([<03ff8047bd54>] zfcp_fc_exec_bsg_job+0x244/0x2d8 > > [zfcp]) > > [ 799.640732] ([<007c8b1e>] fc_bsg_dispatch+0x20e/0x280) > > [ 799.640739] ([<006dea1a>] bsg_request_fn+0x132/0x1e0) > > [ 799.640746] ([<006b8e0a>] __blk_run_queue+0x52/0x68) > > [ 799.640751] ([<006c549a>] blk_execute_rq_nowait+0xf2/0x110) > > [ 799.640754] ([<006c557a>] blk_execute_rq+0xa2/0x110) > > [ 799.640757] ([<006de0ee>] bsg_ioctl+0x1f6/0x268) > > [ 799.640763]
Re: [PATCH v2 00/16] Convert FibreChannel bsg code to use bsg-lib
On Wed, Oct 12, 2016 at 05:54:45PM +0200, Steffen Maier wrote: > Hi Johannes, > > On 10/12/2016 03:06 PM, Johannes Thumshirn wrote: > > This series converts the current bsg usage in the FibreChannel drivers over > > to use bsg-lib. SAS will follow once FC is in a good enough shape. > > > > I did take some inspiration from a similar patchset from Mike Christie > > dating back to 2011 but it's not a 1:1 copy. Patch 15/16 is heavily based > > on his series and attribution is given to him in the commit message. > > > > It is currently regression tested on FCoE using the 'fcns' and > > 'fcrls' utilities. I'm still trying to figure out how to test the other > > LLDDs. So any pointer from the respective maintainers are appreciated > > The first thing that comes to mind for zfcp is libzfcphbaapi and simply run > its tools for starters. They issue a few different CT GLS requests. > http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_fcp_api_runappl.html > or > http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_fcp_api_runappl.html > (upstream: > http://www.ibm.com/developerworks/linux/linux390/zfcp-hbaapi.html) I'll give it a try, thanks. zfcp_show was the 1st hit on Google as well, when I was looking for a way to test it. > > Theoretically above tools could be built against libHBAAPI on other > architectures. > Currently I don't have anything handy for ELS requests. > > Maybe there is some common code tool (possibly building directly on BSG > IOCTL) to exercise more code paths? Yes this is something I had in mind as well and it could become handy later on anyways. > > Just as a heads up the result of my example run (need to dig deeper why it > crashed): > > # zfcp_show -n > > Local Port List: > <<>> > > [ 799.640378] Oops: 0038 ilc:3 [#1] [ 799.640387] PREEMPT SMP [ > > 799.640393] > > [ 799.640399] Modules linked in: nf_log_ipv6 xt_pkttype nf_log_ipv4 > > nf_log_common xt_LOG xt_limit ip6t_REJECT nf_reject_ipv6 xt_tcpudp > > nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 > > iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns > > nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables > > xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables ghash_s390 > > prng ecb aes_s390 des_s390 dm_mod des_generic sha512_s390 sha256_s390 > > qeth_l2 sha1_s390 qeth zfcp sha_common ccwgroup qdio autofs4 > > [ 799.640542] CPU: 1 PID: 2210 Comm: zfcp_show Not tainted 4.8.0fcbsg+ #6 > > [ 799.640550] Hardware name: IBM 2964 N96 702 > > (z/VM) > > [ 799.640558] task: 47b60008 task.stack: 62428000 > > [ 799.640567] Krnl PSW : 0404e0018000 001b125c[ 799.640581] > > (__lock_acquire+0x104/0x7d8) > > [ 799.640590] > > [ 799.640599]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 > > PM:0[ 799.640618] RI:0 EA:3 > > [ 799.640621] > > [ 799.640621] Krnl GPRS: 0008 > > 07f40707c004 > > [ 799.640624] > > 0001 > > [ 799.640627] 00355cb4 > > 47b60008 > > [ 799.640630]0300 009b17b0 > > 6242b800 6242b778 > > [ 799.640643] Krnl Code: 001b124c: b9040029lgr > > %r2,%r9 > > [ 799.640648]001b1250: c0e5d6a4brasl > > %r14,1abf98 > > #001b1256: ec28ffad007c cgij > > %r2,0,8,1b11b0 > > [ 799.640659] >001b125c: eb012198006aasi > > 408(%r2,1 > > 001b1262: 5830ba10 l > > %r3,2576(%r11) > > [ 799.640669]001b1266: 5030f0a4st > > %r3,164(%r15) > > 001b126a: c01000e3f9db larl > > %r1,1e30620 > > [ 799.640678]001b1270: e3101012lt > > %r1,0(%r1) > > [ 799.640682] > > [ 799.640684] Call Trace: > > [ 799.640687] ([] 0x) > > [ 799.640691] ([<001b21f4>] lock_acquire+0x30c/0x358) > > [ 799.640699] ([<0099fdae>] > > mutex_lock_interruptible_nested+0x7e/0x4f8) > > [ 799.640717] ([<03ff8047a090>] zfcp_fc_wka_port_get+0x40/0x128 [zfcp]) > > [ 799.640724] ([<03ff8047bd54>] zfcp_fc_exec_bsg_job+0x244/0x2d8 > > [zfcp]) > > [ 799.640732] ([<007c8b1e>] fc_bsg_dispatch+0x20e/0x280) > > [ 799.640739] ([<006dea1a>] bsg_request_fn+0x132/0x1e0) > > [ 799.640746] ([<006b8e0a>] __blk_run_queue+0x52/0x68) > > [ 799.640751] ([<006c549a>] blk_execute_rq_nowait+0xf2/0x110) > > [ 799.640754] ([<006c557a>] blk_execute_rq+0xa2/0x110) > > [ 799.640757] ([<006de0ee>] bsg_ioctl+0x1f6/0x268) > > [ 799.640763]
Re: [PATCH v2 00/16] Convert FibreChannel bsg code to use bsg-lib
Hi Johannes, On 10/12/2016 03:06 PM, Johannes Thumshirn wrote: This series converts the current bsg usage in the FibreChannel drivers over to use bsg-lib. SAS will follow once FC is in a good enough shape. I did take some inspiration from a similar patchset from Mike Christie dating back to 2011 but it's not a 1:1 copy. Patch 15/16 is heavily based on his series and attribution is given to him in the commit message. It is currently regression tested on FCoE using the 'fcns' and 'fcrls' utilities. I'm still trying to figure out how to test the other LLDDs. So any pointer from the respective maintainers are appreciated The first thing that comes to mind for zfcp is libzfcphbaapi and simply run its tools for starters. They issue a few different CT GLS requests. http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_fcp_api_runappl.html or http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_fcp_api_runappl.html (upstream: http://www.ibm.com/developerworks/linux/linux390/zfcp-hbaapi.html) Theoretically above tools could be built against libHBAAPI on other architectures. Currently I don't have anything handy for ELS requests. Maybe there is some common code tool (possibly building directly on BSG IOCTL) to exercise more code paths? Just as a heads up the result of my example run (need to dig deeper why it crashed): # zfcp_show -n Local Port List: <<>> [ 799.640378] Oops: 0038 ilc:3 [#1] [ 799.640387] PREEMPT SMP [ 799.640393] [ 799.640399] Modules linked in: nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common xt_LOG xt_limit ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables ghash_s390 prng ecb aes_s390 des_s390 dm_mod des_generic sha512_s390 sha256_s390 qeth_l2 sha1_s390 qeth zfcp sha_common ccwgroup qdio autofs4 [ 799.640542] CPU: 1 PID: 2210 Comm: zfcp_show Not tainted 4.8.0fcbsg+ #6 [ 799.640550] Hardware name: IBM 2964 N96 702 (z/VM) [ 799.640558] task: 47b60008 task.stack: 62428000 [ 799.640567] Krnl PSW : 0404e0018000 001b125c[ 799.640581] (__lock_acquire+0x104/0x7d8) [ 799.640590] [ 799.640599]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0[ 799.640618] RI:0 EA:3 [ 799.640621] [ 799.640621] Krnl GPRS: 0008 07f40707c004 [ 799.640624] 0001 [ 799.640627] 00355cb4 47b60008 [ 799.640630]0300 009b17b0 6242b800 6242b778 [ 799.640643] Krnl Code: 001b124c: b9040029lgr %r2,%r9 [ 799.640648]001b1250: c0e5d6a4brasl %r14,1abf98 #001b1256: ec28ffad007c cgij %r2,0,8,1b11b0 [ 799.640659] >001b125c: eb012198006aasi 408(%r2,1 001b1262: 5830ba10 l %r3,2576(%r11) [ 799.640669]001b1266: 5030f0a4st %r3,164(%r15) 001b126a: c01000e3f9db larl %r1,1e30620 [ 799.640678]001b1270: e3101012lt %r1,0(%r1) [ 799.640682] [ 799.640684] Call Trace: [ 799.640687] ([] 0x) [ 799.640691] ([<001b21f4>] lock_acquire+0x30c/0x358) [ 799.640699] ([<0099fdae>] mutex_lock_interruptible_nested+0x7e/0x4f8) [ 799.640717] ([<03ff8047a090>] zfcp_fc_wka_port_get+0x40/0x128 [zfcp]) [ 799.640724] ([<03ff8047bd54>] zfcp_fc_exec_bsg_job+0x244/0x2d8 [zfcp]) [ 799.640732] ([<007c8b1e>] fc_bsg_dispatch+0x20e/0x280) [ 799.640739] ([<006dea1a>] bsg_request_fn+0x132/0x1e0) [ 799.640746] ([<006b8e0a>] __blk_run_queue+0x52/0x68) [ 799.640751] ([<006c549a>] blk_execute_rq_nowait+0xf2/0x110) [ 799.640754] ([<006c557a>] blk_execute_rq+0xa2/0x110) [ 799.640757] ([<006de0ee>] bsg_ioctl+0x1f6/0x268) [ 799.640763] ([<0036ca20>] do_vfs_ioctl+0x680/0x6d8) [ 799.640767] ([<0036caf4>] SyS_ioctl+0x7c/0xb0) [ 799.640771] ([<009a50de>] system_call+0xd6/0x270) [ 799.640774] INFO: lockdep is turned off. [ 799.640776] Last Breaking-Event-Address: [ 799.640779] [<001b1244>] __lock_acquire+0xec/0x7d8 [ 799.640782] [ 799.640785] Kernel panic - not syncing: Fatal exception: panic_on_oops although the LLDD changes are purely mechanical. All they do is change from 'struct fc_bsg_job' to 'struct bsg_job' and corresponding changes in order to get the series bisectable.
Re: [PATCH v2 00/16] Convert FibreChannel bsg code to use bsg-lib
Hi Johannes, On 10/12/2016 03:06 PM, Johannes Thumshirn wrote: This series converts the current bsg usage in the FibreChannel drivers over to use bsg-lib. SAS will follow once FC is in a good enough shape. I did take some inspiration from a similar patchset from Mike Christie dating back to 2011 but it's not a 1:1 copy. Patch 15/16 is heavily based on his series and attribution is given to him in the commit message. It is currently regression tested on FCoE using the 'fcns' and 'fcrls' utilities. I'm still trying to figure out how to test the other LLDDs. So any pointer from the respective maintainers are appreciated The first thing that comes to mind for zfcp is libzfcphbaapi and simply run its tools for starters. They issue a few different CT GLS requests. http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_fcp_api_runappl.html or http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_fcp_api_runappl.html (upstream: http://www.ibm.com/developerworks/linux/linux390/zfcp-hbaapi.html) Theoretically above tools could be built against libHBAAPI on other architectures. Currently I don't have anything handy for ELS requests. Maybe there is some common code tool (possibly building directly on BSG IOCTL) to exercise more code paths? Just as a heads up the result of my example run (need to dig deeper why it crashed): # zfcp_show -n Local Port List: <<>> [ 799.640378] Oops: 0038 ilc:3 [#1] [ 799.640387] PREEMPT SMP [ 799.640393] [ 799.640399] Modules linked in: nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common xt_LOG xt_limit ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables ghash_s390 prng ecb aes_s390 des_s390 dm_mod des_generic sha512_s390 sha256_s390 qeth_l2 sha1_s390 qeth zfcp sha_common ccwgroup qdio autofs4 [ 799.640542] CPU: 1 PID: 2210 Comm: zfcp_show Not tainted 4.8.0fcbsg+ #6 [ 799.640550] Hardware name: IBM 2964 N96 702 (z/VM) [ 799.640558] task: 47b60008 task.stack: 62428000 [ 799.640567] Krnl PSW : 0404e0018000 001b125c[ 799.640581] (__lock_acquire+0x104/0x7d8) [ 799.640590] [ 799.640599]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0[ 799.640618] RI:0 EA:3 [ 799.640621] [ 799.640621] Krnl GPRS: 0008 07f40707c004 [ 799.640624] 0001 [ 799.640627] 00355cb4 47b60008 [ 799.640630]0300 009b17b0 6242b800 6242b778 [ 799.640643] Krnl Code: 001b124c: b9040029lgr %r2,%r9 [ 799.640648]001b1250: c0e5d6a4brasl %r14,1abf98 #001b1256: ec28ffad007c cgij %r2,0,8,1b11b0 [ 799.640659] >001b125c: eb012198006aasi 408(%r2,1 001b1262: 5830ba10 l %r3,2576(%r11) [ 799.640669]001b1266: 5030f0a4st %r3,164(%r15) 001b126a: c01000e3f9db larl %r1,1e30620 [ 799.640678]001b1270: e3101012lt %r1,0(%r1) [ 799.640682] [ 799.640684] Call Trace: [ 799.640687] ([] 0x) [ 799.640691] ([<001b21f4>] lock_acquire+0x30c/0x358) [ 799.640699] ([<0099fdae>] mutex_lock_interruptible_nested+0x7e/0x4f8) [ 799.640717] ([<03ff8047a090>] zfcp_fc_wka_port_get+0x40/0x128 [zfcp]) [ 799.640724] ([<03ff8047bd54>] zfcp_fc_exec_bsg_job+0x244/0x2d8 [zfcp]) [ 799.640732] ([<007c8b1e>] fc_bsg_dispatch+0x20e/0x280) [ 799.640739] ([<006dea1a>] bsg_request_fn+0x132/0x1e0) [ 799.640746] ([<006b8e0a>] __blk_run_queue+0x52/0x68) [ 799.640751] ([<006c549a>] blk_execute_rq_nowait+0xf2/0x110) [ 799.640754] ([<006c557a>] blk_execute_rq+0xa2/0x110) [ 799.640757] ([<006de0ee>] bsg_ioctl+0x1f6/0x268) [ 799.640763] ([<0036ca20>] do_vfs_ioctl+0x680/0x6d8) [ 799.640767] ([<0036caf4>] SyS_ioctl+0x7c/0xb0) [ 799.640771] ([<009a50de>] system_call+0xd6/0x270) [ 799.640774] INFO: lockdep is turned off. [ 799.640776] Last Breaking-Event-Address: [ 799.640779] [<001b1244>] __lock_acquire+0xec/0x7d8 [ 799.640782] [ 799.640785] Kernel panic - not syncing: Fatal exception: panic_on_oops although the LLDD changes are purely mechanical. All they do is change from 'struct fc_bsg_job' to 'struct bsg_job' and corresponding changes in order to get the series bisectable.
