[net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[Michele Baldessari]

It is often quite helpful to be able to know the state of a transport
outside of the application itself (for troubleshooting purposes or for
monitoring purposes). Add it under /proc/net/sctp/remaddr.

Signed-off-by: Michele Baldessari <michele@acksyn.org>
---
 net/sctp/proc.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index 34229ee7f379..bfb242af06ab 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -417,7 +417,7 @@ static void *sctp_remaddr_seq_start(struct seq_file *seq, loff_t *pos)
 
 	if (*pos == 0)
 		seq_printf(seq, "ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX "
-				"REM_ADDR_RTX  START\n");
+				"REM_ADDR_RTX START STATE\n");
 
 	return (void *)pos;
 }
@@ -497,7 +497,13 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
 			 * currently implemented, but we can record it with a
 			 * jiffies marker in a subsequent patch
 			 */
-			seq_printf(seq, "0");
+			seq_printf(seq, "0 ");
+
+			/*
+			 * The current state of this destination. I.e.
+			 * SCTP_ACTIVE, SCTP_INACTIVE, ...
+			 */
+			seq_printf(seq, "%d", tsp->state);
 
 			seq_printf(seq, "\n");
 		}
-- 
2.1.0

[net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[Michele Baldessari]

It is often quite helpful to be able to know the state of a transport
outside of the application itself (for troubleshooting purposes or for
monitoring purposes). Add it under /proc/net/sctp/remaddr.

Signed-off-by: Michele Baldessari <michele@acksyn.org>
---
 net/sctp/proc.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index 34229ee7f379..bfb242af06ab 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -417,7 +417,7 @@ static void *sctp_remaddr_seq_start(struct seq_file *seq, loff_t *pos)
 
 	if (*pos = 0)
 		seq_printf(seq, "ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX "
-				"REM_ADDR_RTX  START\n");
+				"REM_ADDR_RTX START STATE\n");
 
 	return (void *)pos;
 }
@@ -497,7 +497,13 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
 			 * currently implemented, but we can record it with a
 			 * jiffies marker in a subsequent patch
 			 */
-			seq_printf(seq, "0");
+			seq_printf(seq, "0 ");
+
+			/*
+			 * The current state of this destination. I.e.
+			 * SCTP_ACTIVE, SCTP_INACTIVE, ...
+			 */
+			seq_printf(seq, "%d", tsp->state);
 
 			seq_printf(seq, "\n");
 		}
-- 
2.1.0

[net 2/2] sctp: replace seq_printf with seq_puts

[Michele Baldessari]

Fixes checkpatch warning:
"WARNING: Prefer seq_puts to seq_printf"

Signed-off-by: Michele Baldessari <michele@acksyn.org>
---
 net/sctp/proc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index bfb242af06ab..0697eda5aed8 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -490,14 +490,14 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
 			 * Note: We don't have a way to tally this at the moment
 			 * so lets just leave it as zero for the moment
 			 */
-			seq_printf(seq, "0 ");
+			seq_puts(seq, "0 ");
 
 			/*
 			 * remote address start time (START).  This is also not
 			 * currently implemented, but we can record it with a
 			 * jiffies marker in a subsequent patch
 			 */
-			seq_printf(seq, "0 ");
+			seq_puts(seq, "0 ");
 
 			/*
 			 * The current state of this destination. I.e.
-- 
2.1.0

[net 2/2] sctp: replace seq_printf with seq_puts

[Michele Baldessari]

Fixes checkpatch warning:
"WARNING: Prefer seq_puts to seq_printf"

Signed-off-by: Michele Baldessari <michele@acksyn.org>
---
 net/sctp/proc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index bfb242af06ab..0697eda5aed8 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -490,14 +490,14 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
 			 * Note: We don't have a way to tally this at the moment
 			 * so lets just leave it as zero for the moment
 			 */
-			seq_printf(seq, "0 ");
+			seq_puts(seq, "0 ");
 
 			/*
 			 * remote address start time (START).  This is also not
 			 * currently implemented, but we can record it with a
 			 * jiffies marker in a subsequent patch
 			 */
