* 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: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] 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 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 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 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 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
* [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: 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] 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: [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
* 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
* [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] sctp: send abort chunk when max_retrans exceeded
From: David Miller @ 2012-11-20 20:51 UTC (permalink / raw)
To: vyasevich; +Cc: nhorman, netdev, linux-sctp
In-Reply-To: <50ABE754.7060306@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Tue, 20 Nov 2012 15:25:56 -0500
> 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>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: fix build failure in xilinx
From: David Miller @ 2012-11-20 20:52 UTC (permalink / raw)
To: jeffm; +Cc: netdev, dannyfeng
In-Reply-To: <50ABE6B1.7060308@suse.com>
From: Jeff Mahoney <jeffm@suse.com>
Date: Tue, 20 Nov 2012 15:23:13 -0500
> 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>
Applied.
^ permalink raw reply
* Re: [PATCH] irda: sir_dev: Fix copy/paste typo
From: David Miller @ 2012-11-20 20:52 UTC (permalink / raw)
To: shc_work; +Cc: netdev, samuel
In-Reply-To: <1353441551-4359-1-git-send-email-shc_work@mail.ru>
From: Alexander Shiyan <shc_work@mail.ru>
Date: Tue, 20 Nov 2012 23:59:11 +0400
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] caif: Remove redundant null check before kfree in cfctrl.c
From: David Miller @ 2012-11-20 20:53 UTC (permalink / raw)
To: sjur.brandeland; +Cc: sachin.kamat, netdev, patches
In-Reply-To: <81C3A93C17462B4BBD7E272753C105792457273283@EXDCVYMBSTM005.EQ1STM.local>
From: Sjur BRENDELAND <sjur.brandeland@stericsson.com>
Date: Tue, 20 Nov 2012 12:04:23 +0100
>> kfree on a null pointer is a no-op.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: Remove redundant null check before kfree in dev.c
From: David Miller @ 2012-11-20 20:53 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev, edumazet, patches
In-Reply-To: <1353409024-28853-1-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Tue, 20 Nov 2012 16:27:04 +0530
> kfree on a null pointer is a no-op.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied.
^ permalink raw reply
* You have (1) new ecard!
From: knowmukesh @ 2012-11-20 21:06 UTC (permalink / raw)
To: bcond45604
Click here to read it now! http://bit.ly/XZxXkR
^ permalink raw reply
* Re: unable to handle paging request, arm, at aio/tcp code, only 3.6
From: Lluís Batlle i Rossell @ 2012-11-20 21:26 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20121120.151845.765619681074379121.davem@davemloft.net>
On Tue, Nov 20, 2012 at 03:18:45PM -0500, David Miller wrote:
> 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!
All OK so far. No hang.
Thank you all!
^ permalink raw reply
* Re: [PATCH v2] checkpatch: add double empty line check
From: Joe Perches @ 2012-11-20 21:58 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Eilon Greenstein, David Rientjes, linux-kernel, netdev
In-Reply-To: <20121120115239.GA7955@dm>
On Tue, 2012-11-20 at 11:52 +0000, Andy Whitcroft wrote:
> On Sat, Nov 17, 2012 at 01:17:37PM +0200, Eilon Greenstein wrote:
> > Changes from previous attempt:
> > - Use CHK instead of WARN
> > - Issue only one warning per empty lines block
> >
> > Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> > ---
> > scripts/checkpatch.pl | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 21a9f5d..13d264f 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -3579,6 +3579,14 @@ 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*$/ &&
> > + ($rawlines[$linenr] =~ /^\s*$/ ||
> > + $prevline =~ /^\+?\s*$/ && $rawlines[$linenr] !~ /^\+\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
>
> In your previous version you indicated you would be emiting one per group
> of lines, I do not see how this does that. Also this fails if the fragment
> is at the top of the hunk emiting a perl warning. We should probabally
> use the suppress approach.
>
> How about something like the below.
>
> -apw
>
>
> >From 848ebffa8656a1ff96a91788ec0f1c04dab9c3e9 Mon Sep 17 00:00:00 2001
> From: Andy Whitcroft <apw@canonical.com>
> Date: Sat, 17 Nov 2012 13:17:37 +0200
> Subject: [PATCH] checkpatch: strict warning for multiple blank lines
>
> Signed-off-by: Andy Whitcroft <apw@canonical.com>
> ---
> scripts/checkpatch.pl | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index f18750e..dbc68f3 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -1411,6 +1411,7 @@ sub process {
> my %suppress_whiletrailers;
> my %suppress_export;
> my $suppress_statement = 0;
> + my $suppress_multipleblank = -1;
>
> # Pre-scan the patch sanitizing the lines.
> # Pre-scan the patch looking for any __setup documentation.
> @@ -1521,6 +1522,7 @@ sub process {
> %suppress_whiletrailers = ();
> %suppress_export = ();
> $suppress_statement = 0;
> + $suppress_multipleblank = -1;
> next;
>
> # track the line number as we move through the hunk, note that
> @@ -1930,6 +1932,15 @@ sub process {
> "use the SSYNC() macro in asm/blackfin.h\n" . $herevet);
> }
>
> +# multiple blank lines.
> + if ($line =~ /^-/ || ($suppress_multipleblank == $linenr && $line =~ /^[ \+]\s*$/)) {
> + $suppress_multipleblank++;
> + } elsif ($prevline =~ /^\+\s*$/ and $line =~ /^\+\s*$/) {
> + $suppress_multipleblank = $linenr + 1;
> + CHK("MULTIPLE_EMPTY_LINE",
> + "One empty line should be sufficient. Consider removing this one.\n" . $herecurr);
> + }
> +
> # Check for potential 'bare' types
> my ($stat, $cond, $line_nr_next, $remain_next, $off_next,
> $realline_next);
What about:
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d2d5ba1..ed4ec9d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1382,6 +1382,7 @@ sub process {
my $comment_edge = 0;
my $first_line = 0;
my $p1_prefix = '';
+ my $last_blank_linenr = 0;
my $prev_values = 'E';
@@ -3323,6 +3324,15 @@ sub process {
"sizeof $1 should be sizeof($1)\n" . $herecurr);
}
+# check for multiple blank lines, warn only on the second one in a block
+ if ($rawline =~ /^.\s*$/ &&
+ $prevrawline =~ /^.\s*$/ &&
+ $linenr != $last_blank_linenr + 1) {
+ CHK("DOUBLE_EMPTY_LINE",
+ "One blank line separating blocks is generally sufficient\n" . $herecurr);
+ $last_blank_linenr = $linenr;
+ }
+
# check for line continuations in quoted strings with odd counts of "
if ($rawline =~ /\\$/ && $rawline =~ tr/"/"/ % 2) {
WARN("LINE_CONTINUATIONS",
^ permalink raw reply related
* Re: [PATCH v2] checkpatch: add double empty line check
From: Andy Whitcroft @ 2012-11-20 23:19 UTC (permalink / raw)
To: Joe Perches; +Cc: Eilon Greenstein, David Rientjes, linux-kernel, netdev
In-Reply-To: <1353448728.17819.33.camel@joe-AO722>
On Tue, Nov 20, 2012 at 01:58:48PM -0800, Joe Perches wrote:
> +# check for multiple blank lines, warn only on the second one in a block
> + if ($rawline =~ /^.\s*$/ &&
> + $prevrawline =~ /^.\s*$/ &&
> + $linenr != $last_blank_linenr + 1) {
> + CHK("DOUBLE_EMPTY_LINE",
> + "One blank line separating blocks is generally sufficient\n" . $herecurr);
> + $last_blank_linenr = $linenr;
> + }
> +
> # check for line continuations in quoted strings with odd counts of "
> if ($rawline =~ /\\$/ && $rawline =~ tr/"/"/ % 2) {
> WARN("LINE_CONTINUATIONS",
Pretty sure that will fail with combination which have removed lines. I
have a version here which I am testing with the combinations I have
isolated to far ...
-apw
^ permalink raw reply
* Re: [PATCH v2] checkpatch: add double empty line check
From: Joe Perches @ 2012-11-20 23:41 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Eilon Greenstein, David Rientjes, linux-kernel, netdev
In-Reply-To: <20121120231930.GA27492@localhost>
On Tue, 2012-11-20 at 23:19 +0000, Andy Whitcroft wrote:
> On Tue, Nov 20, 2012 at 01:58:48PM -0800, Joe Perches wrote:
>
> > +# check for multiple blank lines, warn only on the second one in a block
> > + if ($rawline =~ /^.\s*$/ &&
> > + $prevrawline =~ /^.\s*$/ &&
> > + $linenr != $last_blank_linenr + 1) {
> > + CHK("DOUBLE_EMPTY_LINE",
> > + "One blank line separating blocks is generally sufficient\n" . $herecurr);
> > + $last_blank_linenr = $linenr;
> > + }
> > +
> > # check for line continuations in quoted strings with odd counts of "
> > if ($rawline =~ /\\$/ && $rawline =~ tr/"/"/ % 2) {
> > WARN("LINE_CONTINUATIONS",
>
> Pretty sure that will fail with combination which have removed lines.
Not as far as I can tell.
Deleted lines followed by inserted lines seem
to work OK.
This check is located after the test that ensures
the current $line/$rawline is an insertion.
> I have a version here which I am testing with the combinations I have
> isolated to far ...
Enjoy.
Can you please test my proposal against those combinations too?
cheers, Joe
^ permalink raw reply
* Re: 3.6 routing cache regression, multicast loopback broken
From: Julian Anastasov @ 2012-11-21 0:35 UTC (permalink / raw)
To: Maxime Bizon; +Cc: David Miller, netdev
In-Reply-To: <1352133471.12029.43.camel@sakura.staff.proxad.net>
Hello,
On Mon, 5 Nov 2012, Maxime Bizon wrote:
>
> Hi David & all,
>
>
> kernel 3.6 to 3.6.5 (3.5 is working fine)
>
> I have a "sender" sample app that does:
>
> - socket(dgram)
> - setsockopt mcast ttl 8
> - setsockopt mcast loopback
Do you also have CONFIG_IP_MROUTE enabled? I see the
problem with caching both "RTCF_MULTICAST | RTCF_LOCAL" and
"RTCF_MULTICAST" flags to same place but I'm not sure in the
sequence of route lookups for your setup. ip_mc_output does
not care about RTCF_LOCAL when CONFIG_IP_MROUTE is disabled,
so in this case it should loop the packet even on wrong
caching (without RTCF_LOCAL flag).
> - sendto() to 239.0.0.x
>
> and a "receiver" sample app:
>
> - socket(dgram)
> - bind(239.0.0.x)
> - add membership (239.0.0.x)
> - loop on recv()
>
>
> My setup: no default route, "ip route add 239.0.0.0/8 dev eth0", sender
> & receiver running on same host.
>
> If I first start one sender app (on 239.0.0.1), and after a receiver app
> on 239.0.0.1 => no problem
>
> If I first start two or more sender apps (239.0.0.1/239.0.0.2/...), then
> assuming I don't start as many matching receivers, receivers sometimes
> get all data or nothing at all.
>
>
> After digging in __mkroute_output(), I found that unless I'm using a
> default route (fi != NULL), rtable is cached and shared by all senders
> (even those with different mcast addresses)
>
> Since ip_check_mc_rcu() returns different results depending on whether
> fl->daddr is present in device mc_list or not, I don't think we can
> cache this.
>
> The random working/not working effect I get is because add_membership
> flushes the rt_cache, so depending on which sender does sendto() first
> after flush, the cached entry will either use ip_mc_output() or
> ip_output().
Can you try the following patch. If it does not
solve the problem we have to add some debugs in __mkroute_output.
And I'm not sure if this is fatal only when CONFIG_IP_MROUTE
is enabled, I have to spend more time to check the code.
As an optimization, the patch avoids lookup for fnhe
when multicast is not cached because multicasts are
not redirected and they do not learn PMTU.
The patch is not tested. I'll update the commit
message after your tests.
> --
> Maxime
[PATCH net-next] ipv4: do not cache looped multicasts
We have two cases for outgoing multicasts
depending on the membership: with or without RTCF_LOCAL.
Currently, we use caching only if route to 224/4 is used.
As we can not cache for both cases, optimize the caching
for senders only, do not cache routes with RTCF_LOCAL
flag set.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/route.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 5b58788..0d73f86 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1785,6 +1785,7 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
if (dev_out->flags & IFF_LOOPBACK)
flags |= RTCF_LOCAL;
+ do_cache = true;
if (type == RTN_BROADCAST) {
flags |= RTCF_BROADCAST | RTCF_LOCAL;
fi = NULL;
@@ -1793,6 +1794,8 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
if (!ip_check_mc_rcu(in_dev, fl4->daddr, fl4->saddr,
fl4->flowi4_proto))
flags &= ~RTCF_LOCAL;
+ else
+ do_cache = false;
/* If multicast route do not exist use
* default one, but do not gateway in this case.
* Yes, it is hack.
@@ -1802,8 +1805,8 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
}
fnhe = NULL;
- do_cache = fi != NULL;
- if (fi) {
+ do_cache &= fi != NULL;
+ if (do_cache) {
struct rtable __rcu **prth;
struct fib_nh *nh = &FIB_RES_NH(*res);
--
1.7.3.4
^ permalink raw reply related
* Re: [Xen-devel] compound skb frag pages appearing in start_xmit
From: ANNIE LI @ 2012-11-21 2:42 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefan Bader, Eric Dumazet, Sander Eikelenboom,
netdev@vger.kernel.org, xen-devel, Konrad Rzeszutek Wilk,
Marcos E. Matsunaga, Eric Dumazet
In-Reply-To: <1353411413.13542.31.camel@zakaz.uk.xensource.com>
On 2012-11-20 19:36, Ian Campbell wrote:
> On Tue, 2012-11-20 at 09:21 +0000, Ian Campbell wrote:
>> On Tue, 2012-11-20 at 08:30 +0000, Stefan Bader wrote:
>>>>> When I tried to rebase my persistent grant netfront/netback patch on
>>>>> latest kernel, netperf/netserver test never succeeded. I did some test
>>>>> to find out that v3.6-rc7 works fine, but v3.7-rc1, v3.7-rc2 and
>>>>> v3.7-rc4 does not succeed in netperf/netserver test. So I keep my
>>>>> persistent grant patch only based on v3.4-rc3 now.
>>>>> Konrad thought about commit 6a8ed462f16b8455eec5ae00eb6014159a6721f0 in
>>>>> v3.7-rc1, and suggested me to test your debug patch in netfront. This
>>>>> BUG_ON happens soon after running the netperf/netserver test case.
>>>>> Thanks
>>>>> Annie
>>>> Is there any progression with this bug (rc6 is out the door, so the
>>> release of 3.7-final seems to be eminent and this bug completely
>>> cripples any networking with guests) ?
>>> +1 on that. I was testing yesterday with a PVM domU running 3.7-rc5 on Xen 4.2
>>> (but also reported from EC2 running Xen 3.4.3) c with one VCPU. I actually can
>>> trigger it by just ssh'ing into the domU (from another machine) and then run
>>> "find /". Output starts to stutter and then stops completely. When this happens
>>> a new connection still can be made and as long as only shorter output is
>>> generated the ssh connection is ok. From a dump taken it looks like user-space
>>> is waiting in some select call (without any warnon I rather won't see the tx path).
>> Annie, are you still looking into this or shall I?
> I'll assume that silence == No. Will post a patch shortly.
Sorry for the delay response, I did create a patch, but did not post it
out in time.
Thanks
Annie
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox