Page MenuHomePhabricator

jakubjelinek (Jakub Jelínek)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 20 2016, 10:07 AM (142 w, 6 d)

Recent Activity

Jun 16 2018

jakubjelinek added inline comments to D48255: [sanitizer] Fix LSAN for 32-bit glibc before 2.27.
Jun 16 2018, 3:51 AM · Restricted Project

Jun 8 2018

jakubjelinek added a comment to D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.

Could you push it @jakubjelinek? If nobody takes care of it I'll try to merge it later.

Jun 8 2018, 9:43 AM · Restricted Project

May 22 2018

jakubjelinek added inline comments to D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.
May 22 2018, 6:06 AM · Restricted Project

May 9 2018

jakubjelinek added inline comments to D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.
May 9 2018, 11:40 AM · Restricted Project
jakubjelinek updated the diff for D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.
May 9 2018, 10:12 AM · Restricted Project
jakubjelinek added a comment to D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.

Updated patch, which uses a template with 2 support classes to avoid some code duplication. I must say that I find

#ifndef __GLIBC_PREREQ
# define __GLIBC_PREREQ(x, y) 0
#endif

easier to read over the longer sequence of #ifs, and as I said earlier, the proposed

#if defined(__i386__) && (!defined(__GLIBC_PREREQ) || !__GLIBC_PREREQ(2, 27))

is not valid C/C++ if __GLIBC_PREREQ macro is not defined.

May 9 2018, 9:05 AM · Restricted Project
jakubjelinek updated the diff for D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.
May 9 2018, 9:02 AM · Restricted Project
jakubjelinek added inline comments to D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.
May 9 2018, 8:27 AM · Restricted Project
jakubjelinek added inline comments to D46638: [sanitizer] Fix runtime crash on 32-bit Linux with glibc 2.27.
May 9 2018, 8:04 AM · Restricted Project

Mar 21 2018

jakubjelinek added inline comments to D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.
Mar 21 2018, 12:01 PM · Restricted Project
jakubjelinek added a comment to D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.
In D44623#1042762, @kcc wrote:

Is this related to https://github.com/google/sanitizers/issues/914 or this is another problem?

Mar 21 2018, 11:48 AM · Restricted Project

Mar 19 2018

jakubjelinek added a comment to D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.

glibc 2.27 has added the glob@@GLIBC_2.27 symbols approx. one month after these internal_function changes, so it is closer to that than e.g. trying to parse confstr for glibc 2.27 and later, and is also smaller than trying to parse the confstr string.

Mar 19 2018, 6:49 AM · Restricted Project
jakubjelinek created D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later.
Mar 19 2018, 6:47 AM · Restricted Project

Nov 29 2017

jakubjelinek added a comment to D40600: Enhance libsanitizer support for invalid-pointer-pair..

Can you or Konstantin please commit it? I don't have write access to llvm repo.
Thanks.

Nov 29 2017, 2:42 PM · Restricted Project
jakubjelinek added a comment to D38971: Enhance libsanitizer support for invalid-pointer-pair..

Phabriactor doesn't allow me to update this patch, so I've uploaded it to D40600 instead. If you have a way to update the diff here, please do.

Nov 29 2017, 5:09 AM
jakubjelinek created D40600: Enhance libsanitizer support for invalid-pointer-pair..
Nov 29 2017, 5:07 AM · Restricted Project

Nov 10 2017

jakubjelinek added a comment to D39889: Export __lsan_init.

Can you please commit it?

Nov 10 2017, 10:00 AM
jakubjelinek created D39889: Export __lsan_init.
Nov 10 2017, 1:33 AM
jakubjelinek added a reviewer for D39888: [Sanitizers, LSan, Darwin] Allow for lack of VM_MEMORY_OS_ALLOC_ONCE: kcc.
Nov 10 2017, 1:24 AM · Restricted Project

Oct 17 2017

jakubjelinek added a comment to D39018: -fsanitize=noreturn sanitization.

