Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build fails with devmapper.c:387:97: error: unused parameter ‘deferred_remove’ [-Werror=unused-parameter] #7

Closed
paulmenzel opened this issue May 20, 2021 · 15 comments

Comments

@paulmenzel
Copy link

Build version 0.8.6 fails with the error below:

$ make
[…]
cc --std=gnu99  -O2 -g -fstack-protector-strong --param=ssp-buffer-size=4 -Werror -Wall -Wextra -Wformat=2 -Werror=implicit-int -Werror=implicit-function-declaration -Werror=format-security -Wno-clobbered -Wno-error=clobbered -Werror=cast-qual -Werror=discarded-qualifiers -pipe -DBIN_DIR=\"/sbin\" -DLIB_STRING=\"lib64\" -DRUN_DIR=\"run\" -MMD -MP -fPIC -I../libmpathcmd -I../libmpathpersist -I../libmultipath/nvme -DUSE_SYSTEMD=242 -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE -DLIBUDEV_API_RECVBUF -Wp,-D_FORTIFY_SOURCE=2  -c -o devmapper.o devmapper.c
devmapper.c: In function ‘dm_simplecmd’:
devmapper.c:387:97: error: unused parameter ‘deferred_remove’ [-Werror=unused-parameter]
  387 | dm_simplecmd (int task, const char *name, int no_flush, int need_sync, uint16_t udev_flags, int deferred_remove) {
      |                                                                                             ~~~~^~~~~~~~~~~~~~~
devmapper.c: In function ‘dm_flush_map_nopaths’:
devmapper.c:1125:48: error: unused parameter ‘deferred_remove’ [-Werror=unused-parameter]
 1125 | dm_flush_map_nopaths(const char * mapname, int deferred_remove)
      |                                            ~~~~^~~~~~~~~~~~~~~
devmapper.c: In function ‘dm_cancel_deferred_remove’:
devmapper.c:1576:46: error: unused parameter ‘mpp’ [-Werror=unused-parameter]
 1576 | dm_cancel_deferred_remove (struct multipath *mpp)
      |                            ~~~~~~~~~~~~~~~~~~^~~
@mwilck
Copy link
Contributor

mwilck commented May 20, 2021

Interesting ... what distro / compiler are you using?

@paulmenzel
Copy link
Author

We have our own distribution based loosely on Linux From Scratch (MarIuX64).

I tested GCC 7.5 and 10.1.

@mwilck
Copy link
Contributor

mwilck commented May 20, 2021

asking because we are testing quite a few compilers in our github worklflows. Still not covering everything, obviously.

@mwilck
Copy link
Contributor

mwilck commented May 20, 2021

OK - it's because you don't have LIBDM_API_DEFERRED set. You seem to be using a very old version of libdevmapper.

@paulmenzel
Copy link
Author

Indeed, /usr/include/libdevmapper.h is from lvm2-2.02.100-0.x86_64.

@mwilck
Copy link
Contributor

mwilck commented May 20, 2021

I'll create a patch to avoid this error. Be advised though that multipath testing has almost exclusively been done with newer versions of libdevmapper for several years. Maybe it's time to update :-)

@paulmenzel
Copy link
Author

Thank you for your analysis and help.

Indeed, updating is a good idea. I only need kpartx and will run it manually.

@mwilck
Copy link
Contributor

mwilck commented May 20, 2021

The easiest workaround in cases like this is to just using somewhat less strict warning flags. You could simply add -Wno-unused in the WARNFLAGS (Makefile.inc), for example. If you examine the warnings, you'll see that they are non-fatal, so loosening the flags a bit is justified for that specific use case. We are trying to use strict warn flags to catch errors, but making that work for any distro (or like in your case, with any old library version) is almost impossible, and thus we focus on more modern distros. Our CI goes back to Debian "Jessie", but we can't cover everything.

@mwilck
Copy link
Contributor

mwilck commented May 20, 2021

Please test with 20c2697 (mwilck/tip).

@paulmenzel
Copy link
Author

Perfect. Tested successfully.

(In the commit message, you might want to prefix the issue URL with Resolves:. (But maybe you waited for my test.))

Thank you very much.

@mwilck
Copy link
Contributor

mwilck commented May 20, 2021

Commit msg updated.

@mwilck
Copy link
Contributor

mwilck commented May 20, 2021