-			seq_printf(seq, "0 ");
+			seq_puts(seq, "0 ");
 
 			/*
 			 * The current state of this destination. I.e.
-- 
2.1.0

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[Neil Horman]

On Thu, Oct 23, 2014 at 09:48:40PM +0200, Michele Baldessari wrote:
> It is often quite helpful to be able to know the state of a transport
> outside of the application itself (for troubleshooting purposes or for
> monitoring purposes). Add it under /proc/net/sctp/remaddr.
> 
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
> ---
>  net/sctp/proc.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index 34229ee7f379..bfb242af06ab 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -417,7 +417,7 @@ static void *sctp_remaddr_seq_start(struct seq_file *seq, loff_t *pos)
>  
>  	if (*pos == 0)
>  		seq_printf(seq, "ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX "
> -				"REM_ADDR_RTX  START\n");
> +				"REM_ADDR_RTX START STATE\n");
>  
>  	return (void *)pos;
>  }
> @@ -497,7 +497,13 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
>  			 * currently implemented, but we can record it with a
>  			 * jiffies marker in a subsequent patch
>  			 */
> -			seq_printf(seq, "0");
> +			seq_printf(seq, "0 ");
> +
> +			/*
> +			 * The current state of this destination. I.e.
> +			 * SCTP_ACTIVE, SCTP_INACTIVE, ...
> +			 */
> +			seq_printf(seq, "%d", tsp->state);
>  
>  			seq_printf(seq, "\n");
>  		}
> -- 
> 2.1.0
> 
> 

Acked-by: Neil Horman <nhorman@tuxdriver.com>

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[Neil Horman]

On Thu, Oct 23, 2014 at 09:48:40PM +0200, Michele Baldessari wrote:
> It is often quite helpful to be able to know the state of a transport
> outside of the application itself (for troubleshooting purposes or for
> monitoring purposes). Add it under /proc/net/sctp/remaddr.
> 
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
> ---
>  net/sctp/proc.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index 34229ee7f379..bfb242af06ab 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -417,7 +417,7 @@ static void *sctp_remaddr_seq_start(struct seq_file *seq, loff_t *pos)
>  
>  	if (*pos = 0)
>  		seq_printf(seq, "ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX "
> -				"REM_ADDR_RTX  START\n");
> +				"REM_ADDR_RTX START STATE\n");
>  
>  	return (void *)pos;
>  }
> @@ -497,7 +497,13 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
>  			 * currently implemented, but we can record it with a
>  			 * jiffies marker in a subsequent patch
>  			 */
> -			seq_printf(seq, "0");
> +			seq_printf(seq, "0 ");
> +
> +			/*
> +			 * The current state of this destination. I.e.
> +			 * SCTP_ACTIVE, SCTP_INACTIVE, ...
> +			 */
> +			seq_printf(seq, "%d", tsp->state);
>  
>  			seq_printf(seq, "\n");
>  		}
> -- 
> 2.1.0
> 
> 

Acked-by: Neil Horman <nhorman@tuxdriver.com>

Re: [net 2/2] sctp: replace seq_printf with seq_puts

[Neil Horman]

