From owner-freebsd-hackers@freebsd.org Sun Mar 8 17:53:23 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 62C452701E0 for ; Sun, 8 Mar 2020 17:53:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48b88x4B32z3NTQ; Sun, 8 Mar 2020 17:53:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 028Hr73U066628 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 8 Mar 2020 19:53:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 028Hr73U066628 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 028Hr6Nt066627; Sun, 8 Mar 2020 19:53:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Mar 2020 19:53:06 +0200 From: Konstantin Belousov To: Mark Millard Cc: FreeBSD Hackers , jhb@freebsd.org Subject: Re: bugzilla 213937, syscall(int, ...), struct ktr_syscall's short ktr_code, struct syscall_args's u_int code: should the bug be closed? Message-ID: <20200308175306.GM98340@kib.kiev.ua> References: <5AEC7760-EF38-4738-AEBD-9E563CB0E62B.ref@yahoo.com> <5AEC7760-EF38-4738-AEBD-9E563CB0E62B@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5AEC7760-EF38-4738-AEBD-9E563CB0E62B@yahoo.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 48b88x4B32z3NTQ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-0.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.938,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-3.14), ipnet: 2001:470::/32(-4.65), asn: 6939(-3.59), country: US(-0.05)]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 17:53:23 -0000 On Sat, Mar 07, 2020 at 09:42:29PM -0800, Mark Millard via freebsd-hackers wrote: > Question: Should bugzilla 213937 be left as-is to suggest > changing things so that more bad syscall "code/number" > values are preserved and reported correctly if/when they > happen? > > Background leading to the question . . . > > I've been reviewing some of my old bugzilla reports that > are still in the new state, closing or adding notes to a > bunch of them. The status for what contributes to > bugzilla 213937 has not changed over the years since the > submittal. > > Bugzilla 213937 was a report of ktrace misreporting the 24 > bit field value in the armv7 svclt instruction. (I had a bad > file that had such an instruction with a large 24-bit field > value that lead to seeing the problems. It was rather > confusing until I figured out the information reported was > incorrect relative to the instruction encoding.) > > Part of the problem was that it looked like the lower 16 > bits had been used but sign extended to produce the > reported value, a negative number as reported. (It took > a while to notice that.) > > Oleksandr Tymoshenko eventually reported in comment #2 > that there is the odd mix of types in use overall > (I'm using the "code" terminology below): > > syscall(int code,...) > struct ktr_syscall's short ktr_code > struct syscall_args's u_int code > > Sure enough, using ktr_code could generate a sign-extension > of a 16-bit value. But syscall and syscall_args are a > little odd as well (signed vs. unsigned at least). > > It looks like "short ktr_code" has been around for long > before I ever ran into it and might well be expected by > folks with more historical background than I had. But it > can not preserve all int or u_int values for FreeBSD's > normal definitions of those types. > > Is this something that should be fixed? Does it have a > reason for being as it is? I do not think that we want to change the layout of KTR_SYSCALL message. We can re-define the message number and extend the ktr_code member to full u_int, but the general hope is that we are very far from having 32K syscalls defined, and will be for quite some time. It might be that some relief for invalid printing can be provided by changing the ktr_code type to unsigned short. It does not fix truncation, but would avoid sign-extension bug. Or even this. diff --git a/usr.bin/kdump/kdump.c b/usr.bin/kdump/kdump.c index 3b597533359..522877ccb2d 100644 --- a/usr.bin/kdump/kdump.c +++ b/usr.bin/kdump/kdump.c @@ -796,7 +796,7 @@ ktrsyscall(struct ktr_syscall *ktr, u_int sv_flags) intmax_t arg; int quad_align, quad_slots; - syscallname(ktr->ktr_code, sv_flags); + syscallname((unsigned short)ktr->ktr_code, sv_flags); ip = first = &ktr->ktr_args[0]; if (narg) { char c = '('; @@ -1534,7 +1534,7 @@ ktrsysret(struct ktr_sysret *ktr, u_int sv_flags) register_t ret = ktr->ktr_retval; int error = ktr->ktr_error; - syscallname(ktr->ktr_code, sv_flags); + syscallname((unsigned short)ktr->ktr_code, sv_flags); printf(" "); if (error == 0) {