I took the liberty to also add a Tested-by: Paul Menzel tag.

@paulmenzel
Copy link
Author

Yes, thank you. I received your patch message.

@xosevp
Copy link
Contributor

xosevp commented May 20, 2021

Indeed, /usr/include/libdevmapper.h is from lvm2-2.02.100-0.x86_64.

It's nearly 8 years old !!!

You are going to find a lot of bugs fun.

@mwilck
Copy link
Contributor

mwilck commented May 20, 2021

Well, at least code wise, we still support these old versions. We just haven't tested current multipath-tools on them for a long time. Also, there are enterprise distros released in 2014 which still have some years of support left. So, I'm generally glad about bug reports like this.

mwilck referenced this issue in openSUSE/multipath-tools Dec 2, 2021
... by the paths and pg vectors of the map to be removed.

Original bug report from Lixiaokeng ("libmultipath: clear removed path from mpp"):

multipathd[3525635]: ==3525635==ERROR: AddressSanitizer: heap-use-after-free on address 0xffffa4902fc0 at pc 0xffffac7d5b88 bp 0xffffa948dac0 sp 0xffffa948dae0
multipathd[3525635]: READ of size 8 at 0xffffa4902fc0 thread T7
multipathd[3525635]:    #0 0xffffac7d5b87 in free_multipath (/usr/lib64/libmultipath.so.0+0x4bb87)
multipathd[3525635]:    #1 0xaaaad6cf7057  (/usr/sbin/multipathd+0x17057)
multipathd[3525635]:    #2 0xaaaad6cf78eb  (/usr/sbin/multipathd+0x178eb)
multipathd[3525635]:    #3 0xaaaad6cff4df  (/usr/sbin/multipathd+0x1f4df)
multipathd[3525635]:    #4 0xaaaad6cfffe7  (/usr/sbin/multipathd+0x1ffe7)
multipathd[3525635]:    #5 0xffffac807be3 in uevent_dispatch (/usr/lib64/libmultipath.so.0+0x7dbe3)
multipathd[3525635]:    #6 0xaaaad6cf563f  (/usr/sbin/multipathd+0x1563f)
multipathd[3525635]:    #7 0xffffac6877af  (/usr/lib64/libpthread.so.0+0x87af)
multipathd[3525635]:    #8 0xffffac44118b  (/usr/lib64/libc.so.6+0xd518b)
multipathd[3525635]: 0xffffa4902fc0 is located 1344 bytes inside of 1440-byte region [0xffffa4902a80,0xffffa4903020)
multipathd[3525635]: freed by thread T7 here:
multipathd[3525635]:    #0 0xffffac97d703 in free (/usr/lib64/libasan.so.4+0xd0703)
multipathd[3525635]:    #1 0xffffac824827 in orphan_paths (/usr/lib64/libmultipath.so.0+0x9a827)
multipathd[3525635]:    #2 0xffffac824a43 in remove_map (/usr/lib64/libmultipath.so.0+0x9aa43)
multipathd[3525635]:    #3 0xaaaad6cf7057  (/usr/sbin/multipathd+0x17057)
multipathd[3525635]:    #4 0xaaaad6cf78eb  (/usr/sbin/multipathd+0x178eb)
multipathd[3525635]:    #5 0xaaaad6cff4df  (/usr/sbin/multipathd+0x1f4df)
multipathd[3525635]:    #6 0xaaaad6cfffe7  (/usr/sbin/multipathd+0x1ffe7)
multipathd[3525635]:    #7 0xffffac807be3 in uevent_dispatch (/usr/lib64/libmultipath.so.0+0x7dbe3)
multipathd[3525635]:    #8 0xaaaad6cf563f  (/usr/sbin/multipathd+0x1563f)
multipathd[3525635]:    #9 0xffffac6877af  (/usr/lib64/libpthread.so.0+0x87af)
multipathd[3525635]:    #10 0xffffac44118b  (/usr/lib64/libc.so.6+0xd518b)

When mpp only has one path and log out the path, there is an asan error.
In remove_mpp, the pp is freed firstly in orphan_path but is accessed,
changed in free_multipath later. Before free_path(pp), the pp should be
cleared from pp->mpp.

Reported-by: Lixiaokeng <lixiaokeng@huawei.com>
Tested-by: Lixiaokeng <lixiaokeng@huawei.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants