Netdev List
 help / color / mirror / Atom feed
* [PATCH] irda: sir_dev: Fix copy/paste typo
From: Alexander Shiyan @ 2012-11-20 19:59 UTC (permalink / raw)
  To: netdev; +Cc: Samuel Ortiz, Alexander Shiyan


Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
 drivers/net/irda/sir_dev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/irda/sir_dev.c b/drivers/net/irda/sir_dev.c
index 5039f08..43e9ab4 100644
--- a/drivers/net/irda/sir_dev.c
+++ b/drivers/net/irda/sir_dev.c
@@ -222,7 +222,7 @@ static void sirdev_config_fsm(struct work_struct *work)
 			break;
 
 		case SIRDEV_STATE_DONGLE_SPEED:
-			if (dev->dongle_drv->reset) {
+			if (dev->dongle_drv->set_speed) {
 				ret = dev->dongle_drv->set_speed(dev, fsm->param);
 				if (ret < 0) {
 					fsm->result = ret;
-- 
1.7.8.6

^ permalink raw reply related

* Re: [PATCH v2] checkpatch: add double empty line check
From: Eilon Greenstein @ 2012-11-20 20:26 UTC (permalink / raw)
  To: Andy Whitcroft
  Cc: Joe Perches, David Rientjes, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <20121120201142.GI17797@dm>

On Tue, 2012-11-20 at 20:11 +0000, Andy Whitcroft wrote:
> > 
> > Actually the version I sent should indeed cope with the deleted lines
> > regardless of order.  It was cirtainly intended to.
> 
> ... and I think I thought of a couple more corner cases neither solution
> will find.  So I am going to go away and make up a proper set of tests
> for this apparently simple change.  As it is really annoying when it
> false positives.  I will post against when I have something which works.
> 

Thanks Andy!

I will assist in testing it on all the scenarios I have created once you
post it.

I appreciate you taking the time to look into adding a test for this
issue.

Thanks,
Eilon

^ permalink raw reply

* Re: [PATCH v2] sctp: send abort chunk when max_retrans exceeded
From: Vlad Yasevich @ 2012-11-20 20:25 UTC (permalink / raw)
  To: Neil Horman; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <1353442470-20660-1-git-send-email-nhorman@tuxdriver.com>

On 11/20/2012 03:14 PM, Neil Horman wrote:
> In the event that an association exceeds its max_retrans attempts, we should
> send an ABORT chunk indicating that we are closing the assocation as a result.
> Because of the nature of the error, its unlikely to be received, but its a nice
> clean way to close the association if it does make it through, and it will give
> anyone watching via tcpdump a clue as to what happened.
>
> Change notes:
> v2)
> 	* Removed erroneous changes from sctp_make_violation_parmlen
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Vlad Yasevich <vyasevich@gmail.com>

Acked-by: Vlad Yasevich <vyasevich@gmail.com>

-vlad

> CC: "David S. Miller" <davem@davemloft.net>
> CC: linux-sctp@vger.kernel.org
> ---
>   include/net/sctp/sm.h    |  2 ++
>   net/sctp/sm_make_chunk.c | 19 +++++++++++++++++++
>   net/sctp/sm_sideeffect.c |  9 ++++++++-
>   3 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
> index b5887e1..2a82d13 100644
> --- a/include/net/sctp/sm.h
> +++ b/include/net/sctp/sm.h
> @@ -234,6 +234,8 @@ struct sctp_chunk *sctp_make_abort_violation(const struct sctp_association *,
>   struct sctp_chunk *sctp_make_violation_paramlen(const struct sctp_association *,
>   				   const struct sctp_chunk *,
>   				   struct sctp_paramhdr *);
> +struct sctp_chunk *sctp_make_violation_max_retrans(const struct sctp_association *,
> +						   const struct sctp_chunk *);
>   struct sctp_chunk *sctp_make_heartbeat(const struct sctp_association *,
>   				  const struct sctp_transport *);
>   struct sctp_chunk *sctp_make_heartbeat_ack(const struct sctp_association *,
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index fbe1636..e0f01a4 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -1090,6 +1090,25 @@ nodata:
>   	return retval;
>   }
>
> +struct sctp_chunk *sctp_make_violation_max_retrans(
> +	const struct sctp_association *asoc,
> +	const struct sctp_chunk *chunk)
> +{
> +	struct sctp_chunk *retval;
> +	static const char error[] = "Association exceeded its max_retans count";
> +	size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t);
> +
> +	retval = sctp_make_abort(asoc, chunk, payload_len);
> +	if (!retval)
> +		goto nodata;
> +
> +	sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION, sizeof(error));
> +	sctp_addto_chunk(retval, sizeof(error), error);
> +
> +nodata:
> +	return retval;
> +}
> +
>   /* Make a HEARTBEAT chunk.  */
>   struct sctp_chunk *sctp_make_heartbeat(const struct sctp_association *asoc,
>   				  const struct sctp_transport *transport)
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index 6eecf7e..c076956 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -577,7 +577,7 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>   				  unsigned int error)
>   {
>   	struct sctp_ulpevent *event;
> -
> +	struct sctp_chunk *abort;
>   	/* Cancel any partial delivery in progress. */
>   	sctp_ulpq_abort_pd(&asoc->ulpq, GFP_ATOMIC);
>
> @@ -593,6 +593,13 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>   		sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>   				SCTP_ULPEVENT(event));
>
> +	if (asoc->overall_error_count >= asoc->max_retrans) {
> +		abort = sctp_make_violation_max_retrans(asoc, chunk);
> +		if (abort)
> +			sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> +					SCTP_CHUNK(abort));
> +	}
> +
>   	sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
>   			SCTP_STATE(SCTP_STATE_CLOSED));
>
>

^ permalink raw reply

* [PATCH] net: fix build failure in xilinx
From: Jeff Mahoney @ 2012-11-20 20:23 UTC (permalink / raw)
  To: netdev; +Cc: Xiaotian Feng

Commit 71c6c837 (drivers/net: fix tasklet misuse issue) introduced a
build failure in the xilinx driver. axienet_dma_err_handler isn't
declared before its use in axienet_open.