On Thu, Oct 23, 2014 at 09:48:41PM +0200, Michele Baldessari wrote:
> Fixes checkpatch warning:
> "WARNING: Prefer seq_puts to seq_printf"
> 
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
> ---
>  net/sctp/proc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index bfb242af06ab..0697eda5aed8 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -490,14 +490,14 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
>  			 * Note: We don't have a way to tally this at the moment
>  			 * so lets just leave it as zero for the moment
>  			 */
> -			seq_printf(seq, "0 ");
> +			seq_puts(seq, "0 ");
>  
>  			/*
>  			 * remote address start time (START).  This is also not
>  			 * currently implemented, but we can record it with a
>  			 * jiffies marker in a subsequent patch
>  			 */
> -			seq_printf(seq, "0 ");
> +			seq_puts(seq, "0 ");
>  
>  			/*
>  			 * The current state of this destination. I.e.
> -- 
> 2.1.0
> 
> 
Acked-by: Neil Horman <nhorman@tuxdriver.com>

Re: [net 2/2] sctp: replace seq_printf with seq_puts

[Neil Horman]

On Thu, Oct 23, 2014 at 09:48:41PM +0200, Michele Baldessari wrote:
> Fixes checkpatch warning:
> "WARNING: Prefer seq_puts to seq_printf"
> 
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
> ---
>  net/sctp/proc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index bfb242af06ab..0697eda5aed8 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -490,14 +490,14 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
>  			 * Note: We don't have a way to tally this at the moment
>  			 * so lets just leave it as zero for the moment
>  			 */
> -			seq_printf(seq, "0 ");
> +			seq_puts(seq, "0 ");
>  
>  			/*
>  			 * remote address start time (START).  This is also not
>  			 * currently implemented, but we can record it with a
>  			 * jiffies marker in a subsequent patch
>  			 */
> -			seq_printf(seq, "0 ");
> +			seq_puts(seq, "0 ");
>  
>  			/*
>  			 * The current state of this destination. I.e.
> -- 
> 2.1.0
> 
> 
Acked-by: Neil Horman <nhorman@tuxdriver.com>

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[David Miller]

From: Michele Baldessari <michele@acksyn.org>
Date: Thu, 23 Oct 2014 21:48:40 +0200

> It is often quite helpful to be able to know the state of a transport
> outside of the application itself (for troubleshooting purposes or for
> monitoring purposes). Add it under /proc/net/sctp/remaddr.
> 
> Signed-off-by: Michele Baldessari <michele@acksyn.org>

You can't change the layout of procfs files, applications parse
these files and any modification can potentially break such tools.

Secondly, even if this change were acceptable, targetting this
change at anything other than the net-next tree is not appropriate
because it is a new feature.

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[David Miller]

From: Michele Baldessari <michele@acksyn.org>
Date: Thu, 23 Oct 2014 21:48:40 +0200

> It is often quite helpful to be able to know the state of a transport
> outside of the application itself (for troubleshooting purposes or for
> monitoring purposes). Add it under /proc/net/sctp/remaddr.
> 
> Signed-off-by: Michele Baldessari <michele@acksyn.org>

You can't change the layout of procfs files, applications parse
these files and any modification can potentially break such tools.

Secondly, even if this change were acceptable, targetting this
change at anything other than the net-next tree is not appropriate
because it is a new feature.

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[Michele Baldessari]

Hi David,

On Mon, Oct 27, 2014 at 06:55:45PM -0400, David Miller wrote:
> From: Michele Baldessari <michele@acksyn.org>
> Date: Thu, 23 Oct 2014 21:48:40 +0200
> 
> > It is often quite helpful to be able to know the state of a transport
> > outside of the application itself (for troubleshooting purposes or for
> > monitoring purposes). Add it under /proc/net/sctp/remaddr.
> > 
> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
> 
> You can't change the layout of procfs files, applications parse
> these files and any modification can potentially break such tools.

Thanks for the review. I assumed that extending a procfile by adding
a column at the end is ok and that tools must cope with that anyway.
(i.e. like it's been done in f19c29e3e391a66a273e9afebaf01917245148cd)

> Secondly, even if this change were acceptable, targetting this
> change at anything other than the net-next tree is not appropriate
> because it is a new feature.

Ok. Unless you are against adding a column, I'll resubmit to net-next
later this week.

Thanks,
Michele
-- 
Michele Baldessari            <michele@acksyn.org>
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[Michele Baldessari]

Hi David,

On Mon, Oct 27, 2014 at 06:55:45PM -0400, David Miller wrote:
> From: Michele Baldessari <michele@acksyn.org>
> Date: Thu, 23 Oct 2014 21:48:40 +0200
> 
> > It is often quite helpful to be able to know the state of a transport
> > outside of the application itself (for troubleshooting purposes or for
> > monitoring purposes). Add it under /proc/net/sctp/remaddr.
> > 
> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
> 
> You can't change the layout of procfs files, applications parse
> these files and any modification can potentially break such tools.

Thanks for the review. I assumed that extending a procfile by adding
a column at the end is ok and that tools must cope with that anyway.
(i.e. like it's been done in f19c29e3e391a66a273e9afebaf01917245148cd)

> Secondly, even if this change were acceptable, targetting this
> change at anything other than the net-next tree is not appropriate
> because it is a new feature.

Ok. Unless you are against adding a column, I'll resubmit to net-next
later this week.

Thanks,
Michele
-- 
Michele Baldessari            <michele@acksyn.org>
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[Neil Horman]

On Mon, Oct 27, 2014 at 06:55:45PM -0400, David Miller wrote:
> From: Michele Baldessari <michele@acksyn.org>
> Date: Thu, 23 Oct 2014 21:48:40 +0200
> 
> > It is often quite helpful to be able to know the state of a transport
> > outside of the application itself (for troubleshooting purposes or for
> > monitoring purposes). Add it under /proc/net/sctp/remaddr.
> > 
> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
> 
> You can't change the layout of procfs files, applications parse
> these files and any modification can potentially break such tools.
> 
> Secondly, even if this change were acceptable, targetting this
> change at anything other than the net-next tree is not appropriate
> because it is a new feature.
> 

Agree on the net-next submission, though there is precident for extending this
procfile, as we've done it a few times in the past to this, and other files in
the sctp area (see commits f406c8b9693f2f71ef2caeb0b68521a7d22d00f0 and
58fbbed4fbc0094fc808a568fe99a915f85402ee)

Neil

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[Neil Horman]

On Mon, Oct 27, 2014 at 06:55:45PM -0400, David Miller wrote:
> From: Michele Baldessari <michele@acksyn.org>
> Date: Thu, 23 Oct 2014 21:48:40 +0200
> 
> > It is often quite helpful to be able to know the state of a transport
> > outside of the application itself (for troubleshooting purposes or for
> > monitoring purposes). Add it under /proc/net/sctp/remaddr.
> > 
> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
> 
> You can't change the layout of procfs files, applications parse
> these files and any modification can potentially break such tools.
> 
> Secondly, even if this change were acceptable, targetting this
> change at anything other than the net-next tree is not appropriate
> because it is a new feature.
> 

Agree on the net-next submission, though there is precident for extending this
procfile, as we've done it a few times in the past to this, and other files in
the sctp area (see commits f406c8b9693f2f71ef2caeb0b68521a7d22d00f0 and
58fbbed4fbc0094fc808a568fe99a915f85402ee)

Neil

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[David Miller]

From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 28 Oct 2014 06:27:41 -0400

> On Mon, Oct 27, 2014 at 06:55:45PM -0400, David Miller wrote:
>> From: Michele Baldessari <michele@acksyn.org>
>> Date: Thu, 23 Oct 2014 21:48:40 +0200
>> 
>> > It is often quite helpful to be able to know the state of a transport
>> > outside of the application itself (for troubleshooting purposes or for
>> > monitoring purposes). Add it under /proc/net/sctp/remaddr.
>> > 
>> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
>> 
>> You can't change the layout of procfs files, applications parse
>> these files and any modification can potentially break such tools.
>> 
>> Secondly, even if this change were acceptable, targetting this
>> change at anything other than the net-next tree is not appropriate
>> because it is a new feature.
>> 
> 
> Agree on the net-next submission, though there is precident for extending this
> procfile, as we've done it a few times in the past to this, and other files in
> the sctp area (see commits f406c8b9693f2f71ef2caeb0b68521a7d22d00f0 and
> 58fbbed4fbc0094fc808a568fe99a915f85402ee)

Fair enough.

Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr

[David Miller]

From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 28 Oct 2014 06:27:41 -0400

> On Mon, Oct 27, 2014 at 06:55:45PM -0400, David Miller wrote:
>> From: Michele Baldessari <michele@acksyn.org>
>> Date: Thu, 23 Oct 2014 21:48:40 +0200
>> 
>> > It is often quite helpful to be able to know the state of a transport
>> > outside of the application itself (for troubleshooting purposes or for
>> > monitoring purposes). Add it under /proc/net/sctp/remaddr.
>> > 
>> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
>> 
>> You can't change the layout of procfs files, applications parse
>> these files and any modification can potentially break such tools.
>> 
>> Secondly, even if this change were acceptable, targetting this
>> change at anything other than the net-next tree is not appropriate
>> because it is a new feature.
>> 
> 
> Agree on the net-next submission, though there is precident for extending this
> procfile, as we've done it a few times in the past to this, and other files in
> the sctp area (see commits f406c8b9693f2f71ef2caeb0b68521a7d22d00f0 and
> 58fbbed4fbc0094fc808a568fe99a915f85402ee)

Fair enough.