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