This patch provides the prototype before axienet_open.

Cc: Xiaotian Feng <dannyfeng@tencent.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -894,6 +894,8 @@ out:
 	return IRQ_HANDLED;
 }
 
+static void axienet_dma_err_handler(unsigned long data);
+
 /**
  * axienet_open - Driver open routine.
  * @ndev:	Pointer to net_device structure


--
Jeff Mahoney
SUSE Labs

^ permalink raw reply

* Re: unable to handle paging request, arm, at aio/tcp code, only 3.6
From: David Miller @ 2012-11-20 20:18 UTC (permalink / raw)
  To: eric.dumazet; +Cc: viric, netdev
In-Reply-To: <1353360858.10798.86.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 19 Nov 2012 13:34:18 -0800

> [PATCH] ipv6: fix inet6_csk_update_pmtu() return value
> 
> In case of error, inet6_csk_update_pmtu() should consistently
> return NULL.
> 
> Bug added in commit 35ad9b9cf7d8a 
> (ipv6: Add helper inet6_csk_update_pmtu().)
> 
> Reported-by: Lluís Batlle i Rossell <viric@viric.name>
> Signed-off-by: Eric Dumazet <edumazet@google.com>

My bad.  Applied and queued up for 3.6.x-stable, thanks!

^ permalink raw reply

* [PATCH v2] sctp: send abort chunk when max_retrans exceeded
From: Neil Horman @ 2012-11-20 20:14 UTC (permalink / raw)
  To: netdev; +Cc: Neil Horman, Vlad Yasevich, David S. Miller, linux-sctp
In-Reply-To: <1353434344-17864-1-git-send-email-nhorman@tuxdriver.com>

In the event that an association exceeds its max_retrans attempts, we should
send an ABORT chunk indicating that we are closing the assocation as a result.
Because of the nature of the error, its unlikely to be received, but its a nice
clean way to close the association if it does make it through, and it will give
anyone watching via tcpdump a clue as to what happened.

Change notes:
v2)
	* Removed erroneous changes from sctp_make_violation_parmlen

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: linux-sctp@vger.kernel.org
---
 include/net/sctp/sm.h    |  2 ++
 net/sctp/sm_make_chunk.c | 19 +++++++++++++++++++
 net/sctp/sm_sideeffect.c |  9 ++++++++-
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index b5887e1..2a82d13 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -234,6 +234,8 @@ struct sctp_chunk *sctp_make_abort_violation(const struct sctp_association *,
 struct sctp_chunk *sctp_make_violation_paramlen(const struct sctp_association *,
 				   const struct sctp_chunk *,
 				   struct sctp_paramhdr *);
+struct sctp_chunk *sctp_make_violation_max_retrans(const struct sctp_association *,
+						   const struct sctp_chunk *);
 struct sctp_chunk *sctp_make_heartbeat(const struct sctp_association *,
 				  const struct sctp_transport *);
 struct sctp_chunk *sctp_make_heartbeat_ack(const struct sctp_association *,
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index fbe1636..e0f01a4 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -1090,6 +1090,25 @@ nodata:
 	return retval;
 }
 
+struct sctp_chunk *sctp_make_violation_max_retrans(
+	const struct sctp_association *asoc,
+	const struct sctp_chunk *chunk)
+{
+	struct sctp_chunk *retval;
+	static const char error[] = "Association exceeded its max_retans count";
+	size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t);
+
+	retval = sctp_make_abort(asoc, chunk, payload_len);
+	if (!retval)
+		goto nodata;
+
+	sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION, sizeof(error));
+	sctp_addto_chunk(retval, sizeof(error), error);
+
+nodata:
+	return retval;
+}
+
 /* Make a HEARTBEAT chunk.  */
 struct sctp_chunk *sctp_make_heartbeat(const struct sctp_association *asoc,
 				  const struct sctp_transport *transport)
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index 6eecf7e..c076956 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -577,7 +577,7 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
 				  unsigned int error)
 {
 	struct sctp_ulpevent *event;
-
+	struct sctp_chunk *abort;
 	/* Cancel any partial delivery in progress. */
 	sctp_ulpq_abort_pd(&asoc->ulpq, GFP_ATOMIC);
 
@@ -593,6 +593,13 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
 		sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
 				SCTP_ULPEVENT(event));
 
+	if (asoc->overall_error_count >= asoc->max_retrans) {
+		abort = sctp_make_violation_max_retrans(asoc, chunk);
+		if (abort)
+			sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
+					SCTP_CHUNK(abort));
+	}
+
 	sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
 			SCTP_STATE(SCTP_STATE_CLOSED));
 
-- 
1.7.11.7

^ permalink raw reply related

* Re: [PATCH RFC 2/2] ixp4xx_hss: avoid calling dma_pool_create() with NULL dev
From: David Miller @ 2012-11-20 20:13 UTC (permalink / raw)
  To: xi.wang; +Cc: khc, netdev, akpm
In-Reply-To: <1353219910-24690-2-git-send-email-xi.wang@gmail.com>

From: Xi Wang <xi.wang@gmail.com>
Date: Sun, 18 Nov 2012 01:25:10 -0500

> Use &port->netdev->dev instead of NULL since dma_pool_create() doesn't
> allow NULL dev.
> 
> Signed-off-by: Xi Wang <xi.wang@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>

Applied.

^ permalink raw reply

* Re: [PATCH RFC 1/2] ixp4xx_eth: avoid calling dma_pool_create() with NULL dev
From: David Miller @ 2012-11-20 20:13 UTC (permalink / raw)
  To: xi.wang; +Cc: khc, netdev, akpm
In-Reply-To: <1353219910-24690-1-git-send-email-xi.wang@gmail.com>

From: Xi Wang <xi.wang@gmail.com>
Date: Sun, 18 Nov 2012 01:25:09 -0500

> Use &port->netdev->dev instead of NULL since dma_pool_create() doesn't
> allow NULL dev.
> 
> Signed-off-by: Xi Wang <xi.wang@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>

Applied.

^ permalink raw reply

* Re: [PATCH v2] checkpatch: add double empty line check
From: Andy Whitcroft @ 2012-11-20 20:11 UTC (permalink / raw)
  To: Eilon Greenstein
  Cc: Joe Perches, David Rientjes, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <20121120193249.GH17797@dm>

On Tue, Nov 20, 2012 at 07:32:49PM +0000, Andy Whitcroft wrote:
> On Tue, Nov 20, 2012 at 09:10:35PM +0200, Eilon Greenstein wrote:
> 
> > About the logic - true, if diff will show deleted lines after newly
> > added lines, some new double line segments will be missed. However, it
> > seems like few other things will break if diff will start acting out
> > like that. The suggestion you posted earlier will miss those as well,
> > and starting to check for this weird case (of deleted lines after the
> > added lines) does not seem right.
> 
> Actually the version I sent should indeed cope with the deleted lines
> regardless of order.  It was cirtainly intended to.

... and I think I thought of a couple more corner cases neither solution
will find.  So I am going to go away and make up a proper set of tests
for this apparently simple change.  As it is really annoying when it
false positives.  I will post against when I have something which works.

-apw

^ permalink raw reply

* Re: [PATCH v6 0/2] PCI-Express Non-Transparent Bridge Support
From: David Miller @ 2012-11-20 20:10 UTC (permalink / raw)
  To: jon.mason; +Cc: gregkh, linux-kernel, linux-pci, netdev, dave.jiang, nab
In-Reply-To: <1353119233-32752-1-git-send-email-jon.mason@intel.com>

From: Jon Mason <jon.mason@intel.com>
Date: Fri, 16 Nov 2012 19:27:11 -0700

> I am submitting version 6 of the PCI-Express Non-Transparent Bridge
> patches for inclusion in 3.8 via Greg KH's char-misc-next tree.  All
> outstanding issues have been addressed.
> 
> Version 6 corrects Greg KH's issues, most notably the improper usage of
> the Linux device model.
> http://thread.gmane.org/gmane.linux.kernel.pci/18599

For the networking bits:

Acked-by: David S. Miller <davem@davemloft.net>

^ permalink raw reply

* Re: [PATCH] sctp: send abort chunk when max_retrans exceeded
From: Neil Horman @ 2012-11-20 20:07 UTC (permalink / raw)
  To: Vlad Yasevich; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <50ABDF66.2040603@gmail.com>

On Tue, Nov 20, 2012 at 02:52:06PM -0500, Vlad Yasevich wrote:
> On 11/20/2012 02:28 PM, Vlad Yasevich wrote:
> >On 11/20/2012 02:15 PM, Neil Horman wrote:
> >>On Tue, Nov 20, 2012 at 01:44:23PM -0500, Vlad Yasevich wrote:
> >>>On 11/20/2012 12:59 PM, Neil Horman wrote:
> >>>>In the event that an association exceeds its max_retrans attempts,
> >>>>we should
> >>>>send an ABORT chunk indicating that we are closing the assocation as
> >>>>a result.
> >>>>Because of the nature of the error, its unlikely to be received, but
> >>>>its a nice
> >>>>clean way to close the association if it does make it through, and
> >>>>it will give
> >>>>anyone watching via tcpdump a clue as to what happened.
> >>>>
> >>>>Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> >>>>CC: Vlad Yasevich <vyasevich@gmail.com>
> >>>>CC: "David S. Miller" <davem@davemloft.net>
> >>>>CC: linux-sctp@vger.kernel.org
> >>>>---
> >>>>  include/net/sctp/sm.h    |  2 ++
> >>>>  net/sctp/sm_make_chunk.c | 26 +++++++++++++++++++++-----
> >>>>  net/sctp/sm_sideeffect.c |  9 ++++++++-
> >>>>  3 files changed, 31 insertions(+), 6 deletions(-)
> >>>>
> >>>>diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
> >>>>index b5887e1..2a82d13 100644
> >>>>--- a/include/net/sctp/sm.h
> >>>>+++ b/include/net/sctp/sm.h
> >>>>@@ -234,6 +234,8 @@ struct sctp_chunk
> >>>>*sctp_make_abort_violation(const struct sctp_association *,
> >>>>  struct sctp_chunk *sctp_make_violation_paramlen(const struct
> >>>>sctp_association *,
> >>>>                     const struct sctp_chunk *,
> >>>>                     struct sctp_paramhdr *);
> >>>>+struct sctp_chunk *sctp_make_violation_max_retrans(const struct
> >>>>sctp_association *,
> >>>>+                           const struct sctp_chunk *);
> >>>>  struct sctp_chunk *sctp_make_heartbeat(const struct
> >>>>sctp_association *,
> >>>>                    const struct sctp_transport *);
> >>>>  struct sctp_chunk *sctp_make_heartbeat_ack(const struct
> >>>>sctp_association *,
> >>>>diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> >>>>index fbe1636..d6a8c80 100644
> >>>>--- a/net/sctp/sm_make_chunk.c
> >>>>+++ b/net/sctp/sm_make_chunk.c
> >>>>@@ -1074,17 +1074,33 @@ struct sctp_chunk
> >>>>*sctp_make_violation_paramlen(
> >>>>  {
> >>>>      struct sctp_chunk *retval;
> >>>>      static const char error[] = "The following parameter had
> >>>>invalid length:";
> >>>>-    size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t) +
> >>>>-                sizeof(sctp_paramhdr_t);
> >>>>+    size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t);
> >>>>
> >>>>      retval = sctp_make_abort(asoc, chunk, payload_len);
> >>>>      if (!retval)
> >>>>          goto nodata;
> >>>>
> >>>>-    sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION,
> >>>>-            sizeof(error) + sizeof(sctp_paramhdr_t));
> >>>>+    sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION,
> >>>>sizeof(error));
> >>>>+    sctp_addto_chunk(retval, sizeof(error), error);
> >>>>+
> >>>>+nodata:
> >>>>+    return retval;
> >>>>+}
> >>>
> >>>Neil
> >>>
> >>>You ended dropping the parameter information of the parameter that
> >>>caused the violation.  Was that intentional?
> >>>
> >>Yes, it was, because theres not really IMO a specific parameter that
> >>causes this
> >>abort condition.
> >
> >Sure there is.  You changed sctp_make_violation_paramlen() which is
> >called when we receive a protocol parameter which has an invalid length.
> >This triggers a violation and the parameter is report back.  This has
> >nothing to do with max_rtx overflow.
> 
> It looks like you tried to re-use sctp_make_violation_paramlen(),
> abandoned that approach, but forgot to fully restore the old
> function...
> 
> -vlad
> 
Oh hell, you're right, my apologies, thats exactly what happened, and I
misunderstood what you were saying.  I thought you were asking why I wasn't
including a parameter segment in the max_retrans abort (because there isn't
any).  I completly missed the fact that I inadvertently mangled the
sctp_violation_paramlen function. 

I'll fix that up and repost.

Thanks
Neil

^ permalink raw reply

* Re: [PATCH] sctp: send abort chunk when max_retrans exceeded
From: Vlad Yasevich @ 2012-11-20 19:52 UTC (permalink / raw)
  To: Neil Horman; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <50ABD9CA.7080907@gmail.com>

On 11/20/2012 02:28 PM, Vlad Yasevich wrote:
> On 11/20/2012 02:15 PM, Neil Horman wrote:
>> On Tue, Nov 20, 2012 at 01:44:23PM -0500, Vlad Yasevich wrote:
>>> On 11/20/2012 12:59 PM, Neil Horman wrote:
>>>> In the event that an association exceeds its max_retrans attempts,
>>>> we should
>>>> send an ABORT chunk indicating that we are closing the assocation as
>>>> a result.
>>>> Because of the nature of the error, its unlikely to be received, but
>>>> its a nice
>>>> clean way to close the association if it does make it through, and
>>>> it will give
>>>> anyone watching via tcpdump a clue as to what happened.
>>>>
>>>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>>>> CC: Vlad Yasevich <vyasevich@gmail.com>
>>>> CC: "David S. Miller" <davem@davemloft.net>
>>>> CC: linux-sctp@vger.kernel.org
>>>> ---
>>>>   include/net/sctp/sm.h    |  2 ++
>>>>   net/sctp/sm_make_chunk.c | 26 +++++++++++++++++++++-----
>>>>   net/sctp/sm_sideeffect.c |  9 ++++++++-
>>>>   3 files changed, 31 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
>>>> index b5887e1..2a82d13 100644
>>>> --- a/include/net/sctp/sm.h
>>>> +++ b/include/net/sctp/sm.h
>>>> @@ -234,6 +234,8 @@ struct sctp_chunk
>>>> *sctp_make_abort_violation(const struct sctp_association *,
>>>>   struct sctp_chunk *sctp_make_violation_paramlen(const struct
>>>> sctp_association *,
>>>>                      const struct sctp_chunk *,
>>>>                      struct sctp_paramhdr *);
>>>> +struct sctp_chunk *sctp_make_violation_max_retrans(const struct
>>>> sctp_association *,
>>>> +                           const struct sctp_chunk *);
>>>>   struct sctp_chunk *sctp_make_heartbeat(const struct
>>>> sctp_association *,
>>>>                     const struct sctp_transport *);
>>>>   struct sctp_chunk *sctp_make_heartbeat_ack(const struct
>>>> sctp_association *,
>>>> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
>>>> index fbe1636..d6a8c80 100644
>>>> --- a/net/sctp/sm_make_chunk.c
>>>> +++ b/net/sctp/sm_make_chunk.c
>>>> @@ -1074,17 +1074,33 @@ struct sctp_chunk
>>>> *sctp_make_violation_paramlen(
>>>>   {
>>>>       struct sctp_chunk *retval;
>>>>       static const char error[] = "The following parameter had
>>>> invalid length:";
>>>> -    size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t) +
>>>> -                sizeof(sctp_paramhdr_t);
>>>> +    size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t);
>>>>
>>>>       retval = sctp_make_abort(asoc, chunk, payload_len);
>>>>       if (!retval)
>>>>           goto nodata;
>>>>
>>>> -    sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION,
>>>> -            sizeof(error) + sizeof(sctp_paramhdr_t));
>>>> +    sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION,
>>>> sizeof(error));
>>>> +    sctp_addto_chunk(retval, sizeof(error), error);
>>>> +
>>>> +nodata:
>>>> +    return retval;
>>>> +}
>>>
>>> Neil
>>>
>>> You ended dropping the parameter information of the parameter that
>>> caused the violation.  Was that intentional?
>>>
>> Yes, it was, because theres not really IMO a specific parameter that
>> causes this
>> abort condition.
>
> Sure there is.  You changed sctp_make_violation_paramlen() which is
> called when we receive a protocol parameter which has an invalid length.
> This triggers a violation and the parameter is report back.  This has
> nothing to do with max_rtx overflow.

It looks like you tried to re-use sctp_make_violation_paramlen(), 
abandoned that approach, but forgot to fully restore the old function...

-vlad

>
> The new code doesn't have to include parameter information and I am fine
> with that.
>
> -vlad
>
>
>>  If a chunk needs to be resent more than max_retrans times, we
>> abort the connection, theres no specific parameter that we can point
>> to that
>> says "this caused the problem", we're just aborting because we can't
>> get a SACK
>> from the peer.  Likewise, I can't think of any information that we can
>> include
>> that would give the peer, or the anyone tcpdumping the connection an
>> improved
>> view as to why the abort happened, beyond the string this patch currently
>> includes.
>>
>> I know I had privately sent you an early version of the patch as a
>> rough draft
>> which did include space for a param header, but that patch never
>> filled that
>> space out, since we don't have any valid information to fill it out with.
>>
>> Thanks & Regards
>> Neil
>>
>
> Neil
>

^ permalink raw reply

* Re: [PATCH v2] checkpatch: add double empty line check
From: Andy Whitcroft @ 2012-11-20 19:32 UTC (permalink / raw)
  To: Eilon Greenstein
  Cc: Joe Perches, David Rientjes, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <1353438635.10779.10.camel@lb-tlvb-eilong.il.broadcom.com>

On Tue, Nov 20, 2012 at 09:10:35PM +0200, Eilon Greenstein wrote:

> About the logic - true, if diff will show deleted lines after newly
> added lines, some new double line segments will be missed. However, it
> seems like few other things will break if diff will start acting out
> like that. The suggestion you posted earlier will miss those as well,
> and starting to check for this weird case (of deleted lines after the
> added lines) does not seem right.

Actually the version I sent should indeed cope with the deleted lines
regardless of order.  It was cirtainly intended to.

-apw

^ permalink raw reply

* Re: [PATCH] sctp: send abort chunk when max_retrans exceeded
From: Vlad Yasevich @ 2012-11-20 19:28 UTC (permalink / raw)
  To: Neil Horman; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <20121120191514.GA10287@shamino.rdu.redhat.com>

On 11/20/2012 02:15 PM, Neil Horman wrote:
> On Tue, Nov 20, 2012 at 01:44:23PM -0500, Vlad Yasevich wrote:
>> On 11/20/2012 12:59 PM, Neil Horman wrote:
>>> In the event that an association exceeds its max_retrans attempts, we should
>>> send an ABORT chunk indicating that we are closing the assocation as a result.
>>> Because of the nature of the error, its unlikely to be received, but its a nice
>>> clean way to close the association if it does make it through, and it will give
>>> anyone watching via tcpdump a clue as to what happened.
>>>
>>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>>> CC: Vlad Yasevich <vyasevich@gmail.com>
>>> CC: "David S. Miller" <davem@davemloft.net>
>>> CC: linux-sctp@vger.kernel.org
>>> ---
>>>   include/net/sctp/sm.h    |  2 ++
>>>   net/sctp/sm_make_chunk.c | 26 +++++++++++++++++++++-----
>>>   net/sctp/sm_sideeffect.c |  9 ++++++++-
>>>   3 files changed, 31 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
>>> index b5887e1..2a82d13 100644
>>> --- a/include/net/sctp/sm.h
>>> +++ b/include/net/sctp/sm.h
>>> @@ -234,6 +234,8 @@ struct sctp_chunk *sctp_make_abort_violation(const struct sctp_association *,
>>>   struct sctp_chunk *sctp_make_violation_paramlen(const struct sctp_association *,
>>>   				   const struct sctp_chunk *,
>>>   				   struct sctp_paramhdr *);
>>> +struct sctp_chunk *sctp_make_violation_max_retrans(const struct sctp_association *,
>>> +						   const struct sctp_chunk *);
>>>   struct sctp_chunk *sctp_make_heartbeat(const struct sctp_association *,
>>>   				  const struct sctp_transport *);
>>>   struct sctp_chunk *sctp_make_heartbeat_ack(const struct sctp_association *,
>>> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
>>> index fbe1636..d6a8c80 100644
>>> --- a/net/sctp/sm_make_chunk.c
>>> +++ b/net/sctp/sm_make_chunk.c
>>> @@ -1074,17 +1074,33 @@ struct sctp_chunk *sctp_make_violation_paramlen(
>>>   {
>>>   	struct sctp_chunk *retval;
>>>   	static const char error[] = "The following parameter had invalid length:";
>>> -	size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t) +
>>> -				sizeof(sctp_paramhdr_t);
>>> +	size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t);
>>>
>>>   	retval = sctp_make_abort(asoc, chunk, payload_len);
>>>   	if (!retval)
>>>   		goto nodata;
>>>
>>> -	sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION,
>>> -			sizeof(error) + sizeof(sctp_paramhdr_t));
>>> +	sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION, sizeof(error));
>>> +	sctp_addto_chunk(retval, sizeof(error), error);
>>> +
>>> +nodata:
>>> +	return retval;
>>> +}
>>
>> Neil
>>
>> You ended dropping the parameter information of the parameter that
>> caused the violation.  Was that intentional?
>>
> Yes, it was, because theres not really IMO a specific parameter that causes this
> abort condition.

Sure there is.  You changed sctp_make_violation_paramlen() which is 
called when we receive a protocol parameter which has an invalid length.
This triggers a violation and the parameter is report back.  This has 
nothing to do with max_rtx overflow.

The new code doesn't have to include parameter information and I am fine 
with that.

-vlad


>  If a chunk needs to be resent more than max_retrans times, we
> abort the connection, theres no specific parameter that we can point to that
> says "this caused the problem", we're just aborting because we can't get a SACK
> from the peer.  Likewise, I can't think of any information that we can include
> that would give the peer, or the anyone tcpdumping the connection an improved
> view as to why the abort happened, beyond the string this patch currently
> includes.
>
> I know I had privately sent you an early version of the patch as a rough draft
> which did include space for a param header, but that patch never filled that
> space out, since we don't have any valid information to fill it out with.
>
> Thanks & Regards
> Neil
>

Neil

^ permalink raw reply

* re: team: add broadcast mode
From: Dan Carpenter @ 2012-11-20 19:23 UTC (permalink / raw)
  To: jpirko; +Cc: netdev

Hello Jiri Pirko,

The patch 5fc889911a99: "team: add broadcast mode" from Jul 11, 2012, 
leads to the following Smatch warning:
drivers/net/team/team_mode_broadcast.c:46 bc_transmit()
	 warn: signedness bug returning '18446744073709551516'

The error message sucks because 18446744073709551516 is -100 as an int,
and I'm not sure how it figures this returns -100...

But actually there is a signedness bug in bc_transmit().  We return
error codes from team_dev_queue_xmit() and cast them to 1 as bool.  This
function is supposed to return 1 on success but instead it returns zero.

regards,
dan carpenter

^ permalink raw reply

* Re: [PATCH] sctp: send abort chunk when max_retrans exceeded
From: Neil Horman @ 2012-11-20 19:15 UTC (permalink / raw)
  To: Vlad Yasevich; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <50ABCF87.2090901@gmail.com>

