Bug 1069584

Created attachment 867376 [details]
propsed patch v1

Created attachment 867494 [details]
propsed patch v2

Xiaowei, I've created a RHEL 7 x86_64 build with the latest version of the patch. It is here:

https://brewweb.devel.redhat.com/taskinfo?taskID=7105361

In case you want to try  it. When I ran some tests, I got:

[root@client abrt]# multipathd reconfigure
fail
[root@client abrt]# systemctl status multipathd.service
multipathd.service - Device-Mapper Multipath Device Controller
   Loaded: loaded (/usr/lib/systemd/system/multipathd.service; enabled)
   Active: active (running) since Tue 2014-02-25 19:11:26 CET; 30s ago
  Process: 4104 ExecStart=/sbin/multipathd (code=exited, status=0/SUCCESS)
  Process: 4103 ExecStartPre=/sbin/modprobe dm-multipath (code=exited, status=0/SUCCESS)
 Main PID: 4108 (multipathd)
   CGroup: /system.slice/multipathd.service
           └─4108 /sbin/multipathd

Feb 25 19:11:25 client.example.org modprobe[4103]: Executing: /sbin/modprobe dm-multipath
Feb 25 19:11:26 client.example.org multipathd[4104]: Executing: /sbin/multipathd
Feb 25 19:11:44 client.example.org multipathd[4108]: path checkers start up
Feb 25 19:11:44 client.example.org multipathd[4108]: reconfigure (operator)
Feb 25 19:11:44 client.example.org multipathd[4108]: error parsing config file

