From owner-freebsd-arm@freebsd.org Mon May 3 08:00:15 2021 Return-Path: Delivered-To: freebsd-arm@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 607E962A849 for ; Mon, 3 May 2021 08:00:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FYb4G0ZLJz4Yqr for ; Mon, 3 May 2021 08:00:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1620028812; bh=6ErL3r5DtsNgiTDkMVJxXp/EgkaB54WZx4yttrXKbFG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=taIbe/47xXRwISxZCnRDdxFZuo5Wn2yfNRkWWavGhW7vnep18Vv7mN0WapVQ6iZNHSFhKpYr4moII3jb8jP+TGsZ7X4UCOgHqteVuAgQkZu/502cP2QZr7VuYy26pSZw0i70snHwd4+MiMXlWk8f4mYDRSv9BCXFSJRC7hcMG3lpfL+FR5YANWgJTWUUhJZRdTa7xJdFW8J50rPyT6sBQgkIAcbPbBa+CxgYfY3S9VUqXHDguSYGWKfiN5q/rkjqm7Byz8lIq1bmhMfmGDIosME9GPKcB1zfPB2S2ZMmKrUgdU9JJEqP0Yh/FydGJgLPIJAenrA33srW7EDpdqXM1Q== X-YMail-OSG: KZ6S3YEVM1nt6t2_KRCXaC2AfP0DE16c2Rg8.y1KirN7TV.jcxCyV4Ixki3sCVd bKjeza0Kqq8n7oS8RDKKFVh9b0LxOfg1iz3uwqTPuA6QcAvejqi98MvhP6pmRQlb0OqKAJA_Ns5F iZ_LhEGYvalsea8zjLDXqQIGGBAJngywkGcttTVj0bBcXvMnSU6sR7WBzBCQtyKDjeRt6HDdd3Yq KtOk.4rxlG9.mNpcgxw.dUmuy_FfJGfjiO3t9PgnHySPZYTQ75P0wnt7Ral9Jt_3qO78NUBaXg74 WcXsQspAND8MKEpE_EMPkjxuC3aLQy_j3UHXjolnBV1UcHNAcIMBLpy_w.L1fv5NhPMkDZ33KfaY i6AEYH_uO___uUEcWlT_WvZVJTICQA87Ufq4VCc296Ml0UyQFOQs.jKsm5B_eey1x5T3IHZZ9CyI WZeuBLxAe31R1EE4Y.WJD3ng6hqCxOmKKgCayJAUyG8c8wnxa_GYTU8O2tki2CXEU7h8aytk_073 tDSYxGeyWfyAOXaxSnug.Pkp9ZKVTMZQHA45VwnBMNBps93f7lvCBpuEUToGPU2u.MUfMgt8VPIJ M1KVYzpAyiyWuKc7dtW6OxAByWicKURT5nAfWbv1m_G1jO5a0JKP3LMOgH2NywIxDP101pqICS0g WnSMMJs5V1O.meMdGv7TpAbyZlGbtZwvZV8Wv3adLzK4tNfwwyoEy6RbR4noZK7xQRvYwauTyjLh qEAmMRtyNzpiI97XS5jIPacymv5BT1lpJodX32cxUG1EoNhNAUk0cUt.B_VXRl6_M15GXCQ1FGa7 jUlIeb32s5RJT.AkzVuMAnkTptJv5JPfFHEw_f1Ada.VcNxCvTHueMpHCpRG6aeD4O8nYMctfEu7 yGQ8VF1FmLwtR0BHeCRRy.Rr6DFqVzD4TsPizHZhKt6Y9NAayUCuI3dv18dPfs7Y8FRmxEnTrY7w 9Jv0X_.nCgim.Av2V4DmEsh_3SVL2cWHPOD62luN3zmPPZtamAPqDxnQklFf.vuDAJfuw2XN7K4w S8tdHDvTuKf5fYYyWrX35TvZs02Q7XqlS578nfEwp2.ET.0YAFlIXjGFtO6qoFH9iYh5FcCIGSHw I7dMEiGZrkj7HgyqcxITDXHZLsizY07uCHCwrEaGqUGupaSdnwKxUFiFXgVQUS1IPOCYeTYpTawk HPVkyK7t6DvCnukACKyZfIZ.auKISFy8j8673gNC379G98ipK40TyMKo_rI5.Qfu1Kb_d.obkE4E xW_gZOAQJUMngQ06JRb5FOuRxwgYI.IBbcSmBBVgGVTxI1kh6UFrWbi1k_g8u.XriPHPK.AB7l._ 7C8kwMHGtLUa8C7_Nsv3wX0VMAeIIEH0ICNtfogmNz769PZ8L.OaQB_z8NSBvGIA5n4iahGZZGOc Py25Mm9BLFUJGUzwRCv8X6YSg_dhQkRp6K0j5AE3MJp6k8WRQRaBpY_kyEoDgUAtt41hlQEreH5j f_RAK2LOi6XB6uEUfrR6K4q_b5T4tYjvRYDxUuMvRmF3gK4Y_dkdUrZr7W9C6WvKcNXr0B5quuCP 2Ko1mQohmqgsVoSyLS9ieG9GyjFurmGooX.NIwj_TQXpY6oWUg9VXpRTfcaHovoxX.JBCXxxDH_z I._rR1nMGYpZjV04TmSa5PTseZOZETLNZCJ4B3LZ4aRpYiEKTw6EOvRgmkwVMiW2k_WtKB.TCJ7K O6p_kUYtATTAwsN.lIOVpaKJW6qeP0xRI6yvyML5n21nwXAiD4KWHUlKw2dP08pL0gWR2IHsCf8p j3tk61DISAgO_3NAR.v0IuirrHg5AIsIoGM3vQffb.fpLfdJ3l_B3JdRPlnI_KqjlvbB_rq8R2i2 ozIHf_d_Tw.f1kUCKz1gfP1vHZ_APkVt9CWS7naixjBH1XRhpWDxEbNaBgm5wEVPfsrWMCXuIBBL btzci7rOZnxRHgYr1PZ6Bu9r2iRy1uJogpsBwRfd3sKMAhcq_6jLCDPbUvxzRR3swuc0InRyNDrv 1qbI9moMpxr5AUJwwzSJlJQ69U0od.SCQ8yDiUd9BL30ubqgH_xC1o.UAlqHyIszn1_doKm91b47 8HfoJEOax8jVJUEoIwkI2gfoIBGJ309lLCPKjrUA8BUJMLrwCL6jcjUQqi4ntyxie8urj5c5v0F8 wVExtGimUhkDIXJ3H8z7BruoxHMY4w.GWC2pPwyuK7lAgn6GUaho6bFGjlykZfQRNNa8EglmdL13 KJSRzJUitmaM9GC0oPzyfGllC3ld54T4DaXlkVdZINpq3B_NpqQAOilLpg4qkqGzgEca4gnteQvZ FF_wGeCSMQkW8DTblYhfzXex_b_9ddEOAXwOy.mzJff68CT9EE7z8E2xP9zBxaD_qcagtMTdGGko c7Aif2aACD4.xDXXJP1fcA3T9pBa5OZ9OJTviFP5OEuKQCitSqZTX1SLmsLXl5ROs_vxs2FseGyq HPy8P.L6LwfbQ8_UnApBUeOBgh1fYV0JXau2gg2Cm.bQlcdUiDmYLrSg8CjSpex9WBV6I2LA6Rp_ owAS6O_g2G1wqlT4d6ViIB4Wjh6CeN3CdcipV56pjxEP4YKksm47xDjPdMW.o8cKD X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Mon, 3 May 2021 08:00:12 +0000 Received: by kubenode544.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 713617f43e67148f4c1c8b25a07426a5; Mon, 03 May 2021 08:00:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: Xoscope nuisance console messages on Pi4 running -current From: Mark Millard In-Reply-To: <20210503063701.GA34665@www.zefox.net> Date: Mon, 3 May 2021 01:00:03 -0700 Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <263BF9DF-B22B-4579-9667-AFCB7D2D667C@yahoo.com> References: <20210503063701.GA34665@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FYb4G0ZLJz4Yqr X-Spamd-Bar: - X-Spamd-Result: default: False [-1.94 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.56)[0.556]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 08:00:15 -0000 On 2021-May-2, at 23:37, bob prohaska wrote: > After a successful compile of audio/xoscope on a Pi4 running current a > stream of messages appeared on the console and in the security log > while xoscope was running: >=20 >=20 > +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl = ffffffffc0045006 > +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl = ffffffffc0045005 > +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl = ffffffffc0045002 > +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl = ffffffffc0045006 > +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl = ffffffffc0045005 > +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl = ffffffffc0045002 >=20 > They seem to come at a fairly high rate and clutter the logfiles, but=20= > apart from that nuisance nothing else seemed visibly amiss. >=20 > Are they of any significance? The code from a mid 2021-Mar vintage of main [so: 14] looks like: /* ARGSUSED */ int sys_ioctl(struct thread *td, struct ioctl_args *uap) { u_char smalldata[SYS_IOCTL_SMALL_SIZE] = __aligned(SYS_IOCTL_SMALL_ALIGN); uint32_t com; int arg, error; u_int size; caddr_t data; #ifdef INVARIANTS if (uap->com > 0xffffffff) { printf( "WARNING pid %d (%s): ioctl sign-extension ioctl = %lx\n", td->td_proc->p_pid, td->td_name, uap->com); } #endif com =3D (uint32_t)uap->com; . . . where sys/sys/sysproto.h shows: struct ioctl_args { char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)]; char com_l_[PADL_(u_long)]; u_long com; char = com_r_[PADR_(u_long)]; char data_l_[PADL_(char *)]; char * data; char = data_r_[PADR_(char *)]; }; So, uap->com is unsigned with 64 bits for aarch64 and the 0xffffffff is converted to match that for the > test (C rules). The assignment to uint32_t com would end up with a truncated value recorded whenever the warning is produced. Thus a value like 0xffffffffc0045006ul ends up with com =3D=3D 0xc0045006u instead. Then looking at the usage of com leads to sys/sys/ioccom.h : . . . /* * Ioctl's have the command encoded in the lower word, and the size of * any in or out parameters in the upper word. The high 3 bits of the * upper word are used to encode the in/out status of the parameter. * * 31 29 28 16 15 8 7 0 * = +---------------------------------------------------------------+ * | I/O | Parameter Length | Command Group | Command = | * = +---------------------------------------------------------------+ */ #define IOCPARM_SHIFT 13 /* number of bits for ioctl size = */ #define IOCPARM_MASK ((1 << IOCPARM_SHIFT) - 1) /* parameter length = mask */ #define IOCPARM_LEN(x) (((x) >> 16) & IOCPARM_MASK) #define IOCBASECMD(x) ((x) & ~(IOCPARM_MASK << 16)) #define IOCGROUP(x) (((x) >> 8) & 0xff) #define IOCPARM_MAX (1 << IOCPARM_SHIFT) /* max size of ioctl */ #define IOC_VOID 0x20000000UL /* no parameters */ #define IOC_OUT 0x40000000UL /* copy out parameters */ #define IOC_IN 0x80000000UL /* copy in parameters */ #define IOC_INOUT (IOC_IN|IOC_OUT)/* copy parameters in and out */ #define IOC_DIRMASK (IOC_VOID|IOC_OUT|IOC_IN)/* mask for IN/OUT/VOID = */ . . . So, com =3D=3D 0xc0045006u ends up with: I/O matching: : IOC_IN | IOC_OUT Command matching (byte): 0x06u Command Group matching (byte): 0x50u Parameter Length matching : 0x0004u While I do not know the specifics for the command and command group encoding, the truncated value seems coherent with the code that is using it. My guess would be xoscope used a signed 32-bit type that got a value with sign extension to 64 bits before the value started being treated as unsigned. If it had used an unsigned type instead, the padding would have been a zero fill instead (presuming that I've guessed right). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)