On Tue, Nov 20, 2012 at 01:44:23PM -0500, Vlad Yasevich wrote:
> On 11/20/2012 12:59 PM, Neil Horman wrote:
> >In the event that an association exceeds its max_retrans attempts, we should
> >send an ABORT chunk indicating that we are closing the assocation as a result.
> >Because of the nature of the error, its unlikely to be received, but its a nice
> >clean way to close the association if it does make it through, and it will give
> >anyone watching via tcpdump a clue as to what happened.
> >
> >Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> >CC: Vlad Yasevich <vyasevich@gmail.com>
> >CC: "David S. Miller" <davem@davemloft.net>
> >CC: linux-sctp@vger.kernel.org
> >---
> >  include/net/sctp/sm.h    |  2 ++
> >  net/sctp/sm_make_chunk.c | 26 +++++++++++++++++++++-----
> >  net/sctp/sm_sideeffect.c |  9 ++++++++-
> >  3 files changed, 31 insertions(+), 6 deletions(-)
> >
> >diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
> >index b5887e1..2a82d13 100644
> >--- a/include/net/sctp/sm.h
> >+++ b/include/net/sctp/sm.h
> >@@ -234,6 +234,8 @@ struct sctp_chunk *sctp_make_abort_violation(const struct sctp_association *,
> >  struct sctp_chunk *sctp_make_violation_paramlen(const struct sctp_association *,
> >  				   const struct sctp_chunk *,
> >  				   struct sctp_paramhdr *);
> >+struct sctp_chunk *sctp_make_violation_max_retrans(const struct sctp_association *,
> >+						   const struct sctp_chunk *);
> >  struct sctp_chunk *sctp_make_heartbeat(const struct sctp_association *,
> >  				  const struct sctp_transport *);
> >  struct sctp_chunk *sctp_make_heartbeat_ack(const struct sctp_association *,
> >diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> >index fbe1636..d6a8c80 100644
> >--- a/net/sctp/sm_make_chunk.c
> >+++ b/net/sctp/sm_make_chunk.c
> >@@ -1074,17 +1074,33 @@ struct sctp_chunk *sctp_make_violation_paramlen(
> >  {
> >  	struct sctp_chunk *retval;
> >  	static const char error[] = "The following parameter had invalid length:";
> >-	size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t) +
> >-				sizeof(sctp_paramhdr_t);
> >+	size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t);
> >
> >  	retval = sctp_make_abort(asoc, chunk, payload_len);
> >  	if (!retval)
> >  		goto nodata;
> >
> >-	sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION,
> >-			sizeof(error) + sizeof(sctp_paramhdr_t));
> >+	sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION, sizeof(error));
> >+	sctp_addto_chunk(retval, sizeof(error), error);
> >+
> >+nodata:
> >+	return retval;
> >+}
> 
> Neil
> 
> You ended dropping the parameter information of the parameter that
> caused the violation.  Was that intentional?
> 
Yes, it was, because theres not really IMO a specific parameter that causes this
abort condition.  If a chunk needs to be resent more than max_retrans times, we
abort the connection, theres no specific parameter that we can point to that
says "this caused the problem", we're just aborting because we can't get a SACK 
from the peer.  Likewise, I can't think of any information that we can include
that would give the peer, or the anyone tcpdumping the connection an improved
view as to why the abort happened, beyond the string this patch currently
includes.

I know I had privately sent you an early version of the patch as a rough draft
which did include space for a param header, but that patch never filled that
space out, since we don't have any valid information to fill it out with.

Thanks & Regards
Neil

^ permalink raw reply

* Re: [PATCH v2] checkpatch: add double empty line check
From: Eilon Greenstein @ 2012-11-20 19:10 UTC (permalink / raw)
  To: Andy Whitcroft
  Cc: Joe Perches, David Rientjes, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <20121120163607.GB17797@dm>

On Tue, 2012-11-20 at 18:36 +0200, Andy Whitcroft wrote:
> On Tue, Nov 20, 2012 at 04:14:17PM +0000, Andy Whitcroft wrote:
> > On Tue, Nov 20, 2012 at 06:06:10PM +0200, Eilon Greenstein wrote:
> > > I'm only testing the nextline if the current line is newly added. If I
> > > got it right, when a line is newly added, the next line can be:
> > > a. another new line
> > > b. existing line (provided for context)
> > > c. Does not exist since this is the end of the file (I missed this one
> > > originally)
> > > 
> > > It cannot just jump to the next hunk and it cannot be a deleted line,
> > > right?
> 
> Oh and in theory at least it could be a - line, though diff never
> generates things in that order.
> 

Andy - I could not find any other perl warnings. In the current
suggestion, only $line and $prevline are being accessed unconditionally
and $rawlines[$linenr] is accessed only after checking it exists - so it
seems safe.

About the logic - true, if diff will show deleted lines after newly
added lines, some new double line segments will be missed. However, it
seems like few other things will break if diff will start acting out
like that. The suggestion you posted earlier will miss those as well,
and starting to check for this weird case (of deleted lines after the
added lines) does not seem right.

So this patch seems safe, it does not generate false positives and it
does catch all the cases we can currently generate with diff - can you
please consider applying it to checkpatch?

I'm posting it again below for easier reference, please let me know if
you would like me to send it in a clean email separately.

Thanks,
Eilon

>From 403038375a9c09046631f674d14c221758a0de61 Mon Sep 17 00:00:00 2001
From: Eilon Greenstein <eilong@broadcom.com>
Date: Tue, 20 Nov 2012 21:05:30 +0200
Subject: [PATCH] checkpatch: add double empty line check

Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
 scripts/checkpatch.pl |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 21a9f5d..c0c610c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3579,6 +3579,19 @@ sub process {
 			WARN("EXPORTED_WORLD_WRITABLE",
 			     "Exporting world writable files is usually an error. Consider more restrictive permissions.\n" . $herecurr);
 		}
+
+# check for double empty lines
+		if ($line =~ /^\+\s*$/) {
+			my $nextline = "";
+			if (defined($rawlines[$linenr])) {
+				$nextline = $rawlines[$linenr];
+			}
+			if ($nextline =~ /^\s*$/ ||
+			    $prevline =~ /^\+?\s*$/ && $nextline !~ /^\+\s*$/) {
+				CHK("DOUBLE_EMPTY_LINE",
+				    "One empty line should be sufficient. Consider removing this one.\n" . $herecurr);
+			}
+		}
 	}
 
 	# If we have no input at all, then there is nothing to report on