(In reply to Jose Castillo from comment #2)
> I think the patch attached solve the problem for both fast_io_fail_tmo and
> dev_loss_tmo. Xiaowei, did you have any problems with dev_loss_tmo as well?
> 
> The patch is based on the same approach for the options "rr_min_io_rq" and
> "flush_on_last_del", but lets see if Ben think is correct.

when testing the dev_loss_tmo, get the following result. please let me know if it's the same issue and if you want me to file another bug for the dev_loss_tmo.

1. does not provide the value to dev_loss_tmo section -- pass
for example:
defaults {
    user_friendly_names     yes
    dev_loss_tmo  
}

# multipathd reconfig
fail

# service multipathd status
>>> snip >>>
: error parsing config file
>>> snip >>>

2. provide the wrong string value to dev_loss_tmo section -- fail, coredump
for example:
defaults {
    user_friendly_names     yes
    dev_loss_tmo  aaa
}

Core was generated by `/sbin/multipathd'.
Program terminated with signal 11, Segmentation fault.
#0  __GI___libc_free (mem=0x63687461706d) at malloc.c:2903
2903	  if (chunk_is_mmapped(p))                       /* release mmapped memory. */
(gdb) bt
#0  __GI___libc_free (mem=0x63687461706d) at malloc.c:2903
#1  0x00007fca831f4a9a in xfree (string=<optimized out>) at ../xfree.c:49
#2  0x00007fca82b7d09e in free_config (conf=conf@entry=0x7fca7400f920) at config.c:473
#3  0x00007fca83a8f033 in reconfigure (vecs=0x7fca840acf00) at main.c:1418
#4  0x00007fca83a92157 in parse_cmd (cmd=cmd@entry=0x7fca7400cee0 "reconfig \n", 
    reply=reply@entry=0x7fca83a3dd58, len=len@entry=0x7fca83a3dd40, data=data@entry=0x7fca840acf00)
    at cli.c:399
#5  0x00007fca83a8d7f5 in uxsock_trigger (str=0x7fca7400cee0 "reconfig \n", 
    reply=reply@entry=0x7fca83a3dd58, len=len@entry=0x7fca83a3dd40, 
    trigger_data=trigger_data@entry=0x7fca840acf00) at main.c:744
#6  0x00007fca83a91052 in uxsock_listen (
    uxsock_trigger=uxsock_trigger@entry=0x7fca83a8d7b0 <uxsock_trigger>, 
    trigger_data=trigger_data@entry=0x7fca840acf00) at uxlsnr.c:168
#7  0x00007fca83a8e19f in uxlsnrloop (ap=0x7fca840acf00) at main.c:905
#8  0x00007fca83650df3 in start_thread (arg=0x7fca83a3e700) at pthread_create.c:308
#9  0x00007fca8247e39d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
(gdb) l
2898	  if (mem == 0)                              /* free(0) has no effect */
2899	    return;
2900	
2901	  p = mem2chunk(mem);
2902	
2903	  if (chunk_is_mmapped(p))                       /* release mmapped memory. */
2904	  {
2905	    /* see if the dynamic brk/mmap threshold needs adjusting */
2906	    if (!mp_.no_dyn_threshold
2907		&& p->size > mp_.mmap_threshold

also hit the similar core dump when passing the wrong string value to the fast_io_fail_tmo.

(In reply to Jose Castillo from comment #6)
> Xiaowei, I've created a RHEL 7 x86_64 build with the latest version of the
> patch. It is here:
> 
> https://brewweb.devel.redhat.com/taskinfo?taskID=7105361
> 
> In case you want to try  it. When I ran some tests, I got:
> 
> [root@client abrt]# multipathd reconfigure
> fail
> [root@client abrt]# systemctl status multipathd.service
> multipathd.service - Device-Mapper Multipath Device Controller
>    Loaded: loaded (/usr/lib/systemd/system/multipathd.service; enabled)
>    Active: active (running) since Tue 2014-02-25 19:11:26 CET; 30s ago
>   Process: 4104 ExecStart=/sbin/multipathd (code=exited, status=0/SUCCESS)
>   Process: 4103 ExecStartPre=/sbin/modprobe dm-multipath (code=exited,
> status=0/SUCCESS)
>  Main PID: 4108 (multipathd)
>    CGroup: /system.slice/multipathd.service
>            └─4108 /sbin/multipathd
> 
> Feb 25 19:11:25 client.example.org modprobe[4103]: Executing: /sbin/modprobe
> dm-multipath
> Feb 25 19:11:26 client.example.org multipathd[4104]: Executing:
> /sbin/multipathd
> Feb 25 19:11:44 client.example.org multipathd[4108]: path checkers start up
> Feb 25 19:11:44 client.example.org multipathd[4108]: reconfigure (operator)
> Feb 25 19:11:44 client.example.org multipathd[4108]: error parsing config
> file

tested the rpm. the original issue was fixed. but we still have the following issues:

1. the patch cannot fix the issue that fast_io_fail_tmo is in device sector not in the default section

devices {
        device {
                vendor "DGC"
                product ".*"
                product_blacklist "LUNZ"
                fast_io_fail_tmo
        }

}

2. the patch cannot fix the issue in comment 7.

also, let me know if you want me to file the new bug to track the new issues since your patch can fix the original issue.

(In reply to Xiaowei Li from comment #9)
> tested the rpm. the original issue was fixed. but we still have the
> following issues:
> 
> 1. the patch cannot fix the issue that fast_io_fail_tmo is in device sector
> not in the default section
> 
> devices {
>         device {
>                 vendor "DGC"
>                 product ".*"
>                 product_blacklist "LUNZ"
>                 fast_io_fail_tmo
>         }
> 
> }
> 

This may be a new, different problem, but see below first.

> 2. the patch cannot fix the issue in comment 7.
> 
Were you using in this test the patched version or the original one? I ask you because I have the feeling that is the patch itself what causes the coredump in comment #7. 

> also, let me know if you want me to file the new bug to track the new issues
> since your patch can fix the original issue.

Fill a new bugzilla only if the test in #7 was done with the original multipath package, not the patched one. If that is not the case, then I'll fix the patch to avoid this problem.

since it's not a blocker and RHEL 7.0 is going to RC we should move it to 7.1.

Patch applied. Thanks!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0367.html