From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E67713858C41 for ; Wed, 15 Nov 2023 02:07:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E67713858C41 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E67713858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700014036; cv=none; b=bp6/+MvXAalY9kbw8jErXpr+DnXyptJxOYd3cBU0h+3Xi+iwRN9oUmuGacFt9qv7AYHE/D3uRkSxKI5fUmFIzfPndhf3k6ght0cEJOG6cV5Jf96MF/PSQZmsE+ZWVUthP227e5T2mURKLMxqKeNzOWl4FLQzys6G9Zhz3wxXTS4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700014036; c=relaxed/simple; bh=fIpYDojUwHmYvSTpXpPGD61KDyYwp1f6eqpL2Hgc9Do=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=EUVfSf0dXco0QZ6vFYEZUirlcf9w8aOCdBWsjqy34x16EZ+Er4UcQ1c60DP7Z4DFxXWBn+Vg3F8x0pzAbTosA4tPm3VPh3w6a3//lEzFTLcaLkuA34c/m5VcHqiQrlM1CbmJR+40Z6gVKjoJrcTTkcfh/FTytOBmOmzs6Yxz4g0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700014034; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=jQ6HJVA5I/8mRYv/2czjXSYYmjVTv7YlqXJozURLyxo=; b=QmkY8PuvOjzM0C3n1znpGrc6QwoHGs5wsAje8qqSeO5muECAioFF+AWtkBRYHlBya3PG/1 jqUEN/AzuGLmX1WTIL5iOMp1FlRldTNJxQDnOi8iC1w7t3Rj4qL+nL/EymUDR0uvFu39Hn 51eoxXwadM4o5TWZwB1hl1qcQTqKF7U= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-562-55kphR9wNWeML9ahYKhoiw-1; Tue, 14 Nov 2023 21:07:13 -0500 X-MC-Unique: 55kphR9wNWeML9ahYKhoiw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 03D033810D20 for ; Wed, 15 Nov 2023 02:07:13 +0000 (UTC) Received: from [10.22.32.166] (unknown [10.22.32.166]) by smtp.corp.redhat.com (Postfix) with ESMTP id D08003D3; Wed, 15 Nov 2023 02:07:12 +0000 (UTC) Message-ID: <2dbc0bb1-f45d-4e90-b6cf-cd607511f3a8@redhat.com> Date: Tue, 14 Nov 2023 21:07:12 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: systemtap@sourceware.org Cc: wcohen@redhat.com From: William Cohen Subject: Improving the "make installcheck" results for the syscalls test X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, Been going through the syscall test result to see what can be done to improve the syscall test results. There were 359 failures on the x86_64 RHEL9 guest VM I tried things out on. There seems to be four different ways that the syscall tests are failing: 1) Pointers rather than actual strings printed 2) Incomplete output from the instrumenttion scripts 3) Some fields in struct timespec not being printed properly 4) Matching issue (for example 4th arg printed as hex, but matching expects decimal for preadv For the pointers in place of strings The reason for systemtap printing the pointer rather than the actual string is that memory page is not available when the systemtap probe fires. This typically happens for the syscall tests that have strings stored as read only constants. When the initial syscall with a pointer to the read only constant is made that particular area of memory is not yet mapped in on entry to the syscall. However, the kernel does map in the page with the string, but that occurs after the systemtap probe handler for syscall entry runs. A work around for this behavior is to have some code do a sprintf of the string constant in the dummy buffer before the syscall is made. This causes the string constants to be mapped in before the syscalls are made. I have implements this on about 20 of syscall test driver programs. There looks to be about 90 that have strings in them. Incomplete output When reviewing the systemtap.log output to detemine why tests failed I found a number of tests where output was truncated or parts of the output were dropped. The places where things were dropped varied between runs. Would see things like: spawn -ignore SIGHUP gcc /home/wcohen/systemtap_write/systemtap/testsuite/systemtap.syscall/domainname.c -m64 -lrt -Wno-stringop-overflow -lm -o /home/wcohen/systemtap_write/systemtap/testsuite/staptestv2on6W/domainname domainname FAILED. output of "staprun -R /home/wcohen/systemtap_write/systemtap/testsuite/syscall_longlonglong.ko -c /home/wcohen/systemtap_write/systemtap/testsuite/staptestv2on6W/domainname" was: ------------------------------------------ stapio: rt_sigaction (SIGUSR1, {SIG_DFL}, 0x0, 8) = WARNING: There were 1 transport failures. Try stap -s to increase the buffer size from 16. ------------------------------------------ RESULTS: ('*' = MATCHED EXPECTED) --------- EXPECTED and NOT MATCHED ---------- ^domainname: setdomainname \(0x[f]+, [\-0-9]+\) = -[\-0-9]+ ^domainname: setdomainname \("([a-zA-Z0-9\.-]+|\(none\))", -1\) = -[\-0-9]+ FAIL: 64-bit domainname syscall A number of the tests seem to stop having output before the driver program is run. Also have cases like the following where the return value and carrige return aren't printed: msg_queue: msgget (-1, IPC_CREAT|IPC_EXCL|0600) = msg_queue: msgsnd (-1, 0x404060, 136, 0x0) = -22 (EINVAL) Which tests this incomplete output occurs on appears to vary between runs. Printing of struct timestruct field apppear to be wrong for some syscalls One example of the questionable output is for the futex syscall test. The diagnostic output shows matching the futex syscalls until it gets to calls that have fields with floating point values. The output has values of 0.000000000, but expecting 0.000000789 *futex: futex (0x7f9e546dd000, FUTEX_WAKE, 1) = 1 futex: wait4 (23149, 0x7ffe4ecdd328, 0x0, 0x0) = 23149 futex: munmap (0x7f9e546dd000, 4) = 0 *futex: futex (0xffffffffffffffff, FUTEX_WAKE, 1) = -22 (EINVAL) *futex: futex (0x0, 0xffffffff, 1) = -38 (ENOSYS) *futex: futex (0x0, FUTEX_CMP_REQUEUE, -1, 0, 0x0, 0) = -22 (EINVAL) *futex: futex (0x0, FUTEX_CMP_REQUEUE, 1, 18446744073709551615, 0x0, 0) = -22 (EINVAL) *futex: futex (0x0, FUTEX_CMP_REQUEUE, 1, 0, 0xffffffffffffffff, 0) = -14 (EFAULT) *futex: futex (0x0, FUTEX_CMP_REQUEUE, 1, 0, 0x0, -1) = -14 (EFAULT) *futex: futex (0x0, FUTEX_WAKE_BITSET, 1, 0xffffffffffffffff) = -14 (EFAULT) futex: futex (0x0, FUTEX_WAIT, 1, [0.000000000]) = -14 (EFAULT) futex: futex (0x0, FUTEX_WAIT_BITSET, 1, [0.000000000], 0xbeef) = -14 (EFAULT) futex: futex (0x0, FUTEX_REQUEUE, 1, 2, 0x0) = -14 (EFAULT) futex: futex (0x0, FUTEX_CMP_REQUEUE, 1, 2, 0x3, -1) = -14 (EFAULT) futex: futex (0x0, FUTEX_WAKE_OP, 1, 2, 0x3, {FUTEX_OP_SET, 2, FUTEX_OP_CMP_EQ, 1}) = -14 (EFAULT) futex: futex (0x0, FUTEX_WAIT_REQUEUE_PI, 1, [0.000000000], 0x0) = -22 (EINVAL) futex: exit_group (0) = --------- EXPECTED and NOT MATCHED ---------- ^futex: futex \(0x0, FUTEX_WAIT, 1, \[0.000000789\]\) = [\-0-9]+ ^futex: futex \(0x0, FUTEX_WAIT_BITSET, 1, \[0.000000789\], 0xbeef\) = [\-0-9]+ ^futex: futex \(0x0, FUTEX_REQUEUE, 1, 2, 0x0\) = [\-0-9]+ ^futex: futex \(0x0, FUTEX_CMP_REQUEUE, 1, 2, 0x3, -1\) = [\-0-9]+ ^futex: futex \(0x0, FUTEX_WAKE_OP, 1, 2, 0x3, {FUTEX_OP_SET, 2, FUTEX_OP_CMP_EQ, 1}\) = [\-0-9]+ ^futex: futex \(0x0, FUTEX_WAIT_REQUEUE_PI, 1, \[0.000000789\], 0x0\) = [\-0-9]+ FAIL: 64-bit futex syscall Matching issues For a few of the syscall tests there appears to be missmatches between what is outputed and what is expected. For example in preadv the preadv2 syscall prints out the 4th argument in hexadecimal but the matching expects a decimal quantity. -Will