-- 
1.7.9.5

^ permalink raw reply related

* Re: [PATCH v2 net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: David Miller @ 2012-11-20 18:58 UTC (permalink / raw)
  To: brian.haley; +Cc: xemul, eric.dumazet, netdev
In-Reply-To: <50A6A8FB.3050901@hp.com>

From: Brian Haley <brian.haley@hp.com>
Date: Fri, 16 Nov 2012 15:58:35 -0500

> Instead of having the getsockopt() of SO_BINDTODEVICE return an index, which
> will then require another call like if_indextoname() to get the actual interface
> name, have it return the name directly.
> 
> This also matches the existing man page description on socket(7) which mentions
> the argument being an interface name.
> 
> If the value has not been set, zero is returned and optlen will be set to zero
> to indicate there is no interface name present.
> 
> Added a seqlock to protect this code path, and dev_ifname(), from someone
> changing the device name via dev_change_name().
> 
> v2: Added seqlock protection while copying device name.
> 
> Signed-off-by: Brian Haley <brian.haley@hp.com>

Brian I was going to apply this, but something about how you email
patches results in them being corrupted.

Go to:

http://patchwork.ozlabs.org/patch/199732/

Click on Download "mbox", and try to apply that to the net-next tree
to see what I mean.

^ permalink raw reply

* Re: [PATCH] pkt_sched: QFQ Plus: fair-queueing service at DRR cost
From: David Miller @ 2012-11-20 18:54 UTC (permalink / raw)
  To: paolo.valente; +Cc: jhs, shemminger, linux-kernel, netdev, rizzo, fchecconi
In-Reply-To: <20121120174513.GA21618@paolo-ThinkPad-W520>

From: Paolo Valente <paolo.valente@unimore.it>
Date: Tue, 20 Nov 2012 18:45:13 +0100

> -	struct sk_buff *skb;
> +	struct sk_buff *skb = NULL;

This is not really an improvement, now the compiler can think
that NULL is passed eventually into qdisc_bstats_update().

Please make the logic easier for the compiler to digest.

For example, restructure the top-level logic into something like:

	skb = NULL;
	if (!list_empty(&in_serv_agg->active))
		skb = qfq_peek_skb(in_serv_agg, &cl, &len);
	else
		len = 0; /* no more active classes in the in-service agg */

	if (len == 0 || in_serv_agg->budget < len) {
 ...
		/*
		 * If we get here, there are other aggregates queued:
		 * choose the new aggregate to serve.
		 */
		in_serv_agg = q->in_serv_agg = qfq_choose_next_agg(q);
		skb = qfq_peek_skb(in_serv_agg, &cl, &len);
	}
	if (!skb)
		return NULL;

That way it is clearer, to both humans and the compiler, what is
going on here.

Thanks.

^ permalink raw reply

* Re: [PATCH] ne2000: add the right platform device
From: David Miller @ 2012-11-20 18:49 UTC (permalink / raw)
  To: alan; +Cc: netdev
In-Reply-To: <20121120163157.11874.74810.stgit@bob.linux.org.uk>

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Tue, 20 Nov 2012 16:31:57 +0000

> From: Alan Cox <alan@linux.intel.com>
> 
> Without this udev doesn't have a way to key the ne device to the platform
> device.
> 
> Signed-off-by: Alan Cox <alan@linux.intel.com>

Applied and queued up for -stable, thanks Alan.

^ permalink raw reply

* Re: [PATCH 1/1] bnx2x: Remove duplicate inclusion of bnx2x_hsi.h
From: David Miller @ 2012-11-20 18:47 UTC (permalink / raw)
  To: sachin.kamat; +Cc: netdev, eilong, patches
In-Reply-To: <1353325931-1803-1-git-send-email-sachin.kamat@linaro.org>

From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Mon, 19 Nov 2012 17:22:11 +0530

> bnx2x_hsi.h was included twice.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>

Applied to net-next, thanks.

^ permalink raw reply

* Re: [RESEND PATCH net-next 1/1] sit: allow to configure 6rd tunnels via netlink
From: David Miller @ 2012-11-20 18:45 UTC (permalink / raw)
  To: nicolas.dichtel; +Cc: netdev, shemminger
In-Reply-To: <1353400905-28335-1-git-send-email-nicolas.dichtel@6wind.com>

From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 20 Nov 2012 09:41:45 +0100

> This patch add the support of 6RD tunnels management via netlink.
> Note that netdev_state_change() is now called when 6RD parameters are updated.
> 
> 6RD parameters are updated only if there is at least one 6RD attribute.
> 
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] sctp: send abort chunk when max_retrans exceeded
From: Vlad Yasevich @ 2012-11-20 18:44 UTC (permalink / raw)
  To: Neil Horman; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <1353434344-17864-1-git-send-email-nhorman@tuxdriver.com>

