All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: David Miller <davem@davemloft.net>,
	Xin Long <lucien.xin@gmail.com>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	netdev@vger.kernel.org, linux-sctp@vger.kernel.org
Subject: Re: [PATCH v3 1/3] sctp: Export struct sctp_info to userspace
Date: Thu, 04 Aug 2016 14:40:21 +0000	[thread overview]
Message-ID: <20160804144021.GD8988@orbyte.nwl.cc> (raw)
In-Reply-To: <20160804133329.GA11579@hmsreliant.think-freely.org>

On Thu, Aug 04, 2016 at 09:33:29AM -0400, Neil Horman wrote:
> On Thu, Aug 04, 2016 at 12:11:55PM +0200, Phil Sutter wrote:
> > This is required to correctly interpret INET_DIAG_INFO messages exported
> > by sctp_diag module.
> > 
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> >  include/linux/sctp.h      | 64 -----------------------------------------------
> >  include/uapi/linux/sctp.h | 64 +++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 64 insertions(+), 64 deletions(-)
> > 
> > diff --git a/include/linux/sctp.h b/include/linux/sctp.h
> > index de1f64318fc4e..fcb4c36461732 100644
> > --- a/include/linux/sctp.h
> > +++ b/include/linux/sctp.h
> > @@ -705,70 +705,6 @@ typedef struct sctp_auth_chunk {
> >  	sctp_authhdr_t auth_hdr;
> >  } __packed sctp_auth_chunk_t;
> >  
> > -struct sctp_info {
> > -	__u32	sctpi_tag;
> > -	__u32	sctpi_state;
> > -	__u32	sctpi_rwnd;
> > -	__u16	sctpi_unackdata;
> > -	__u16	sctpi_penddata;
> > -	__u16	sctpi_instrms;
> > -	__u16	sctpi_outstrms;
> > -	__u32	sctpi_fragmentation_point;
> > -	__u32	sctpi_inqueue;
> > -	__u32	sctpi_outqueue;
> > -	__u32	sctpi_overall_error;
> > -	__u32	sctpi_max_burst;
> > -	__u32	sctpi_maxseg;
> > -	__u32	sctpi_peer_rwnd;
> > -	__u32	sctpi_peer_tag;
> > -	__u8	sctpi_peer_capable;
> > -	__u8	sctpi_peer_sack;
> > -	__u16	__reserved1;
> > -
> > -	/* assoc status info */
> > -	__u64	sctpi_isacks;
> > -	__u64	sctpi_osacks;
> > -	__u64	sctpi_opackets;
> > -	__u64	sctpi_ipackets;
> > -	__u64	sctpi_rtxchunks;
> > -	__u64	sctpi_outofseqtsns;
> > -	__u64	sctpi_idupchunks;
> > -	__u64	sctpi_gapcnt;
> > -	__u64	sctpi_ouodchunks;
> > -	__u64	sctpi_iuodchunks;
> > -	__u64	sctpi_oodchunks;
> > -	__u64	sctpi_iodchunks;
> > -	__u64	sctpi_octrlchunks;
> > -	__u64	sctpi_ictrlchunks;
> > -
> > -	/* primary transport info */
> > -	struct sockaddr_storage	sctpi_p_address;
> > -	__s32	sctpi_p_state;
> > -	__u32	sctpi_p_cwnd;
> > -	__u32	sctpi_p_srtt;
> > -	__u32	sctpi_p_rto;
> > -	__u32	sctpi_p_hbinterval;
> > -	__u32	sctpi_p_pathmaxrxt;
> > -	__u32	sctpi_p_sackdelay;
> > -	__u32	sctpi_p_sackfreq;
> > -	__u32	sctpi_p_ssthresh;
> > -	__u32	sctpi_p_partial_bytes_acked;
> > -	__u32	sctpi_p_flight_size;
> > -	__u16	sctpi_p_error;
> > -	__u16	__reserved2;
> > -
> > -	/* sctp sock info */
> > -	__u32	sctpi_s_autoclose;
> > -	__u32	sctpi_s_adaptation_ind;
> > -	__u32	sctpi_s_pd_point;
> > -	__u8	sctpi_s_nodelay;
> > -	__u8	sctpi_s_disable_fragments;
> > -	__u8	sctpi_s_v4mapped;
> > -	__u8	sctpi_s_frag_interleave;
> > -	__u32	sctpi_s_type;
> > -	__u32	__reserved3;
> > -};
> > -
> >  struct sctp_infox {
> >  	struct sctp_info *sctpinfo;
> >  	struct sctp_association *asoc;
> > diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> > index d304f4c9792c4..a406adcc0793e 100644
> > --- a/include/uapi/linux/sctp.h
> > +++ b/include/uapi/linux/sctp.h
> > @@ -944,4 +944,68 @@ struct sctp_default_prinfo {
> >  	__u16 pr_policy;
> >  };
> >  
> > +struct sctp_info {
> > +	__u32	sctpi_tag;
> > +	__u32	sctpi_state;
> > +	__u32	sctpi_rwnd;
> > +	__u16	sctpi_unackdata;
> > +	__u16	sctpi_penddata;
> > +	__u16	sctpi_instrms;
> > +	__u16	sctpi_outstrms;
> > +	__u32	sctpi_fragmentation_point;
> > +	__u32	sctpi_inqueue;
> > +	__u32	sctpi_outqueue;
> > +	__u32	sctpi_overall_error;
> > +	__u32	sctpi_max_burst;
> > +	__u32	sctpi_maxseg;
> > +	__u32	sctpi_peer_rwnd;
> > +	__u32	sctpi_peer_tag;
> > +	__u8	sctpi_peer_capable;
> > +	__u8	sctpi_peer_sack;
> > +	__u16	__reserved1;
> > +
> > +	/* assoc status info */
> > +	__u64	sctpi_isacks;
> > +	__u64	sctpi_osacks;
> > +	__u64	sctpi_opackets;
> > +	__u64	sctpi_ipackets;
> > +	__u64	sctpi_rtxchunks;
> > +	__u64	sctpi_outofseqtsns;
> > +	__u64	sctpi_idupchunks;
> > +	__u64	sctpi_gapcnt;
> > +	__u64	sctpi_ouodchunks;
> > +	__u64	sctpi_iuodchunks;
> > +	__u64	sctpi_oodchunks;
> > +	__u64	sctpi_iodchunks;
> > +	__u64	sctpi_octrlchunks;
> > +	__u64	sctpi_ictrlchunks;
> > +
> > +	/* primary transport info */
> > +	struct sockaddr_storage	sctpi_p_address;
> > +	__s32	sctpi_p_state;
> > +	__u32	sctpi_p_cwnd;
> > +	__u32	sctpi_p_srtt;
> > +	__u32	sctpi_p_rto;
> > +	__u32	sctpi_p_hbinterval;
> > +	__u32	sctpi_p_pathmaxrxt;
> > +	__u32	sctpi_p_sackdelay;
> > +	__u32	sctpi_p_sackfreq;
> > +	__u32	sctpi_p_ssthresh;
> > +	__u32	sctpi_p_partial_bytes_acked;
> > +	__u32	sctpi_p_flight_size;
> > +	__u16	sctpi_p_error;
> > +	__u16	__reserved2;
> > +
> > +	/* sctp sock info */
> > +	__u32	sctpi_s_autoclose;
> > +	__u32	sctpi_s_adaptation_ind;
> > +	__u32	sctpi_s_pd_point;
> > +	__u8	sctpi_s_nodelay;
> > +	__u8	sctpi_s_disable_fragments;
> > +	__u8	sctpi_s_v4mapped;
> > +	__u8	sctpi_s_frag_interleave;
> > +	__u32	sctpi_s_type;
> > +	__u32	__reserved3;
> > +};
> > +
> If you export these, shouldn't they be converted to the corresponding
> uint<size>_t variants?

As mentioned earlier, uapi headers using the __u* types seems not
uncommon. Another aspect is consistency, these types are used throughout
the whole file already, so if I should change them, they all should be
changed. And assuming uapi/linux/tcp.h being a good example: struct
tcp_info uses them also.

Cheers, Phil

WARNING: multiple messages have this Message-ID (diff)
From: Phil Sutter <phil@nwl.cc>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: David Miller <davem@davemloft.net>,
	Xin Long <lucien.xin@gmail.com>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	netdev@vger.kernel.org, linux-sctp@vger.kernel.org
Subject: Re: [PATCH v3 1/3] sctp: Export struct sctp_info to userspace
Date: Thu, 4 Aug 2016 16:40:21 +0200	[thread overview]
Message-ID: <20160804144021.GD8988@orbyte.nwl.cc> (raw)
In-Reply-To: <20160804133329.GA11579@hmsreliant.think-freely.org>

On Thu, Aug 04, 2016 at 09:33:29AM -0400, Neil Horman wrote:
> On Thu, Aug 04, 2016 at 12:11:55PM +0200, Phil Sutter wrote:
> > This is required to correctly interpret INET_DIAG_INFO messages exported
> > by sctp_diag module.
> > 
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> >  include/linux/sctp.h      | 64 -----------------------------------------------
> >  include/uapi/linux/sctp.h | 64 +++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 64 insertions(+), 64 deletions(-)
> > 
> > diff --git a/include/linux/sctp.h b/include/linux/sctp.h
> > index de1f64318fc4e..fcb4c36461732 100644
> > --- a/include/linux/sctp.h
> > +++ b/include/linux/sctp.h
> > @@ -705,70 +705,6 @@ typedef struct sctp_auth_chunk {
> >  	sctp_authhdr_t auth_hdr;
> >  } __packed sctp_auth_chunk_t;
> >  
> > -struct sctp_info {
> > -	__u32	sctpi_tag;
> > -	__u32	sctpi_state;
> > -	__u32	sctpi_rwnd;
> > -	__u16	sctpi_unackdata;
> > -	__u16	sctpi_penddata;
> > -	__u16	sctpi_instrms;
> > -	__u16	sctpi_outstrms;
> > -	__u32	sctpi_fragmentation_point;
> > -	__u32	sctpi_inqueue;
> > -	__u32	sctpi_outqueue;
> > -	__u32	sctpi_overall_error;
> > -	__u32	sctpi_max_burst;
> > -	__u32	sctpi_maxseg;
> > -	__u32	sctpi_peer_rwnd;
> > -	__u32	sctpi_peer_tag;
> > -	__u8	sctpi_peer_capable;
> > -	__u8	sctpi_peer_sack;
> > -	__u16	__reserved1;
> > -
> > -	/* assoc status info */
> > -	__u64	sctpi_isacks;
> > -	__u64	sctpi_osacks;
> > -	__u64	sctpi_opackets;
> > -	__u64	sctpi_ipackets;
> > -	__u64	sctpi_rtxchunks;
> > -	__u64	sctpi_outofseqtsns;
> > -	__u64	sctpi_idupchunks;
> > -	__u64	sctpi_gapcnt;
> > -	__u64	sctpi_ouodchunks;
> > -	__u64	sctpi_iuodchunks;
> > -	__u64	sctpi_oodchunks;
> > -	__u64	sctpi_iodchunks;
> > -	__u64	sctpi_octrlchunks;
> > -	__u64	sctpi_ictrlchunks;
> > -
> > -	/* primary transport info */
> > -	struct sockaddr_storage	sctpi_p_address;
> > -	__s32	sctpi_p_state;
> > -	__u32	sctpi_p_cwnd;
> > -	__u32	sctpi_p_srtt;
> > -	__u32	sctpi_p_rto;
> > -	__u32	sctpi_p_hbinterval;
> > -	__u32	sctpi_p_pathmaxrxt;
> > -	__u32	sctpi_p_sackdelay;
> > -	__u32	sctpi_p_sackfreq;
> > -	__u32	sctpi_p_ssthresh;
> > -	__u32	sctpi_p_partial_bytes_acked;
> > -	__u32	sctpi_p_flight_size;
> > -	__u16	sctpi_p_error;
> > -	__u16	__reserved2;
> > -
> > -	/* sctp sock info */
> > -	__u32	sctpi_s_autoclose;
> > -	__u32	sctpi_s_adaptation_ind;
> > -	__u32	sctpi_s_pd_point;
> > -	__u8	sctpi_s_nodelay;
> > -	__u8	sctpi_s_disable_fragments;
> > -	__u8	sctpi_s_v4mapped;
> > -	__u8	sctpi_s_frag_interleave;
> > -	__u32	sctpi_s_type;
> > -	__u32	__reserved3;
> > -};
> > -
> >  struct sctp_infox {
> >  	struct sctp_info *sctpinfo;
> >  	struct sctp_association *asoc;
> > diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> > index d304f4c9792c4..a406adcc0793e 100644
> > --- a/include/uapi/linux/sctp.h
> > +++ b/include/uapi/linux/sctp.h
> > @@ -944,4 +944,68 @@ struct sctp_default_prinfo {
> >  	__u16 pr_policy;
> >  };
> >  
> > +struct sctp_info {
> > +	__u32	sctpi_tag;
> > +	__u32	sctpi_state;
> > +	__u32	sctpi_rwnd;
> > +	__u16	sctpi_unackdata;
> > +	__u16	sctpi_penddata;
> > +	__u16	sctpi_instrms;
> > +	__u16	sctpi_outstrms;
> > +	__u32	sctpi_fragmentation_point;
> > +	__u32	sctpi_inqueue;
> > +	__u32	sctpi_outqueue;
> > +	__u32	sctpi_overall_error;
> > +	__u32	sctpi_max_burst;
> > +	__u32	sctpi_maxseg;
> > +	__u32	sctpi_peer_rwnd;
> > +	__u32	sctpi_peer_tag;
> > +	__u8	sctpi_peer_capable;
> > +	__u8	sctpi_peer_sack;
> > +	__u16	__reserved1;
> > +
> > +	/* assoc status info */
> > +	__u64	sctpi_isacks;
> > +	__u64	sctpi_osacks;
> > +	__u64	sctpi_opackets;
> > +	__u64	sctpi_ipackets;
> > +	__u64	sctpi_rtxchunks;
> > +	__u64	sctpi_outofseqtsns;
> > +	__u64	sctpi_idupchunks;
> > +	__u64	sctpi_gapcnt;
> > +	__u64	sctpi_ouodchunks;
> > +	__u64	sctpi_iuodchunks;
> > +	__u64	sctpi_oodchunks;
> > +	__u64	sctpi_iodchunks;
> > +	__u64	sctpi_octrlchunks;
> > +	__u64	sctpi_ictrlchunks;
> > +
> > +	/* primary transport info */
> > +	struct sockaddr_storage	sctpi_p_address;
> > +	__s32	sctpi_p_state;
> > +	__u32	sctpi_p_cwnd;
> > +	__u32	sctpi_p_srtt;
> > +	__u32	sctpi_p_rto;
> > +	__u32	sctpi_p_hbinterval;
> > +	__u32	sctpi_p_pathmaxrxt;
> > +	__u32	sctpi_p_sackdelay;
> > +	__u32	sctpi_p_sackfreq;
> > +	__u32	sctpi_p_ssthresh;
> > +	__u32	sctpi_p_partial_bytes_acked;
> > +	__u32	sctpi_p_flight_size;
> > +	__u16	sctpi_p_error;
> > +	__u16	__reserved2;
> > +
> > +	/* sctp sock info */
> > +	__u32	sctpi_s_autoclose;
> > +	__u32	sctpi_s_adaptation_ind;
> > +	__u32	sctpi_s_pd_point;
> > +	__u8	sctpi_s_nodelay;
> > +	__u8	sctpi_s_disable_fragments;
> > +	__u8	sctpi_s_v4mapped;
> > +	__u8	sctpi_s_frag_interleave;
> > +	__u32	sctpi_s_type;
> > +	__u32	__reserved3;
> > +};
> > +
> If you export these, shouldn't they be converted to the corresponding
> uint<size>_t variants?

As mentioned earlier, uapi headers using the __u* types seems not
uncommon. Another aspect is consistency, these types are used throughout
the whole file already, so if I should change them, they all should be
changed. And assuming uapi/linux/tcp.h being a good example: struct
tcp_info uses them also.

Cheers, Phil

  reply	other threads:[~2016-08-04 14:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-04 10:11 [PATCH v3 0/3] sctp_diag: A bunch of fixes for upcoming 'ss' support Phil Sutter
2016-08-04 10:11 ` Phil Sutter
2016-08-04 10:11 ` [PATCH v3 1/3] sctp: Export struct sctp_info to userspace Phil Sutter
2016-08-04 10:11   ` Phil Sutter
2016-08-04 13:33   ` Neil Horman
2016-08-04 13:33     ` Neil Horman
2016-08-04 14:40     ` Phil Sutter [this message]
2016-08-04 14:40       ` Phil Sutter
2016-08-04 10:11 ` [PATCH v3 2/3] sctp_diag: Fix T3_rtx timer export Phil Sutter
2016-08-04 10:11   ` Phil Sutter
2016-08-04 10:11 ` [PATCH v3 3/3] sctp_diag: Respect ss adding TCPF_CLOSE to idiag_states Phil Sutter
2016-08-04 10:11   ` Phil Sutter
2016-08-04 12:36 ` [PATCH v3 0/3] sctp_diag: A bunch of fixes for upcoming 'ss' support Marcelo Ricardo Leitner
2016-08-04 12:36   ` Marcelo Ricardo Leitner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160804144021.GD8988@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.