Re: Xoscope nuisance console messages on Pi4 running -current

Mark Millard via freebsd-arm <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm,gmane.os.freebsd.devel.ports
Message-ID <[email protected]>
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:
> 
> 
> +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
> 
> They seem to come at a fairly high rate and clutter the logfiles, but 
> apart from that nuisance nothing else seemed visibly amiss.
> 
> 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 = (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 == 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 == 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).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.