From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr2qO-0005rM-TD for qemu-devel@nongnu.org; Tue, 27 Oct 2015 07:55:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr2qK-0003pK-45 for qemu-devel@nongnu.org; Tue, 27 Oct 2015 07:55:12 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:61747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr2qJ-0003p9-UE for qemu-devel@nongnu.org; Tue, 27 Oct 2015 07:55:08 -0400 References: <1444151509-5047-1-git-send-email-laurent@vivier.eu> <562EEAD4.7070706@vivier.eu> From: Laurent Vivier Message-ID: <562F6612.8040103@vivier.eu> Date: Tue, 27 Oct 2015 12:54:58 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] linux-user: manage SOCK_PACKET socket type. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Riku Voipio , QEMU Developers Le 27/10/2015 12:50, Peter Maydell a écrit : > On 27 October 2015 at 03:09, Laurent Vivier wrote: >> Le 26/10/2015 15:40, Peter Maydell a écrit : >>> This confuses me. The packet(7) manpage suggests there are two flavours >>> of packet socket: >>> (1) legacy AF_INET + SOCK_PACKET >>> (2) new style AF_PACKET + SOCK_RAW / SOCK_DGRAM >>> >>> but this comment suggests it's trying to handle AF_PACKET + SOCK_PACKET ? >> >> In fact, I've started not from the man page, but from a non working dhcp >> client, originally with a m68k target and etch-m68k distro, and I've met >> again this problem on a ppc target and jessie distro. > >> kernel 4.3.0-rc3, net/packet/af_packet.c: >> >> 2961 >> 2962 static int packet_bind_spkt(struct socket *sock, struct sockaddr >> *uaddr, >> 2963 int addr_len) >> 2964 { >> 2965 struct sock *sk = sock->sk; >> 2966 char name[15]; >> 2967 struct net_device *dev; >> 2968 int err = -ENODEV; >> 2969 >> 2970 /* >> 2971 * Check legality >> 2972 */ >> 2973 >> 2974 if (addr_len != sizeof(struct sockaddr)) >> 2975 return -EINVAL; >> 2976 strlcpy(name, uaddr->sa_data, sizeof(name)); >> 2977 >> 2978 dev = dev_get_by_name(sock_net(sk), name); >> 2979 if (dev) >> 2980 err = packet_do_bind(sk, dev, pkt_sk(sk)->num); >> 2981 return err; >> 2982 } >> ... >> 4246 static const struct proto_ops packet_ops_spkt = { >> 4247 .family = PF_PACKET, >> ... >> 4250 .bind = packet_bind_spkt, >> ... >> 3022 >> 3023 static int packet_create(struct net *net, struct socket *sock, >> int protocol, >> 3024 int kern) >> ... >> 3045 if (sock->type == SOCK_PACKET) >> 3046 sock->ops = &packet_ops_spkt; >> ... > > Yes, but also: > http://lxr.free-electrons.com/source/net/socket.c#L1109 > > 1114 if (family == PF_INET && type == SOCK_PACKET) { > 1115 static int warned; > 1116 if (!warned) { > 1117 warned = 1; > 1118 pr_info("%s uses obsolete (PF_INET,SOCK_PACKET)\n", > 1119 current->comm); > 1120 } > 1121 family = PF_PACKET; > 1122 } > > So I think my conclusion is: > * Original 2.0 kernels used PF_INET + SOCK_PACKET > * When the non-legacy stuff was added and this compat warning > came in, the (accidental?) result was that PF_PACKET + SOCK_PACKET > gave a warning, PF_PACKET + SOCK_PACKET gave legacy behaviour > without a warning, and PF_PACKET + SOCK_RAW/SOCK_DGRAM gave > the new interface > * Some userspace programs responded not by updating to the new > non-legacy interface, but by moving to PF_PACKET + SOCK_PACKET > which just suppresses the warning > > So we should special case both PF_INET + SOCK_PACKET and > PF_PACKET + SOCK_PACKET (but not any other PF_* + SOCK_PACKET). I'll try that too... Laurent