This is an archive of the discontinued LLVM Phabricator instance.

sanitizer: Don't intercept ustat for Linux
AbandonedPublic

Authored by hjl.tools on May 21 2018, 3:29 PM.

Details

Summary

<sys/ustat.h> has been removed from glibc 2.28 by:

commit cf2478d53ad7071e84c724a986b56fe17f4f4ca7
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date: Sun Mar 18 11:28:59 2018 +0800

Deprecate ustat syscall interface

This patch removes its reference from libsanitizer for Linux to fix

https://bugs.llvm.org/show_bug.cgi?id=37418

Diff Detail

Event Timeline

hjl.tools created this revision.May 21 2018, 3:29 PM
hjl.tools retitled this revision from [PATCH] sanitizer: Don't intercept ustat for Linux to sanitizer: Don't intercept ustat for Linux.May 22 2018, 6:20 AM
cryptoad resigned from this revision.May 22 2018, 10:32 AM

Sorry I don't know enough about the ustat usages, resigning as a reviewer.

kcc added a reviewer: eugenis.May 23 2018, 8:52 AM

the ustat interceptor has been added in 2013, probably as part of the work on msan.

r190157 | eugenis | 2013-09-06 07:20:01 -0700 (Fri, 06 Sep 2013) | 2 lines
[sanitizer] A bunch of linux system call handlers.

I bet some code uses ustat and was causing msan false positives.
We don't seem to have tests for it, and such a test doesn't appear trivial for the LLVM test suite.

What will happen on pre 2.28 if we remove this interceptor?
Will msan get new false positives?

I tested it on Fedora 28 which has glibc 2.27. There is no regression, probably because there is no test.
We can a definition of sizeof(struct ustat) to sanitizer_common/sanitizer_platform_limits_posix.cc, which
doesn't depend on <sys/ustat.h>.

kcc added a comment.May 23 2018, 9:19 AM

Yes, I think a much safer fix would be to add

unsigned struct_ustat_sz = <SOMETHING>;  // glibc >= 2.28 doesn't have <sys/ustat.h> so we can't include it and use  sizeof(struct ustat);