On 11/20/2012 12:59 PM, Neil Horman wrote:
> In the event that an association exceeds its max_retrans attempts, we should
> send an ABORT chunk indicating that we are closing the assocation as a result.
> Because of the nature of the error, its unlikely to be received, but its a nice
> clean way to close the association if it does make it through, and it will give
> anyone watching via tcpdump a clue as to what happened.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Vlad Yasevich <vyasevich@gmail.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: linux-sctp@vger.kernel.org
> ---
>   include/net/sctp/sm.h    |  2 ++
>   net/sctp/sm_make_chunk.c | 26 +++++++++++++++++++++-----
>   net/sctp/sm_sideeffect.c |  9 ++++++++-
>   3 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
> index b5887e1..2a82d13 100644
> --- a/include/net/sctp/sm.h
> +++ b/include/net/sctp/sm.h
> @@ -234,6 +234,8 @@ struct sctp_chunk *sctp_make_abort_violation(const struct sctp_association *,
>   struct sctp_chunk *sctp_make_violation_paramlen(const struct sctp_association *,
>   				   const struct sctp_chunk *,
>   				   struct sctp_paramhdr *);
> +struct sctp_chunk *sctp_make_violation_max_retrans(const struct sctp_association *,
> +						   const struct sctp_chunk *);
>   struct sctp_chunk *sctp_make_heartbeat(const struct sctp_association *,
>   				  const struct sctp_transport *);
>   struct sctp_chunk *sctp_make_heartbeat_ack(const struct sctp_association *,
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index fbe1636..d6a8c80 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -1074,17 +1074,33 @@ struct sctp_chunk *sctp_make_violation_paramlen(
>   {
>   	struct sctp_chunk *retval;
>   	static const char error[] = "The following parameter had invalid length:";
> -	size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t) +
> -				sizeof(sctp_paramhdr_t);
> +	size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t);
>
>   	retval = sctp_make_abort(asoc, chunk, payload_len);
>   	if (!retval)
>   		goto nodata;
>
> -	sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION,
> -			sizeof(error) + sizeof(sctp_paramhdr_t));
> +	sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION, sizeof(error));
> +	sctp_addto_chunk(retval, sizeof(error), error);
> +
> +nodata:
> +	return retval;
> +}

Neil

You ended dropping the parameter information of the parameter that 
caused the violation.  Was that intentional?

-vlad

> +
> +struct sctp_chunk *sctp_make_violation_max_retrans(
> +	const struct sctp_association *asoc,
> +	const struct sctp_chunk *chunk)
> +{
> +	struct sctp_chunk *retval;
> +	static const char error[] = "Association exceeded its max_retans count";
> +	size_t payload_len = sizeof(error) + sizeof(sctp_errhdr_t);
> +
> +	retval = sctp_make_abort(asoc, chunk, payload_len);
> +	if (!retval)
> +		goto nodata;
> +
> +	sctp_init_cause(retval, SCTP_ERROR_PROTO_VIOLATION, sizeof(error));
>   	sctp_addto_chunk(retval, sizeof(error), error);
> -	sctp_addto_param(retval, sizeof(sctp_paramhdr_t), param);
>
>   nodata:
>   	return retval;
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index 6eecf7e..c076956 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -577,7 +577,7 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>   				  unsigned int error)
>   {
>   	struct sctp_ulpevent *event;
> -
> +	struct sctp_chunk *abort;
>   	/* Cancel any partial delivery in progress. */
>   	sctp_ulpq_abort_pd(&asoc->ulpq, GFP_ATOMIC);
>
> @@ -593,6 +593,13 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>   		sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>   				SCTP_ULPEVENT(event));
>
> +	if (asoc->overall_error_count >= asoc->max_retrans) {
> +		abort = sctp_make_violation_max_retrans(asoc, chunk);
> +		if (abort)
> +			sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> +					SCTP_CHUNK(abort));
> +	}
> +
>   	sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
>   			SCTP_STATE(SCTP_STATE_CLOSED));
>
>

^ permalink raw reply

* Re: [PATCH] pkt_sched: QFQ Plus: fair-queueing service at DRR cost
From: Stephen Hemminger @ 2012-11-20 18:44 UTC (permalink / raw)
  To: David Miller; +Cc: paolo.valente, jhs, linux-kernel, netdev, rizzo, fchecconi
In-Reply-To: <20121120.131516.311189144173456123.davem@davemloft.net>

On Tue, 20 Nov 2012 13:15:16 -0500 (EST)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Tue, 20 Nov 2012 10:09:58 -0800
> 
> > On Tue, 20 Nov 2012 13:02:02 -0500 (EST)
> > David Miller <davem@davemloft.net> wrote:
> > 
> >> From: Stephen Hemminger <shemminger@vyatta.com>
> >> Date: Tue, 20 Nov 2012 09:53:04 -0800
> >> 
> >> > There are actually lots of bogus warnings than seem to only occur
> >> > because gcc 4.4 does a bad job of checking. Later versions are fixed
> >> > and don't generate warnings.
> >> > 
> >> > My preference is to not add the unnecessary initialization because
> >> > if you get in the habit of doing it. The whole purpose of the uninitialized
> >> > check is lost. 
> >> 
> >> Try again, this was with gcc-4.7.2-2 on Fedora.
> >> 
> >> There are too many preconditions, across multiple basic block, which
> >> together ensure the skb is in fact initialized at the point in
> >> question and the compiler simply isn't sophisticated enough to see
> >> that.
> > 
> > Weird, it compiles  clean on x86-84 on Debian.
> > gcc-4.7.real (Debian 4.7.2-4) 4.7.2
> 
> Fedora backports a lot more stuff into gcc than Debian does.

Probably. that's it. Plus Fedora has more gcc maintainers.

^ permalink raw reply

* Re: [PATCHv3 net-next] add DOVE extensions for VXLAN
From: David Miller @ 2012-11-20 18:41 UTC (permalink / raw)
  To: dlstevens; +Cc: shemminger, netdev
In-Reply-To: <201211201251.qAKCoEN8003256@lab1.dls>

From: David L Stevens <dlstevens@us.ibm.com>
Date: Tue, 20 Nov 2012 07:50:14 -0500

> 
> 	This patch provides extensions to VXLAN for supporting Distributed
> Overlay Virtual Ethernet (DOVE) networks. The patch includes:
> 
> 	+ a dove flag per VXLAN device to enable DOVE extensions
> 	+ ARP reduction, whereby a bridge-connected VXLAN tunnel endpoint
> 		answers ARP requests from the local bridge on behalf of
> 		remote DOVE clients
> 	+ route short-circuiting (aka L3 switching). Known destination IP
> 		addresses use the corresponding destination MAC address for
> 		switching rather than going to a (possibly remote) router first.
> 	+ netlink notification messages for forwarding table and L3 switching
> 		misses
> 
> Changes since v2
> 	- combined bools into "u32 flags"
> 	- replaced loop with !is_zero_ether_addr()
> 
> Signed-off-by: David L Stevens <dlstevens@us.ibm.com>

Applied, thanks David.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox