[PATCH] kdump-module-setup.sh: do not handle ibft in kdump module

[WANG Chao]

1st kernel uses ip=ibft and rd.iscsi.firmware to log in ibft lun. In 2nd
kernel, ibft lun can be logged in automatically, because 2nd kernel
inherit 1st kernel cmdline.

Currently kdump will configure netroot=iscsi:xxx if we find iscsi lun
being used. In case of ibft, ip=ibft and rd.iscsi.firmware is enough for
dracut to be aware of, otherwise netroot=iscsi:xxx will only confuse
dracut and fail to log in ibft lun.

So in kdump module, we should avoid handling iscsi lun if ibft.

Signed-off-by: WANG Chao <chaowang(a)redhat.com&gt;
---
 dracut-module-setup.sh | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index 517099c..252d17a 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -268,6 +268,16 @@ kdump_install_conf() {
     rm -f /tmp/$$-kdump.conf
 }
 
+kdump_is_ibft() {
+    local path=$1
+    local tgt_name fw_tgt_name
+
+    tgt_name=$(kdump_iscsi_get_rec_val "$path" "node.name")
+    fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1 ==
"node.name" {print $3}')
+
+    [ -n "$fw_tgt_name" ] && strstr "$fw_tgt_name"
"$tgt_name"
+}
+
 kdump_iscsi_get_rec_val() {
 
     local result
@@ -323,6 +333,11 @@ kdump_setup_iscsi_device() {
         return 1
     fi
 
+    if kdump_is_ibft ${path}; then
+        dinfo "${path} is ibft, skip"
+        return 0
+    fi
+
     tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
     tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn\[0\].address")
 
-- 
1.8.3.1

[WANG Chao]

On 09/05/13 at 12:47am, WANG Chao wrote:
>  1st kernel uses ip=ibft and rd.iscsi.firmware to log in ibft lun. In
> 2nd
>  kernel, ibft lun can be logged in automatically, because 2nd kernel
>  inherit 1st kernel cmdline.
>  
>  Currently kdump will configure netroot=iscsi:xxx if we find iscsi lun
>  being used. In case of ibft, ip=ibft and rd.iscsi.firmware is enough for
>  dracut to be aware of, otherwise netroot=iscsi:xxx will only confuse
>  dracut and fail to log in ibft lun.
>  
>  So in kdump module, we should avoid handling iscsi lun if ibft.
>  
>  Signed-off-by: WANG Chao <chaowang(a)redhat.com&gt; 
CCing Vivek, Bao, Dave

Thanks,
WANG Chao

>  ---
>   dracut-module-setup.sh | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>  
>  diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  index 517099c..252d17a 100755
>  --- a/dracut-module-setup.sh
>  +++ b/dracut-module-setup.sh
>  @@ -268,6 +268,16 @@ kdump_install_conf() {
>       rm -f /tmp/$$-kdump.conf
>   }
>   
>  +kdump_is_ibft() {
>  +    local path=$1
>  +    local tgt_name fw_tgt_name
>  +
>  +    tgt_name=$(kdump_iscsi_get_rec_val "$path" "node.name")
>  +    fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1 ==
> "node.name" {print $3}')
>  +
>  +    [ -n "$fw_tgt_name" ] && strstr "$fw_tgt_name"
> "$tgt_name"
>  +}
>  +
>   kdump_iscsi_get_rec_val() {
>   
>       local result
>  @@ -323,6 +333,11 @@ kdump_setup_iscsi_device() {
>           return 1
>       fi
>   
>  +    if kdump_is_ibft ${path}; then
>  +        dinfo "${path} is ibft, skip"
>  +        return 0
>  +    fi
>  +
>       tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>       tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn\[0\].address")
>   
>  -- 
>  1.8.3.1
>

[Dave Young]

On 09/05/13 at 12:47am, WANG Chao wrote:
>  1st kernel uses ip=ibft and rd.iscsi.firmware to log in ibft lun. In
> 2nd
>  kernel, ibft lun can be logged in automatically, because 2nd kernel
>  inherit 1st kernel cmdline.
>  
>  Currently kdump will configure netroot=iscsi:xxx if we find iscsi lun
>  being used. In case of ibft, ip=ibft and rd.iscsi.firmware is enough for
>  dracut to be aware of, otherwise netroot=iscsi:xxx will only confuse
>  dracut and fail to log in ibft lun.
>  
>  So in kdump module, we should avoid handling iscsi lun if ibft. 
Hi, Vivek
Could you review this patch? does it make sense?

>  
>  Signed-off-by: WANG Chao <chaowang(a)redhat.com&gt;
>  ---
>   dracut-module-setup.sh | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>  
>  diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  index 517099c..252d17a 100755
>  --- a/dracut-module-setup.sh
>  +++ b/dracut-module-setup.sh
>  @@ -268,6 +268,16 @@ kdump_install_conf() {
>       rm -f /tmp/$$-kdump.conf
>   }
>   
>  +kdump_is_ibft() {
>  +    local path=$1
>  +    local tgt_name fw_tgt_name
>  +
>  +    tgt_name=$(kdump_iscsi_get_rec_val "$path" "node.name")
>  +    fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1 ==
> "node.name" {print $3}')
>  +
>  +    [ -n "$fw_tgt_name" ] && strstr "$fw_tgt_name"
> "$tgt_name"
>  +}
>  +
>   kdump_iscsi_get_rec_val() {
>   
>       local result
>  @@ -323,6 +333,11 @@ kdump_setup_iscsi_device() {
>           return 1
>       fi
>   
>  +    if kdump_is_ibft ${path}; then
>  +        dinfo "${path} is ibft, skip"
>  +        return 0
>  +    fi
>  +
>       tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>       tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn\[0\].address")
>   
>  -- 
>  1.8.3.1
>  
>  _______________________________________________
>  kexec mailing list
>  kexec(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/mailman/listinfo/kexec

[Vivek Goyal]

On Thu, Sep 05, 2013 at 12:47:22AM +0800, WANG Chao wrote:
>  1st kernel uses ip=ibft and rd.iscsi.firmware to log in ibft lun. In
> 2nd
>  kernel, ibft lun can be logged in automatically, because 2nd kernel
>  inherit 1st kernel cmdline.
>  
>  Currently kdump will configure netroot=iscsi:xxx if we find iscsi lun
>  being used. In case of ibft, ip=ibft and rd.iscsi.firmware is enough for
>  dracut to be aware of, otherwise netroot=iscsi:xxx will only confuse
>  dracut and fail to log in ibft lun.
>  
>  So in kdump module, we should avoid handling iscsi lun if ibft.
>  
>  Signed-off-by: WANG Chao <chaowang(a)redhat.com&gt;
>  ---
>   dracut-module-setup.sh | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>  
>  diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  index 517099c..252d17a 100755
>  --- a/dracut-module-setup.sh
>  +++ b/dracut-module-setup.sh
>  @@ -268,6 +268,16 @@ kdump_install_conf() {
>       rm -f /tmp/$$-kdump.conf
>   }
>   
>  +kdump_is_ibft() {
>  +    local path=$1
>  +    local tgt_name fw_tgt_name
>  +
>  +    tgt_name=$(kdump_iscsi_get_rec_val "$path" "node.name")
>  +    fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1 ==
> "node.name" {print $3}')
>  +
>  +    [ -n "$fw_tgt_name" ] && strstr "$fw_tgt_name"
> "$tgt_name"
>  +}
>  +
>   kdump_iscsi_get_rec_val() {
>   
>       local result
>  @@ -323,6 +333,11 @@ kdump_setup_iscsi_device() {
>           return 1
>       fi
>   
>  +    if kdump_is_ibft ${path}; then
>  +        dinfo "${path} is ibft, skip" 
So this is relying on the fact that ip=ibft and rd.iscsi.firmware has
been passed on command line. Is it always the case in first kernel? Can't
I bring up ibft luns from user space later?

If yes, it might be better to always append ip=ibft and rd.iscsi.firmware
to command line option.

Thanks
Vivek

[WANG Chao]

On 09/23/13 at 03:47pm, Vivek Goyal wrote:
>  On Thu, Sep 05, 2013 at 12:47:22AM +0800, WANG Chao wrote:
>  > 1st kernel uses ip=ibft and rd.iscsi.firmware to log in ibft lun. In 2nd
>  > kernel, ibft lun can be logged in automatically, because 2nd kernel
>  > inherit 1st kernel cmdline.
>  > 
>  > Currently kdump will configure netroot=iscsi:xxx if we find iscsi lun
>  > being used. In case of ibft, ip=ibft and rd.iscsi.firmware is enough for
>  > dracut to be aware of, otherwise netroot=iscsi:xxx will only confuse
>  > dracut and fail to log in ibft lun.
>  > 
>  > So in kdump module, we should avoid handling iscsi lun if ibft.
>  > 
>  > Signed-off-by: WANG Chao <chaowang(a)redhat.com&gt;
>  > ---
>  >  dracut-module-setup.sh | 15 +++++++++++++++
>  >  1 file changed, 15 insertions(+)
>  > 
>  > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  > index 517099c..252d17a 100755
>  > --- a/dracut-module-setup.sh
>  > +++ b/dracut-module-setup.sh
>  > @@ -268,6 +268,16 @@ kdump_install_conf() {
>  >      rm -f /tmp/$$-kdump.conf
>  >  }
>  >  
>  > +kdump_is_ibft() {
>  > +    local path=$1
>  > +    local tgt_name fw_tgt_name
>  > +
>  > +    tgt_name=$(kdump_iscsi_get_rec_val "$path" "node.name")
>  > +    fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1 ==
> "node.name" {print $3}')
>  > +
>  > +    [ -n "$fw_tgt_name" ] && strstr "$fw_tgt_name"
> "$tgt_name"
>  > +}
>  > +
>  >  kdump_iscsi_get_rec_val() {
>  >  
>  >      local result
>  > @@ -323,6 +333,11 @@ kdump_setup_iscsi_device() {
>  >          return 1
>  >      fi
>  >  
>  > +    if kdump_is_ibft ${path}; then
>  > +        dinfo "${path} is ibft, skip"
>  
>  So this is relying on the fact that ip=ibft and rd.iscsi.firmware has
>  been passed on command line. Is it always the case in first kernel? 
ip=ibft and rd.iscsi.firmware will be appended to cmdline automatically
after installation. Because both of the cmdline args are *required* to
boot an ibft box.

If users want to use ibft, they must have both ip=ibft and
rd.iscsi.firmware in cmdline. I don't know if dracut or anaconda will
change about it, but for now it's true.

>   Can't I bring up ibft luns from user space later? 
You don't have to manually do this. ibft luns will be brought up in
initrd.

>  If yes, it might be better to always append ip=ibft and
> rd.iscsi.firmware
>  to command line option. 
If 1st kernel uses ibft, ip=ibft and rd.iscsi.firmware are already there
in cmdline.

If 1st kernel doesn't use ibft, I don't see a reason for ibft to be used
in 2nd kernel.

Providing duplicated ip=ibft might cause some unexpected behavior of
dracut. I didn't test it. I'm not sure wether it's a good idea or not.
But if you have strong reason or insist to do this, I'm fine with this.

Thanks
WANG Chao

[Vivek Goyal]

On Tue, Sep 24, 2013 at 01:09:30PM +0800, WANG Chao wrote:
>  On 09/23/13 at 03:47pm, Vivek Goyal wrote:
>  > On Thu, Sep 05, 2013 at 12:47:22AM +0800, WANG Chao wrote:
>  > > 1st kernel uses ip=ibft and rd.iscsi.firmware to log in ibft lun. In 2nd
>  > > kernel, ibft lun can be logged in automatically, because 2nd kernel
>  > > inherit 1st kernel cmdline.
>  > > 
>  > > Currently kdump will configure netroot=iscsi:xxx if we find iscsi lun
>  > > being used. In case of ibft, ip=ibft and rd.iscsi.firmware is enough for
>  > > dracut to be aware of, otherwise netroot=iscsi:xxx will only confuse
>  > > dracut and fail to log in ibft lun.
>  > > 
>  > > So in kdump module, we should avoid handling iscsi lun if ibft.
>  > > 
>  > > Signed-off-by: WANG Chao <chaowang(a)redhat.com&gt;
>  > > ---
>  > >  dracut-module-setup.sh | 15 +++++++++++++++
>  > >  1 file changed, 15 insertions(+)
>  > > 
>  > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  > > index 517099c..252d17a 100755
>  > > --- a/dracut-module-setup.sh
>  > > +++ b/dracut-module-setup.sh
>  > > @@ -268,6 +268,16 @@ kdump_install_conf() {
>  > >      rm -f /tmp/$$-kdump.conf
>  > >  }
>  > >  
>  > > +kdump_is_ibft() {
>  > > +    local path=$1
>  > > +    local tgt_name fw_tgt_name
>  > > +
>  > > +    tgt_name=$(kdump_iscsi_get_rec_val "$path"
> "node.name")
>  > > +    fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1 ==
> "node.name" {print $3}')
>  > > +
>  > > +    [ -n "$fw_tgt_name" ] && strstr "$fw_tgt_name"
> "$tgt_name"
>  > > +}
>  > > +
>  > >  kdump_iscsi_get_rec_val() {
>  > >  
>  > >      local result
>  > > @@ -323,6 +333,11 @@ kdump_setup_iscsi_device() {
>  > >          return 1
>  > >      fi
>  > >  
>  > > +    if kdump_is_ibft ${path}; then
>  > > +        dinfo "${path} is ibft, skip"
>  > 
>  > So this is relying on the fact that ip=ibft and rd.iscsi.firmware has
>  > been passed on command line. Is it always the case in first kernel?
>  
>  ip=ibft and rd.iscsi.firmware will be appended to cmdline automatically
>  after installation. Because both of the cmdline args are *required* to
>  boot an ibft box. 
Will it not be the case only if root was on a lun as seen by ibft. What
if I have another network card in the system where I am doing regular
software iscsi and that's where my root is. Or my root is on local disk
but I have some iscsi luns exported using ibft and my dump destination
is an ibft lun?

>  
>  If users want to use ibft, they must have both ip=ibft and
>  rd.iscsi.firmware in cmdline. I don't know if dracut or anaconda will
>  change about it, but for now it's true. 
So you are saying that even if root is not on ibft lun, dracut will
bring up ibft luns? Does not sound right to me. Have you tested it?

>  
>  >  Can't I bring up ibft luns from user space later?
>  
>  You don't have to manually do this. ibft luns will be brought up in
>  initrd. 
Only if root is on ibft lun?

>  
>  > If yes, it might be better to always append ip=ibft and rd.iscsi.firmware
>  > to command line option.
>  
>  If 1st kernel uses ibft, ip=ibft and rd.iscsi.firmware are already there
>  in cmdline.
>  
>  If 1st kernel doesn't use ibft, I don't see a reason for ibft to be used
>  in 2nd kernel.
>  
>  Providing duplicated ip=ibft might cause some unexpected behavior of
>  dracut. I didn't test it. I'm not sure wether it's a good idea or not.
>  But if you have strong reason or insist to do this, I'm fine with this. 
You can write a function which appends an option to command line only
if it is not present already.

Thanks
Vivek

[Vivek Goyal]

On Tue, Sep 24, 2013 at 09:43:45AM -0400, Vivek Goyal wrote:

[..]
>  > > > +kdump_is_ibft() { 
A better name might be "target_is_ibft_lun()"

>  > > > +    local path=$1
>  > > > +    local tgt_name fw_tgt_name
>  > > > +
>  > > > +    tgt_name=$(kdump_iscsi_get_rec_val "$path"
> "node.name")
>  > > > +    fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1 ==
> "node.name" {print $3}')
>  > > > +
>  > > > +    [ -n "$fw_tgt_name" ] && strstr
> "$fw_tgt_name" "$tgt_name" 
I vaguely remember that one problem with ibft in the past was that one
could not tell reliably whether a lun came from ibft configuration or
not.

So how does above work. Can you give an actual example. 

Is this generic enough to work on wide variety of iscsi ibft
configurations? So after this, should we start claiming supporting iscsi
using ibft as kdump target?

Thanks
Vivek

[WANG Chao]

On 09/24/13 at 09:43am, Vivek Goyal wrote:
>  On Tue, Sep 24, 2013 at 01:09:30PM +0800, WANG Chao wrote:
>  > On 09/23/13 at 03:47pm, Vivek Goyal wrote:
>  > > On Thu, Sep 05, 2013 at 12:47:22AM +0800, WANG Chao wrote:
>  > > > 1st kernel uses ip=ibft and rd.iscsi.firmware to log in ibft lun. In 2nd
>  > > > kernel, ibft lun can be logged in automatically, because 2nd kernel
>  > > > inherit 1st kernel cmdline.
>  > > > 
>  > > > Currently kdump will configure netroot=iscsi:xxx if we find iscsi lun
>  > > > being used. In case of ibft, ip=ibft and rd.iscsi.firmware is enough for
>  > > > dracut to be aware of, otherwise netroot=iscsi:xxx will only confuse
>  > > > dracut and fail to log in ibft lun.
>  > > > 
>  > > > So in kdump module, we should avoid handling iscsi lun if ibft.
>  > > > 
>  > > > Signed-off-by: WANG Chao <chaowang(a)redhat.com&gt;
>  > > > ---
>  > > >  dracut-module-setup.sh | 15 +++++++++++++++
>  > > >  1 file changed, 15 insertions(+)
>  > > > 
>  > > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  > > > index 517099c..252d17a 100755
>  > > > --- a/dracut-module-setup.sh
>  > > > +++ b/dracut-module-setup.sh
>  > > > @@ -268,6 +268,16 @@ kdump_install_conf() {
>  > > >      rm -f /tmp/$$-kdump.conf
>  > > >  }
>  > > >  
>  > > > +kdump_is_ibft() {
>  > > > +    local path=$1
>  > > > +    local tgt_name fw_tgt_name
>  > > > +
>  > > > +    tgt_name=$(kdump_iscsi_get_rec_val "$path"
> "node.name")
>  > > > +    fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1 ==
> "node.name" {print $3}')
>  > > > +
>  > > > +    [ -n "$fw_tgt_name" ] && strstr
> "$fw_tgt_name" "$tgt_name"
>  > > > +}
>  > > > +
>  > > >  kdump_iscsi_get_rec_val() {
>  > > >  
>  > > >      local result
>  > > > @@ -323,6 +333,11 @@ kdump_setup_iscsi_device() {
>  > > >          return 1
>  > > >      fi
>  > > >  
>  > > > +    if kdump_is_ibft ${path}; then
>  > > > +        dinfo "${path} is ibft, skip"
>  > > 
>  > > So this is relying on the fact that ip=ibft and rd.iscsi.firmware has
>  > > been passed on command line. Is it always the case in first kernel?
>  > 
>  > ip=ibft and rd.iscsi.firmware will be appended to cmdline automatically
>  > after installation. Because both of the cmdline args are *required* to
>  > boot an ibft box.
>  
>  Will it not be the case only if root was on a lun as seen by ibft. What
>  if I have another network card in the system where I am doing regular
>  software iscsi and that's where my root is. Or my root is on local disk
>  but I have some iscsi luns exported using ibft and my dump destination
>  is an ibft lun? 
I'm afraid yes. It's the case if root is on lun seen by ibft. I haven't
thought about these complicated you mentioned above.

I think for ibft, we have several combinations:
1. root fs is ibft
2. /boot is ibft, / is sw-iscsi
3. root fs is local, other mount point is ibft

My patch only handles the 1st case.

For the 2nd case, in order to mount /boot, "ip=ibft rd.iscsi.firmware"
has to be in cmdline. So we also need these two args in 2nd kernel
cmdline.

For the 3rd case, 1st kernel cmdline will not have "ip=ibft
rd.iscsi.firmware". To login ibft lun in 2nd kernel, we need to append
these two args to cmdline when generating kdump initrd.

>  
>  > 
>  > If users want to use ibft, they must have both ip=ibft and
>  > rd.iscsi.firmware in cmdline. I don't know if dracut or anaconda will
>  > change about it, but for now it's true.
>  
>  So you are saying that even if root is not on ibft lun, dracut will
>  bring up ibft luns? Does not sound right to me. Have you tested it? 
In my previous email, by "ibft", I really meant "root fs on a ibft
lun".
I thought ibft was only the case booting OS from iscsi (whole / is
iscsi).

Since you pointed out, now I know ibft lun can be used in many cases and
ibft is not just about boot from iscsi lun. Is that right?

I think if providing ip=ibft and rd.iscsi.firmware, dracut will bring
up ibft luns, even these luns are not root. I didn't test this. Once I
have a chance to borrow a ibft box again, I can test.

>  
>  > 
>  > >  Can't I bring up ibft luns from user space later?
>  > 
>  > You don't have to manually do this. ibft luns will be brought up in
>  > initrd.
>  
>  Only if root is on ibft lun? 
No. all luns seen by ibft if providing ip=ibft and rd.iscsi.firmware.

>  
>  > 
>  > > If yes, it might be better to always append ip=ibft and rd.iscsi.firmware
>  > > to command line option.
>  > 
>  > If 1st kernel uses ibft, ip=ibft and rd.iscsi.firmware are already there
>  > in cmdline.
>  > 
>  > If 1st kernel doesn't use ibft, I don't see a reason for ibft to be used
>  > in 2nd kernel.
>  > 
>  > Providing duplicated ip=ibft might cause some unexpected behavior of
>  > dracut. I didn't test it. I'm not sure wether it's a good idea or not.
>  > But if you have strong reason or insist to do this, I'm fine with this.
>  
>  You can write a function which appends an option to command line only
>  if it is not present already. 
Will do.

So I think when dump target is ibft luns, we can append ip=ibft and
rd.iscsi.firmware to cmdline if they doesn't exist. dracut will bring up
all ibft luns including our dump target. What do you think?

Thanks
WANG Chao

[WANG Chao]

On 09/24/13 at 01:49pm, Vivek Goyal wrote:
>  On Tue, Sep 24, 2013 at 09:43:45AM -0400, Vivek Goyal wrote:
>  
>  [..]
>  > > > > +kdump_is_ibft() {
>  
>  A better name might be "target_is_ibft_lun()" 
Great. Will do.

>  
>  > > > > +    local path=$1
>  > > > > +    local tgt_name fw_tgt_name
>  > > > > +
>  > > > > +    tgt_name=$(kdump_iscsi_get_rec_val "$path"
> "node.name")
>  > > > > +    fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1
> == "node.name" {print $3}')
>  > > > > +
>  > > > > +    [ -n "$fw_tgt_name" ] && strstr
> "$fw_tgt_name" "$tgt_name"
>  
>  I vaguely remember that one problem with ibft in the past was that one
>  could not tell reliably whether a lun came from ibft configuration or
>  not. 
I get the target name of current session and see if it's in the list of
ibft exported target names. If yes, I assume the current session is ibft
lun.

It's not accurate, I know. When there's two network card, say eth{0,1}
both configured ibft, each target is tgt{0,1}. After system boot, I
login tgt1 using eth0. This case will fail target_is_ibft_lun().

>  
>  So how does above work. Can you give an actual example.  
Not now. I can show you once I get a machine with ibft configured.

>  
>  Is this generic enough to work on wide variety of iscsi ibft
>  configurations? So after this, should we start claiming supporting iscsi
>  using ibft as kdump target? 
I think the first thing I need to figure out is how many use case we
need to cover. I'm not familiar with this unfortunately...

Once we can cover all the cases and also have well tested by QE, I think
yes we can say ibft is supported.

Thanks
WANG Chao