[LU-12104] SEGV during "lfs find [--mdt-count=[+,-]<count>, --mdt-hash=<hashtype>]" Created: 25/Mar/19  Updated: 27/Jun/19  Resolved: 27/Jun/19

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.13.0

Type: Bug Priority: Minor
Reporter: Bruno Faccini (Inactive) Assignee: Bruno Faccini (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Related
is related to LU-11376 Special file/dir to represent DAOS Co... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

As part of LU-11376 patchs development and validation, I have found these unexpected errors cases :

[root@boro-51 tmp]# lfs df /mnt/testfs
UUID                   1K-blocks        Used   Available Use% Mounted on
testfs-MDT0000_UUID       125368        2084      112048   2% /mnt/testfs[MDT:0]
testfs-MDT0001_UUID       125368        2000      112132   2% /mnt/testfs[MDT:1]
testfs-OST0000_UUID       325368       13648      284560   5% /mnt/testfs[OST:0]
testfs-OST0001_UUID       325368       13652      284556   5% /mnt/testfs[OST:1]

filesystem_summary:       650736       27300      569116   5% /mnt/testfs

[root@boro-51 tmp]# [root@boro-51 tmp]# lfs mkdir --mdt-count=2 --mdt-hash="fnv_1a_64" /mnt/testfs/foodir
[root@boro-51 tmp]# lfs getdirstripe /mnt/testfs/foodir
lmv_stripe_count: 2 lmv_stripe_offset: 1 lmv_hash_type: fnv_1a_64
mdtidx           FID[seq:oid:ver]
     1           [0x240000400:0x5:0x0]  
     0           [0x200000401:0x5:0x0]  
[root@boro-51 tmp]# [root@boro-51 tmp]# lfs find --mdt-count=+1 --mdt-hash="fnv_1a_64" /mnt/testfs/*
/mnt/testfs/foodir
[root@boro-51 tmp]# [root@boro-51 tmp]# touch /mnt/testfs/foodir/foo
[root@boro-51 tmp]# lfs find --mdt-count=+1 --mdt-hash="fnv_1a_64" /mnt/testfs/*
/mnt/testfs/foodir
Segmentation fault (core dumped)
[root@boro-51 tmp]# 
[root@boro-51 tmp]# ls core*
core.146013
[root@boro-51 tmp]# 
[root@boro-51 tmp]# gdb /bin/lfs core.146013
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/lfs...Reading symbols from /usr/lib/debug/usr/bin/lfs.debug...done.
done.
[New LWP 146013]
Core was generated by `lfs find --mdt-count=+1 --mdt-hash=fnv_1a_64 /mnt/testfs/foodir /mnt/testfs/msc'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007ffff6f4bd30 in dirfd () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7_4.2.x86_64 libyaml-0.1.4-11.el7_0.x86_64 zlib-1.2.7-17.el7.x86_64
(gdb) where
#0  0x00007ffff6f4bd30 in dirfd () from /lib64/libc.so.6
#1  0x00007ffff7bb5404 in cb_get_dirstripe (d=d@entry=0x0, param=param@entry=0x7fffffffd930, path=0x625030 "/mnt/testfs/foodir/foo") at liblustreapi.c:1745
#2  0x00007ffff7bb9bfd in cb_find_init (path=path@entry=0x625030 "/mnt/testfs/foodir/foo", parent=<optimized out>, dirp=dirp@entry=0x0, data=data@entry=0x7fffffffd930, de=de@entry=0x628980)
    at liblustreapi.c:4098
#3  0x00007ffff7bb7700 in llapi_semantic_traverse (path=path@entry=0x625030 "/mnt/testfs/foodir/foo", parent=parent@entry=0x0, sem_init=sem_init@entry=0x7ffff7bb95e0 <cb_find_init>, 
    sem_fini=sem_fini@entry=0x7ffff7bb4d80 <cb_common_fini>, data=data@entry=0x7fffffffd930, de=de@entry=0x0, size=4097) at liblustreapi.c:1938
#4  0x00007ffff7bb7d3d in param_callback (path=<optimized out>, sem_init=sem_init@entry=0x7ffff7bb95e0 <cb_find_init>, sem_fini=sem_fini@entry=0x7ffff7bb4d80 <cb_common_fini>, 
    param=param@entry=0x7fffffffd930) at liblustreapi.c:1986
#5  0x00007ffff7bb9116 in llapi_find (path=<optimized out>, param=param@entry=0x7fffffffd930) at liblustreapi.c:4580
#6  0x0000000000408f1b in lfs_find (argc=5, argv=0x7fffffffe130) at lfs.c:4076
#7  0x00007ffff7bc81d1 in Parser_execarg (argc=argc@entry=5, argv=argv@entry=0x7fffffffe130, cmds=cmds@entry=0x6245c0 <cmdlist>) at util/parser.c:115
#8  0x000000000040422e in main (argc=6, argv=0x7fffffffe128) at lfs.c:9532
(gdb) quit
[root@boro-51 tmp]# 

Coredump analysis has permitted me to find that this is due to not checking/discarding that/when "DIR *dir" is NULL in cb_find_init() when handling either --mdt-count or --mdt-hash options/filters.



 Comments   
Comment by Bruno Faccini (Inactive) [ 25/Mar/19 ]

Fix/patch for this problem should be something like :

diff --git a/lustre/utils/liblustreapi.c b/lustre/utils/liblustreapi.c
index 67eb90b454..52ccaeb0f7 100644
--- a/lustre/utils/liblustreapi.c
+++ b/lustre/utils/liblustreapi.c
@@ -4096,7 +4304,8 @@ static int cb_find_init(char *path, DIR *parent, DIR **dirp,
                 decision = 0;
 
        if (decision == 0) {
-               if (param->fp_check_mdt_count || param->fp_check_hash_type) {
+               if (dir && (param->fp_check_mdt_count || 
+                   param->fp_check_hash_type)) {
                        param->fp_get_lmv = 1;
                        ret = cb_get_dirstripe(path, dir, param);
                        if (ret != 0)
Comment by Andreas Dilger [ 27/Mar/19 ]

A fix for this is included into patch https://review.whamcloud.com/34087 "LU-11376 lmv: new foreign LMV format".

Comment by Bruno Faccini (Inactive) [ 27/Mar/19 ]

Yes, you are right Andreas, I forgot to add that in order to be able to check my changes for LU-11376, I had to integrate the fix already !!...

So may be I can close this ticket, as change #34087 for LU-11376 is about to land with the fix in ?

Comment by Bruno Faccini (Inactive) [ 26/Jun/19 ]

Not sure to understand why the "Not a Bug" resolution ?

Comment by Andreas Dilger [ 27/Jun/19 ]

I guess I thought that the fix was landed before the original patch was landed, but that was incorrect. I've fixed the resolution type.

Generated at Sat Feb 10 02:49:42 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.