From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752897AbcI1Kvx (ORCPT ); Wed, 28 Sep 2016 06:51:53 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:34684 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752258AbcI1Kvv (ORCPT ); Wed, 28 Sep 2016 06:51:51 -0400 Date: Wed, 28 Sep 2016 13:51:47 +0300 From: Cyrill Gorcunov To: Jamal Hadi Salim Cc: Eric Dumazet , David Ahern , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, David Miller , kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net, avagin@openvz.org, stephen@networkplumber.org Subject: Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets Message-ID: <20160928105147.GV1876@uranus.lan> References: <20160928090357.GT1876@uranus.lan> <20160928101726.GU1876@uranus.lan> <8293413c-a81d-f7ff-24f0-8f58ce877116@mojatatu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8293413c-a81d-f7ff-24f0-8f58ce877116@mojatatu.com> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 28, 2016 at 06:43:01AM -0400, Jamal Hadi Salim wrote: ... > > > > Someone may have set it to zero explicitly on source level, and the > > compilation will fail on new kernel then. So no, keeping the name > > is reasonable. > > > > I dont know how compilation will fail but you may be right with note: > that is not how pads have been used in the past. They are supposed to > cosmetic annotation which indicates "here's a hole; use it in the > future if you are looking to add something". And someone in the > future can claim them. I am not sure if MBZ philosophy applies. This structure is uapi, so anyone has complete rights to reference @pad in the userspace programs. Sure it would be more clear to remove the @pad completely, but if we choose so I think it's better to do on top instead and then if someone complain we can easily revert the single trivial commit instead of this big patch. > > > > Should you not just rename it? > > > Also I notice when things like __raw_v4_lookup() are claiming it is unsigned > > > short instead of a u8? > > > > The protocol is still up to 255 for a while, is it expected that IPPROTO_MAX > > will be increased in more-less near future? Of course I can drop the idea > > of using @pad here and switch to some extended reauest but prefer to stick > > with simplier solution. Hm? > > > > Ok. If i understood correctly it was already unsigned short before your > patch -so i agree it doesnt matter. Maybe just put a comment to express > that if ever protocol goes above 255 it wont be sufficient. If protocol goes over u8 then complete inet_diag_req_v2 structure will have to be reworked becaue @sdiag_protocol is u8 as well. IOW, once someone liftup IPPROTO_MAX > 255, he will notice the problem immediately because diag for such module simply stop working properly.