From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJdvg-0006ov-2o for qemu-devel@nongnu.org; Thu, 14 Jan 2016 04:10:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJdvb-0000qe-3Q for qemu-devel@nongnu.org; Thu, 14 Jan 2016 04:10:52 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:65354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJdva-0000q3-QA for qemu-devel@nongnu.org; Thu, 14 Jan 2016 04:10:47 -0500 References: <1452752664-11818-1-git-send-email-chengang@emindsoft.com.cn> <5697593A.5020304@vivier.eu> <569763EF.3010702@emindsoft.com.cn> From: Laurent Vivier Message-ID: <56976603.3090805@vivier.eu> Date: Thu, 14 Jan 2016 10:10:27 +0100 MIME-Version: 1.0 In-Reply-To: <569763EF.3010702@emindsoft.com.cn> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] linux-user/syscall.c: Let lv always match val in do_getsockopt() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chen Gang , riku.voipio@iki.fi Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, rth@twiddle.net Le 14/01/2016 10:01, Chen Gang a écrit : > On 2016年01月14日 16:15, Laurent Vivier wrote: >> Le 14/01/2016 07:24, chengang@emindsoft.com.cn a écrit : >>> From: Chen Gang >>> >>> After host_to_target_sock_type(), the length of val may be changed, so >>> calculate the related lv, too. >>> >>> Signed-off-by: Chen Gang >>> --- >>> linux-user/syscall.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c >>> index fcdca2a..0e95f35 100644 >>> --- a/linux-user/syscall.c >>> +++ b/linux-user/syscall.c >>> @@ -1841,6 +1841,7 @@ static abi_long do_getsockopt(int sockfd, int level, int optname, >>> return ret; >>> if (optname == SO_TYPE) { >>> val = host_to_target_sock_type(val); >>> + lv = (val >> 8) ? 4 : 1; >> >> It seems the kernel always returns sizeof(int) (for all archs), what is >> the aim of reducing the size ? >> > > I am not quite sure whether kernel always returns sizeof(int) (I guess, > it should be). it can be 1 only if len is 1, but this is managed below. > For me, if you are sure, we can skip this patch. Does it fix something ? Laurent