From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751784AbdJYH1O (ORCPT ); Wed, 25 Oct 2017 03:27:14 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:46238 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751557AbdJYH1L (ORCPT ); Wed, 25 Oct 2017 03:27:11 -0400 X-Google-Smtp-Source: ABhQp+SOL/4M8CimyyktuEgoVidEK6nmrS6ShYpD4MSRhIKmHaffVzY+psAeewEFKpEvEtiYlfFzOw== Date: Wed, 25 Oct 2017 10:27:07 +0300 From: Cyrill Gorcunov To: Andrei Vagin Cc: NETDEV , LKML , Andrey Vagin , "David S. Miller" , Pavel Emelyanov Subject: Re: [RFC] net/unix_diag: Provide UDIAG_SHOW_VFS2 attribute to fetch complete inode number Message-ID: <20171025072707.GA3102@uranus> References: <20171024214814.GO5343@uranus> <20171025002509.GA12438@outlook.office365.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171025002509.GA12438@outlook.office365.com> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 24, 2017 at 05:25:16PM -0700, Andrei Vagin wrote: > On Wed, Oct 25, 2017 at 12:48:14AM +0300, Cyrill Gorcunov wrote: > > Currently unix_diag_vfs structure reports unix socket inode > > as u32 value which of course doesn't fit to ino_t type and > > BTW: As far as I understand, it is not a problem right now, because > get_next_ino returns int. And I'm agree that it maybe a problem in a > future and it is better to be ready. > > > the number may be trimmed. Lets rather deprecate old UDIAG_SHOW_VFS > > interface and provide UDIAG_SHOW_VFS2 (with one field "__zero" reserved > > which we could extend in future). > > There is one more place where we return ino as u32: > > static int sk_diag_dump_peer(struct sock *sk, struct sk_buff *nlskb) > .... > return nla_put_u32(nlskb, UNIX_DIAG_PEER, ino); Managed to miss it, thanks! > > +struct unix_diag_vfs2 { > > + __u64 udiag_vfs_ino; > > + __u32 udiag_vfs_dev; > > + __u32 __zero; /* Reserve for future use */ > > How can a user understand whether this field is used or not? Checking out if it zero or not. > Each netlink attribute has its size in a header. Any attribute can be > extended, and users can understand which fields are filled by > a size of an attribute. Well, that's correct, but it implies that any extension has different size. I though of extending this structure (if ever needed) the way that same attribute may carry different structures equal in size and setting up @__zero field with some bit would help. On the other side it become more complex than needed, so now I think I should simply drop __zero out. Thanks for comments, Andrew! Cyrill