I have no idea how to CC those mailing lists (Change Subscribers doesn't seem to allow those) in this tool (or shall I just mail them normally)?
As for tests, the ones I have for GCC are:

Oct 17 2017, 11:47 PM
jakubjelinek created D39018: -fsanitize=noreturn sanitization.
Oct 17 2017, 12:42 PM
jakubjelinek added a comment to D38991: Unbreak libbacktrace symbolizer.
In D38991#899950, @kcc wrote:

LGTM
Do you need me to commit it?

Oct 17 2017, 11:40 AM
jakubjelinek added a comment to D38971: Enhance libsanitizer support for invalid-pointer-pair..

Shouldn't detect_invalid_pointer_pairs=1 be the default? I mean, the user already makes the decision to enable it through a compiler option/parameter and the generated code adds non-zero amount of .text space and some runtime cost, and there is no extra runtime costs for this if code isn't instrumented, so detect_invalid_pointer_pairs=0 by default only causes false assumption that code is error clean.

Oct 17 2017, 8:00 AM
jakubjelinek added a comment to D38971: Enhance libsanitizer support for invalid-pointer-pair..

Besides the patch, we'd like to coordinate on options enabling this in the compilers.
From what I can see, in clang it is currently an experimental asan-detect-invalid-pointer-pair param,
what Martin has implemented is handle it as another kind of sanitization (separate kinds for pointer compare and pointer subtract),
-fsanitize=pointer-subtract or -fsanitize=pointer-compare. One can then do:
-fsanitize=address,pointer-subtract,pointer-compare etc., if address is not specified but one of these is, then
right now we error out. I could imagine pointer-subtract or pointer-compare to be supported even without address
sanitization, where we'd link against libasan and add poisoning/unpoisoning/global variable registration etc., but not
memory dereference checks, the problem is that the compiler then doesn't know if it should do the registration etc.
in kernel-address or user address style.

Oct 17 2017, 2:37 AM
jakubjelinek created D38991: Unbreak libbacktrace symbolizer.
Oct 17 2017, 1:23 AM

Jul 13 2017

jakubjelinek added a comment to D35246: Fix sanitizer build against latest glibc.

Could somebody please commit it? Thanks.

Jul 13 2017, 10:44 AM

Jul 11 2017

jakubjelinek added a comment to D35246: Fix sanitizer build against latest glibc.

Using stack_t in the internal_sigaltstack prototype is problematic, because stack_t is only defined in the *.cc file which includes signal.h through sys/wait.h. But describing what it points to isn't really necessary, the function could be also declared with uptr arguments, or sanitizer_stack_t if we define it independently, etc.
Alternative to using struct
res_state * is using res_state, i.e.

res_state statp = (res_state)state;
Jul 11 2017, 4:22 AM
jakubjelinek created D35246: Fix sanitizer build against latest glibc.
Jul 11 2017, 4:18 AM

Feb 17 2017

jakubjelinek added a comment to D29992: Wrong sanitizer handling of PCs in backtrace.
In D29992#679484, @kcc wrote:

Please:

  • no more #ifdefs int this part of code, at least in the first two hunks
  • no code duplications (the first two hunks look similar)
  • no C-style comments, use //
  • a test

    Also, if possible, please try to change the logic from "harm, then unharm" to "don't harm"
Feb 17 2017, 1:31 AM

Feb 15 2017

jakubjelinek created D29992: Wrong sanitizer handling of PCs in backtrace.
Feb 15 2017, 9:02 AM

Feb 10 2017

jakubjelinek updated the diff for D29825: s390 CVE-2016-2143 whitelist for RHEL kernels.
Feb 10 2017, 2:53 PM
jakubjelinek added a comment to D29825: s390 CVE-2016-2143 whitelist for RHEL kernels.
In D29825#674022, @kcc wrote:
  • please upload patches with full context, otherwise they are harder to review
Feb 10 2017, 2:38 PM
jakubjelinek added a comment to D29824: Fix AddressSanitizer on s390 (31-bit).
In D29824#674011, @kcc wrote:

Is this change testable?

Feb 10 2017, 2:34 PM
jakubjelinek created D29825: s390 CVE-2016-2143 whitelist for RHEL kernels.
Feb 10 2017, 5:31 AM
jakubjelinek added a comment to D29824: Fix AddressSanitizer on s390 (31-bit).

Note, in theory __builtin_extract_return_addr should be used on all architectures, but not sure if it can't break anything, so I'm proposing to use it for now just on s390 31-bit.
In GCC, the builtin returns something other than its unmodified arguments on:
alpha-vms in certain cases
arm (for 26-bit mode)
mips (always masks off lsb)
hppa (always masks off 2 ls bits)
s390 31-bit mode (always masks off msb)
sparc adds 8 or 12 bytes to it
microblaze adds 8 bytes to it

Feb 10 2017, 5:15 AM
jakubjelinek created D29824: Fix AddressSanitizer on s390 (31-bit).
Feb 10 2017, 5:07 AM
jakubjelinek added a comment to D29735: s390x __tls_get_addr_internal vs. __tls_get_offset.
In D29735#672682, @kcc wrote:

check-asan does not pass with this change due to lint"
/tmp/check_lint.XhMkOExnXU/tmp.TSPGZQsNod.sanitizer_common_interceptors.inc.cc:4611: Extra space before ( in function call [whitespace/parens] [4]
/tmp/check_lint.XhMkOExnXU/tmp.TSPGZQsNod.sanitizer_common_interceptors.inc.cc:4611: All parameters should be named in a function [readability/function] [3]
/tmp/check_lint.XhMkOExnXU/tmp.TSPGZQsNod.sanitizer_common_interceptors.inc.cc:4614: Extra space before ( in function call [whitespace/parens] [4]
/tmp/check_lint.XhMkOExnXU/tmp.TSPGZQsNod.sanitizer_common_interceptors.inc.cc:4615: Extra space before ( in function call [whitespace/parens] [4]

Feb 10 2017, 2:19 AM · Restricted Project
jakubjelinek updated the diff for D29735: s390x __tls_get_addr_internal vs. __tls_get_offset.
Feb 10 2017, 2:14 AM · Restricted Project

Feb 9 2017

jakubjelinek updated the summary of D29735: s390x __tls_get_addr_internal vs. __tls_get_offset.
Feb 9 2017, 10:19 AM · Restricted Project
jakubjelinek updated the diff for D29735: s390x __tls_get_addr_internal vs. __tls_get_offset.
Feb 9 2017, 10:18 AM · Restricted Project
jakubjelinek added a comment to D29735: s390x __tls_get_addr_internal vs. __tls_get_offset.

Shall I upload a new patch with that? What is the process now, can somebody check it in for me?

Feb 9 2017, 2:31 AM · Restricted Project
jakubjelinek updated the diff for D29735: s390x __tls_get_addr_internal vs. __tls_get_offset.

Updated patch for that.

Feb 9 2017, 12:42 AM · Restricted Project
jakubjelinek added a comment to D29735: s390x __tls_get_addr_internal vs. __tls_get_offset.
In D29735#671362, @kcc wrote:

This seems to be a S390-only change, right?

Feb 9 2017, 12:26 AM · Restricted Project

Feb 8 2017

jakubjelinek created D29735: s390x __tls_get_addr_internal vs. __tls_get_offset.
Feb 8 2017, 3:40 PM · Restricted Project

Oct 17 2016

jakubjelinek added a comment to D25509: tsan: intercept libatomic.

Defining the builtins directly is certainly not going to work very well.
E.g. GCC libatomic uses:

void libat_load (size_t, void *, void *, int) __asm ("__atomic_load");

or e.g.

void lbat_load (size_t, void *, void *, int);
...
typeof (libat_load) export_load __asm ("__atomic_load") __attribute__((alias ("libat_load")));

or ifuncs.

Oct 17 2016, 11:14 PM

Sep 20 2016

jakubjelinek added a comment to D24771: Add C++17 aligned new/delete entrypoints to libasan.

An interesting question is how to test it upstream.

In theory you could just test it even with C++11, with something like:

#include <new>
Sep 20 2016, 2:34 PM
jakubjelinek added a comment to D24769: tsan: support pie binaries on newer kernels.

Well want to merge all the libsanitizer changes in the next month or two at most, but sure, this can be also desirable for release branch backporting eventually.

Sep 20 2016, 10:22 AM
jakubjelinek retitled D24771: Add C++17 aligned new/delete entrypoints to libasan from to Add C++17 aligned new/delete entrypoints to libasan.
Sep 20 2016, 10:14 AM