Date: Mon, 3 May 2021 01:00:03 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Xoscope nuisance console messages on Pi4 running -current Message-ID: <263BF9DF-B22B-4579-9667-AFCB7D2D667C@yahoo.com> In-Reply-To: <20210503063701.GA34665@www.zefox.net> References: <20210503063701.GA34665@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-2, at 23:37, bob prohaska <fbsd at www.zefox.net> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?263BF9DF-B22B-4579-9667-AFCB7D2D667C>