Re: [PATCH 1/1] linux-user/syscall: Fix do_ioctl_ifconf() for 64 bit targets.

[Stefan]

Hi Laurent!

Thanks for your response.

> Why don't you simply replace STRUCT_sockaddr_ifreq by STRUCT_ifmap_ifreq 
> rather than introducing a
> new constant?

Because STRUCT_sockaddr_ifreq is the union part to be filled and is needed as 
an argument to thunk_convert() in this loop below:

            for (i = 0; i < nb_ifreq ; i++) {
                thunk_convert(argptr + i * target_ifreq_size,
                              host_ifc_buf + i * sizeof(struct ifreq),
                              ifreq_arg_type, THUNK_TARGET);
            }

> In the "if (!is_error(ret))", why don't you use the same size with the part 
> that copies back the
> values to the user?

I’m not sure if I understand your question correctly. Well, ioclt(…, 
SIOCGIFCONF, …) returns an array of struct ifreq, which contains a union, of 
which only struct sockaddr ifr_addr needs to be filled. But that union element 
is not the biggest element on 64 bit architectures.

Without the fix the returned data is not an array of struct ifreq but an array 
of some artificial struct:

struct sockaddr_ifreq {
    char ifr_name[IFNAMSIZ]; /* Interface name */
    struct sockaddr ifr_addr;
}

That artificial struct is too short for 64 bit architectures. On real x86_64 
systems the size of the array returned by ioclt(…, SIOCGIFCONF, …) is a 
multiple of 40 bytes, the sizeof(struct ifreq). And it’s also a multiple of 40 
on real aarch64 systems. However, on x86_64 emulating aarch64 with qemu, the 
returned array size is only a multiple of 32 bytes, which is wrong. It is 
enough to fill only 32 bytes with thunk_convert() and ifreq_arg_type is also 
the proper type, but the array element increase has to be 40 bytes.

I hope this clarifies your question.


Bye

Stefan