* Re: [RFC v2 2/2] e100: Support RXFCS feature flag.
From: Ben Greear @ 2011-06-29 14:22 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev
In-Reply-To: <BANLkTiknCV1HknVpEdK97yU8eJwaJ5Y5Ag@mail.gmail.com>
On 06/29/2011 04:37 AM, Michał Mirosław wrote:
> 2011/6/24<greearb@candelatech.com>:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> This allows e100 to be configured to append the
>> Ethernet FCS to the skb.
>>
>> Useful for sniffing networks.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>> ---
>> :100644 100644 c1352c6... 761f6f5... M drivers/net/e100.c
>> drivers/net/e100.c | 15 ++++++++++++---
>> 1 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
>> index c1352c6..761f6f5 100644
>> --- a/drivers/net/e100.c
>> +++ b/drivers/net/e100.c
>> @@ -1089,6 +1089,7 @@ static void e100_configure(struct nic *nic, struct cb *cb, struct sk_buff *skb)
>> {
>> struct config *config =&cb->u.config;
>> u8 *c = (u8 *)config;
>> + struct net_device *netdev = nic->netdev;
>>
>> cb->command = cpu_to_le16(cb_config);
>>
>> @@ -1132,6 +1133,9 @@ static void e100_configure(struct nic *nic, struct cb *cb, struct sk_buff *skb)
>> config->promiscuous_mode = 0x1; /* 1=on, 0=off */
>> }
>>
>> + if (netdev->wanted_features& NETIF_F_RXFCS)
>> + config->rx_crc_transfer = 0x1; /* 1=save, 0=discard */
>> +
>
> You should check netdev->features here.
I thought 'features' was what the NIC could support, and wanted_features
was what the NIC was currently configured to support? I don't want
to rx the CRC all the time, just when users enable it...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] sctp: Enforce maximum retransmissions during shutdown
From: Vladislav Yasevich @ 2011-06-29 14:20 UTC (permalink / raw)
To: netdev, davem, Wei Yongjun, Sridhar Samudrala, linux-sctp
In-Reply-To: <20110629135704.GB10085@canuck.infradead.org>
On 06/29/2011 09:57 AM, Thomas Graf wrote:
> When initiating a graceful shutdown while having data chunks
> on the retransmission queue with a peer which is in zero
> window mode the shutdown is never completed because the
> retransmission error count is reset periodically by the
> following two rules:
>
> - Do not timeout association while doing zero window probe.
> - Reset overall error count when a heartbeat request has
> been acknowledged.
>
> The graceful shutdown will wait for all outstanding TSN to be
> acknowledged before sending the SHUTDOWN request. This never
> happens due to the peer's zero window not acknowledging the
> continuously retransmitted data chunks. Although the error
> counter is incremented for each failed retransmission done
> via the T3-rtx timer, the receiving of the SACK sent in return
> to the retransmission, announcing the zero window, clears the
> error count again immediately.
>
> Also heartbeat requests continue to be sent periodically. The
> peer acknowledges these requests causing the error counter to
> be reset as well.
>
> This patch changes behaviour to only reset the overall error
> counter for the above rules while not in shutdown. This means
> that if already queued data can't be transmitted in max_retrans
> attempts we ABORT because a graceful shutdown is obviously not
> possible.
>
> The issue can be easily reproduced by establishing a sctp
> association over the loopback device, constantly queueing data
> at the sender while not reading any at the receiver. Wait for
> the window to reach zero, then initiate a shutdown by killing
> both processes simultaneously. The association will never be
> freed and the chunks on the retransmission queue will be
> retransmitted indefinitely.
>
Hi Tomas
I think in this particular case, the receiver has to terminate, not the sender.
Look at how tcp_close() handles this.
As long as receiver is available, the sender should continue to try
sending data.
Once the receiver is no longer available (killed), if it had queued data, it should
trigger an ABORT since it lost data. That ABORT will stop the sender as well.
-vlad
> Signed-off-by: Thomas Graf <tgraf@infradead.org>
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 1c88c89..14a5295 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1629,10 +1629,15 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> * A sender is doing zero window probing when the
> * receiver's advertised window is zero, and there is
> * only one data chunk in flight to the receiver.
> + *
> + * Allow the association to timeout if SHUTDOWN is
> + * pending. We have no interest in keeping the
> + * association around forever.
> */
> if (!q->asoc->peer.rwnd &&
> !list_empty(&tlist) &&
> - (sack_ctsn+2 == q->asoc->next_tsn)) {
> + (sack_ctsn+2 == q->asoc->next_tsn) &&
> + !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) {
> SCTP_DEBUG_PRINTK("%s: SACK received for zero "
> "window probe: %u\n",
> __func__, sack_ctsn);
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index 534c2e5..fa92f4d6 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -670,10 +670,21 @@ static void sctp_cmd_transport_on(sctp_cmd_seq_t *cmds,
> /* 8.3 Upon the receipt of the HEARTBEAT ACK, the sender of the
> * HEARTBEAT should clear the error counter of the destination
> * transport address to which the HEARTBEAT was sent.
> - * The association's overall error count is also cleared.
> */
> t->error_count = 0;
> - t->asoc->overall_error_count = 0;
> +
> + /*
> + * Although RFC2960 and RFC4460 specify that the overall error
> + * count must be cleared when a HEARTBEAT ACK is received this
> + * behaviour may prevent the maximum retransmission count from
> + * being reached while in SHUTDOWN. If the peer keeps its window
> + * closed not acknowledging any outstanding TSN we may rely on
> + * reaching the max_retrans limit via the T3-rtx timer to close
> + * the association which will never happen if the error count is
> + * reset every heartbeat interval.
> + */
> + if (!(t->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING))
> + t->asoc->overall_error_count = 0;
>
> /* Clear the hb_sent flag to signal that we had a good
> * acknowledgement.
>
^ permalink raw reply
* Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Vladislav Yasevich @ 2011-06-29 14:09 UTC (permalink / raw)
To: Sridhar Samudrala, linux-sctp, netdev
In-Reply-To: <20110627091136.GA10085@canuck.infradead.org>
On 06/27/2011 05:11 AM, Thomas Graf wrote:
> On Fri, Jun 24, 2011 at 11:21:11AM -0400, Vladislav Yasevich wrote:
>> We, instead of trying to underestimate the window size, try to over-estimate it.
>> Almost every implementation has some kind of overhead and we don't know how
>> that overhead will impact the window. As such we try to temporarily account for this
>> overhead.
>
> I looked into this some more and it turns out that adding per-packet
> overhead is difficult because when we mark chunks for retransmissions
> we have to add its data size to the peer rwnd again but we have no
> idea how many packets were used for the initial transmission. Therefore
> if we add an overhead, we can only do so per chunk.
>
Good point.
>> If we treat the window as strictly available data, then we may end up sending a lot more traffic
>> then the window can take thus causing us to enter 0 window probe and potential retransmission
>> issues that will trigger congestion control.
>> We'd like to avoid that so we put some overhead into our computations. It may not be ideal
>> since we do this on a per-chunk basis. It could probably be done on per-packet basis instead.
>> This way, we'll essentially over-estimate but under-subscribe our current view of the peers
>> window. So in one shot, we are not going to over-fill it and will get an updated view next
>> time the SACK arrives.
>
> What kind of configuration showed this behaviour? Did you observe that
> issue with Linux peers?
Yes, this was observed with linux peers.
> If a peer announces an a_rwnd which it cannot
> handle then that is a implementation bug of the receiver and not of the
> sender.
>
> We won't go into zero window probe mode that easily, remember it's only
> one packet allowed in flight while rwnd is 0. We always take into
> account outstanding bytes when updating rwnd with a_rwnd so our view of
> the peer's rwnd is very accurate.
>
> In fact the RFC clearly states when and how to update the peer rwnd:
>
> B) Any time a DATA chunk is transmitted (or retransmitted) to a peer,
> the endpoint subtracts the data size of the chunk from the rwnd of
> that peer.
>
> I would like to try and reproduce the behaviour you have observed and
> fix it without cutting our ability to produce pmtu maxed packets with
> small data chunks.
>
This was easily reproducible with sctp_darn tool using 1 byte payload.
This was a while ago, and I dont' know if anyone has tried it recently.
-vlad
^ permalink raw reply
* Re: [PATCH 00/12] Fix various section mismatches and build errors.
From: James Bottomley @ 2011-06-29 13:58 UTC (permalink / raw)
To: Ralf Baechle
Cc: David Miller, akpm, alan, bcasavan, airlied, grundler, perex,
rpurdie, klassert, tj, dri-devel, linux-kernel, linux-mips,
linux-scsi, linux-serial, netdev
In-Reply-To: <20110629130711.GA15649@linux-mips.org>
On Wed, 2011-06-29 at 14:07 +0100, Ralf Baechle wrote:
> On Mon, Jun 27, 2011 at 10:12:57PM -0700, David Miller wrote:
>
> > commit 948252cb9e01d65a89ecadf67be5018351eee15e
> > Author: David S. Miller <davem@davemloft.net>
> > Date: Tue May 31 19:27:48 2011 -0700
> >
> > Revert "net: fix section mismatches"
> >
> > This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4.
> >
> > It causes new build regressions with gcc-4.2 which is
> > pretty common on non-x86 platforms.
> >
> > Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > and postings that led to this revert including:
> >
> > http://marc.info/?l=linux-netdev&m=130653748205263&w=2
>
> Thanks for the pointers; I looked into it a bit deeper and found that the
> construct which hppa64-linux-gcc 4.2.4 doesn't like is the combination of
> const and __devinitconst __devinitdata.
>
> My patches are minimalistic and don't do any constification and seem to
> work fine for PA-RISC.
>
> A possible alternative to allow the use of Michał's reverted patch would
> be to conditionalize the definition of __devinitconst. There is no
> user of __devexitconst so I left that unchanged.
To be honest, my own take on this is that, apart from the compiler
cockups trying to do read only annotations, which affect various
versions of gcc not just the parisc ones, the _devX annotations are
pretty pointless. They only really do something in the non-hotplug
case, so since 95% of the world seems to use hotplug now and the other
5% doesn't care that much about the odd page of memory (which you rarely
get, since modules sections are accumulated per module, not aggregate),
I'd just favour stripping __init and __exit where there's a problem.
I think we should simply concentrate on __init and __exit; that's where
most of the discard value lies and stop expending huge efforts on the
__devX stuff which adds huge complexity for no real gain.
James
^ permalink raw reply
* [PATCH] sctp: Enforce maximum retransmissions during shutdown
From: Thomas Graf @ 2011-06-29 13:57 UTC (permalink / raw)
To: netdev; +Cc: davem, Wei Yongjun, Vlad Yasevich, Sridhar Samudrala, linux-sctp
When initiating a graceful shutdown while having data chunks
on the retransmission queue with a peer which is in zero
window mode the shutdown is never completed because the
retransmission error count is reset periodically by the
following two rules:
- Do not timeout association while doing zero window probe.
- Reset overall error count when a heartbeat request has
been acknowledged.
The graceful shutdown will wait for all outstanding TSN to be
acknowledged before sending the SHUTDOWN request. This never
happens due to the peer's zero window not acknowledging the
continuously retransmitted data chunks. Although the error
counter is incremented for each failed retransmission done
via the T3-rtx timer, the receiving of the SACK sent in return
to the retransmission, announcing the zero window, clears the
error count again immediately.
Also heartbeat requests continue to be sent periodically. The
peer acknowledges these requests causing the error counter to
be reset as well.
This patch changes behaviour to only reset the overall error
counter for the above rules while not in shutdown. This means
that if already queued data can't be transmitted in max_retrans
attempts we ABORT because a graceful shutdown is obviously not
possible.
The issue can be easily reproduced by establishing a sctp
association over the loopback device, constantly queueing data
at the sender while not reading any at the receiver. Wait for
the window to reach zero, then initiate a shutdown by killing
both processes simultaneously. The association will never be
freed and the chunks on the retransmission queue will be
retransmitted indefinitely.
Signed-off-by: Thomas Graf <tgraf@infradead.org>
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 1c88c89..14a5295 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -1629,10 +1629,15 @@ static void sctp_check_transmitted(struct sctp_outq *q,
* A sender is doing zero window probing when the
* receiver's advertised window is zero, and there is
* only one data chunk in flight to the receiver.
+ *
+ * Allow the association to timeout if SHUTDOWN is
+ * pending. We have no interest in keeping the
+ * association around forever.
*/
if (!q->asoc->peer.rwnd &&
!list_empty(&tlist) &&
- (sack_ctsn+2 == q->asoc->next_tsn)) {
+ (sack_ctsn+2 == q->asoc->next_tsn) &&
+ !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) {
SCTP_DEBUG_PRINTK("%s: SACK received for zero "
"window probe: %u\n",
__func__, sack_ctsn);
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index 534c2e5..fa92f4d6 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -670,10 +670,21 @@ static void sctp_cmd_transport_on(sctp_cmd_seq_t *cmds,
/* 8.3 Upon the receipt of the HEARTBEAT ACK, the sender of the
* HEARTBEAT should clear the error counter of the destination
* transport address to which the HEARTBEAT was sent.
- * The association's overall error count is also cleared.
*/
t->error_count = 0;
- t->asoc->overall_error_count = 0;
+
+ /*
+ * Although RFC2960 and RFC4460 specify that the overall error
+ * count must be cleared when a HEARTBEAT ACK is received this
+ * behaviour may prevent the maximum retransmission count from
+ * being reached while in SHUTDOWN. If the peer keeps its window
+ * closed not acknowledging any outstanding TSN we may rely on
+ * reaching the max_retrans limit via the T3-rtx timer to close
+ * the association which will never happen if the error count is
+ * reset every heartbeat interval.
+ */
+ if (!(t->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING))
+ t->asoc->overall_error_count = 0;
/* Clear the hb_sent flag to signal that we had a good
* acknowledgement.
^ permalink raw reply related
* Re: Remove over-broad module alias from zaurus.
From: David Miller @ 2011-06-29 13:09 UTC (permalink / raw)
To: greg; +Cc: davej, netdev
In-Reply-To: <20110627204207.GB5341@kroah.com>
From: Greg KH <greg@kroah.com>
Date: Mon, 27 Jun 2011 13:42:07 -0700
> This module and a bunch of dependancies are getting loaded on several
> of laptops I have (probably picking up the mobile broadband device),
> that have nothing to do with zaurus. Matching by class without
> any vendor/device pair isn't the right thing to do here, as it
> will prevent any other driver from correctly binding to it.
> (Or in the absense of a driver, will just waste time & memory by
> unnecessarily loading modules)
>
> Signed-off-by: Dave Jones <davej@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: drop Michael from bfin_mac driver
From: David Miller @ 2011-06-29 13:07 UTC (permalink / raw)
To: Michael.Hennerich; +Cc: vapier, uclinux-dist-devel, netdev, linux-kernel
In-Reply-To: <544AC56F16B56944AEC3BD4E3D5917713EA0AEEA8C@LIMKCMBX1.ad.analog.com>
From: "Hennerich, Michael" <Michael.Hennerich@analog.com>
Date: Mon, 27 Jun 2011 19:28:11 +0100
> Mike Frysinger wrote on 2011-06-27:
>> We want people to just use the list now rather than hitting up people
>> who are no longer responsible for it.
>>
>> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
...
> Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 00/12] Fix various section mismatches and build errors.
From: Ralf Baechle @ 2011-06-29 13:07 UTC (permalink / raw)
To: David Miller
Cc: akpm, alan, bcasavan, airlied, grundler, JBottomley, perex,
rpurdie, klassert, tj, dri-devel, linux-kernel, linux-mips,
linux-scsi, linux-serial, netdev
In-Reply-To: <20110627.221257.1290251511587162468.davem@davemloft.net>
On Mon, Jun 27, 2011 at 10:12:57PM -0700, David Miller wrote:
> commit 948252cb9e01d65a89ecadf67be5018351eee15e
> Author: David S. Miller <davem@davemloft.net>
> Date: Tue May 31 19:27:48 2011 -0700
>
> Revert "net: fix section mismatches"
>
> This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4.
>
> It causes new build regressions with gcc-4.2 which is
> pretty common on non-x86 platforms.
>
> Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> and postings that led to this revert including:
>
> http://marc.info/?l=linux-netdev&m=130653748205263&w=2
Thanks for the pointers; I looked into it a bit deeper and found that the
construct which hppa64-linux-gcc 4.2.4 doesn't like is the combination of
const and __devinitconst __devinitdata.
My patches are minimalistic and don't do any constification and seem to
work fine for PA-RISC.
A possible alternative to allow the use of Michał's reverted patch would
be to conditionalize the definition of __devinitconst. There is no
user of __devexitconst so I left that unchanged.
Ralf
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
include/linux/init.h | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/init.h b/include/linux/init.h
index 577671c..e12fd85 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -84,7 +84,15 @@
/* Used for HOTPLUG */
#define __devinit __section(.devinit.text) __cold
#define __devinitdata __section(.devinit.data)
+#if defined __GNUC__ && (__GNUC__ == 4) && (__GNUC_MINOR__ == 2)
+/*
+ * GCC 4.2 will sometimes throw an error if the combination of const and
+ * __devinitconst is being used. As a workaround make __devinitconst a noop
+ */
+#define __devinitconst
+#else
#define __devinitconst __section(.devinit.rodata)
+#endif
#define __devexit __section(.devexit.text) __exitused __cold
#define __devexitdata __section(.devexit.data)
#define __devexitconst __section(.devexit.rodata)
^ permalink raw reply related
* Re: [PATCH 9/9] myri10ge: Update MAINTAINERS
From: David Miller @ 2011-06-29 13:04 UTC (permalink / raw)
To: mason; +Cc: netdev, gallatin
In-Reply-To: <1309187108-12715-9-git-send-email-mason@myri.com>
From: Jon Mason <mason@myri.com>
Date: Mon, 27 Jun 2011 10:05:08 -0500
> Update MAINTAINERS to refelect new people working on myri10ge
>
> Signed-off-by: Jon Mason <mason@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH 8/9] myri10ge: update version
From: David Miller @ 2011-06-29 13:04 UTC (permalink / raw)
To: mason; +Cc: netdev, gallatin
In-Reply-To: <1309187108-12715-8-git-send-email-mason@myri.com>
From: Jon Mason <mason@myri.com>
Date: Mon, 27 Jun 2011 10:05:07 -0500
> Update version and copyright
>
> Signed-off-by: Jon Mason <mason@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH 7/9 v2] myri10ge: misc style cleanups
From: David Miller @ 2011-06-29 13:03 UTC (permalink / raw)
To: mason; +Cc: netdev, gallatin
In-Reply-To: <20110627205640.GB18978@myri.com>
From: Jon Mason <mason@myri.com>
Date: Mon, 27 Jun 2011 15:56:41 -0500
> Miscellaneous white space, style, and other cleanups
>
> v2 includes corrections from Joe Perches
>
> Signed-off-by: Jon Mason <mason@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH 6/9] myri10ge: remove unnecessary read of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-29 13:03 UTC (permalink / raw)
To: mason; +Cc: netdev, gallatin
In-Reply-To: <1309187108-12715-6-git-send-email-mason@myri.com>
From: Jon Mason <mason@myri.com>
Date: Mon, 27 Jun 2011 10:05:05 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it.
>
> Signed-off-by: Jon Mason <mason@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH 5/9] myri10ge: add support for set_phys_id
From: David Miller @ 2011-06-29 13:03 UTC (permalink / raw)
To: mason; +Cc: netdev, gallatin
In-Reply-To: <1309187108-12715-5-git-send-email-mason@myri.com>
From: Jon Mason <mason@myri.com>
Date: Mon, 27 Jun 2011 10:05:04 -0500
> Add myri10ge driver support for the ethtool identify operation.
> NOTE: Rather than blinking (which is the normal case), when identify is
> used, the yellow LED turns solid.
>
> Signed-off-by: Jon Mason <mason@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/9] myri10ge: allow small_bytes = 0
From: David Miller @ 2011-06-29 13:03 UTC (permalink / raw)
To: mason; +Cc: netdev, gallatin
In-Reply-To: <1309187108-12715-4-git-send-email-mason@myri.com>
From: Jon Mason <mason@myri.com>
Date: Mon, 27 Jun 2011 10:05:03 -0500
> Allow page-based receive to work when small_bytes is set to 0.
>
> Signed-off-by: Jon Mason <mason@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/9 v3] myri10ge: rework parity error check and cleanup
From: David Miller @ 2011-06-29 13:02 UTC (permalink / raw)
To: mason; +Cc: netdev, gallatin
In-Reply-To: <20110628035727.GA23979@myri.com>
From: Jon Mason <mason@myri.com>
Date: Mon, 27 Jun 2011 22:57:28 -0500
> Clean up watchdog reset code:
> - move code that checks for stuck slice to a common routine
> - unless there is a confirmed h/w fault, verify that a stuck
> slice is still stuck in the watchdog worker; if the slice is no
> longer stuck, abort the reset.
> - this removes an egregious 2000ms pause in the watchdog worker that
> was a diagnostic aid (to look for spurious resets) the snuck into
> production code.
>
> v3 includes corrections from Joe Perches
>
> Signed-off-by: Jon Mason <mason@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/9] myri10ge: Mask PCI Surprise Link Down Events
From: David Miller @ 2011-06-29 13:02 UTC (permalink / raw)
To: mason; +Cc: netdev, gallatin
In-Reply-To: <1309187108-12715-2-git-send-email-mason@myri.com>
From: Jon Mason <mason@myri.com>
Date: Mon, 27 Jun 2011 10:05:01 -0500
> A SRAM parity error can cause a surprise link down. Since We can
> recover from SRAM parity errors, mask PCI surprise down events.
>
> Signed-off-by: Jon Mason <mason@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/9] myri10ge: ensure tx queues remain stopped
From: David Miller @ 2011-06-29 13:02 UTC (permalink / raw)
To: mason; +Cc: netdev, gallatin
In-Reply-To: <1309187108-12715-1-git-send-email-mason@myri.com>
From: Jon Mason <mason@myri.com>
Date: Mon, 27 Jun 2011 10:05:00 -0500
> Ensure that our tx queues remain stopped when we stop them in
> myri10ge_close(). Not doing so can potentially lead to traffic being
> transmitted when the interface is removed, which can lead to NULL
> pointer dereferences.
>
> Signed-off-by: Jon Mason <mason@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/can: activate bit-timing calculation and netlink based drivers by default
From: David Miller @ 2011-06-29 12:58 UTC (permalink / raw)
To: mkl; +Cc: socketcan-users, wg, netdev
In-Reply-To: <1309160391-22486-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 27 Jun 2011 09:39:51 +0200
> The two options "CAN bit-timing calculation" and
> "Platform CAN drivers with Netlink support" have a "default Y". In order to
> activate them by default, change to "default y".
>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH]rionet: fix NULL pointer dereference in rionet_remove
From: David Miller @ 2011-06-29 12:57 UTC (permalink / raw)
To: synmyth; +Cc: netdev, mporter, jj, cmdkhh
In-Reply-To: <4e098bf5.87f62a0a.4c71.571a@mx.google.com>
From: Yinglin Luan <synmyth@gmail.com>
Date: Sun, 26 Jun 2011 12:12:12 +0800
> Function rionet_remove initializes local variable 'ndev' to NULL
> and do nothing changes before the call to unregister_netdev(ndev),
> this could cause a NULL pointer dereference.
>
> Reported-by: Jesper Juhl <jj@chaosbits.net>
> Signed-off-by: Yinglin Luan <synmyth@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH V3 1/1] DSA: Enable cascading in multi-chip 6131 configuration
From: David Miller @ 2011-06-29 12:54 UTC (permalink / raw)
To: barry; +Cc: netdev, buytenh
In-Reply-To: <1308981231-2561-1-git-send-email-barry@grussling.com>
From: Barry Grussling <barry@grussling.com>
Date: Fri, 24 Jun 2011 22:53:51 -0700
> From: Barry Grussling <barry@grussling.com>
>
> This patch enables the 6131 family of chips to forward DSA
> packets to other switch chips. This is needed if multiple
> DSA chips are used in a device. Without this patch the
> chip will drop any DSA packets not destined for it.
>
> This patch only enables the forwarding of DSA packets if
> multiple chips are used in the switch configuration.
>
> Signed-off-by: Barry Grussling <barry@grussling.com>
Applied.
^ permalink raw reply
* Re: [PATCH] caif: Fix recieve/receive typo
From: David Miller @ 2011-06-29 12:52 UTC (permalink / raw)
To: joe; +Cc: sjur.brandeland, netdev, linux-kernel
In-Reply-To: <661bd38a1d84b746ad6879baf83b3a98c93676e6.1308938176.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 24 Jun 2011 10:59:19 -0700
> Just spelling fixes.
>
> Actually, a twofer with vaiables/variables as well.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* [PATCH net-next] net: de4x5: Omit check for multicast bit in netdev_for_each_mc_addr
From: Tobias Klauser @ 2011-06-29 12:16 UTC (permalink / raw)
To: David S. Miller, Grant Grundler; +Cc: netdev
There is no need to check for the address being a multicast address in
the netdev_for_each_mc_addr loop, so remove it.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/tulip/de4x5.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/net/tulip/de4x5.c b/drivers/net/tulip/de4x5.c
index efaa1d6..0c3151a 100644
--- a/drivers/net/tulip/de4x5.c
+++ b/drivers/net/tulip/de4x5.c
@@ -1954,7 +1954,6 @@ SetMulticastFilter(struct net_device *dev)
u16 hashcode;
u32 omr, crc;
char *pa;
- unsigned char *addrs;
omr = inl(DE4X5_OMR);
omr &= ~(OMR_PR | OMR_PM);
@@ -1964,9 +1963,7 @@ SetMulticastFilter(struct net_device *dev)
omr |= OMR_PM; /* Pass all multicasts */
} else if (lp->setup_f == HASH_PERF) { /* Hash Filtering */
netdev_for_each_mc_addr(ha, dev) {
- addrs = ha->addr;
- if ((*addrs & 0x01) == 1) { /* multicast address? */
- crc = ether_crc_le(ETH_ALEN, addrs);
+ crc = ether_crc_le(ETH_ALEN, ha->addr);
hashcode = crc & HASH_BITS; /* hashcode is 9 LSb of CRC */
byte = hashcode >> 3; /* bit[3-8] -> byte in filter */
@@ -1977,7 +1974,6 @@ SetMulticastFilter(struct net_device *dev)
byte -= 1;
}
lp->setup_frame[byte] |= bit;
- }
}
} else { /* Perfect filtering */
netdev_for_each_mc_addr(ha, dev) {
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: ucc_geth: Omit check for multicast bit in netdev_for_each_mc_addr
From: Tobias Klauser @ 2011-06-29 12:16 UTC (permalink / raw)
To: David S. Miller, Li Yang; +Cc: netdev, linuxppc-dev
There is no need to check for the address being a multicast address in
the netdev_for_each_mc_addr loop, so remove it.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ucc_geth.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 3127700..d3465ab 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2030,11 +2030,6 @@ static void ucc_geth_set_multi(struct net_device *dev)
out_be32(&p_82xx_addr_filt->gaddr_l, 0x0);
netdev_for_each_mc_addr(ha, dev) {
- /* Only support group multicast for now.
- */
- if (!is_multicast_ether_addr(ha->addr))
- continue;
-
/* Ask CPM to run CRC and set bit in
* filter mask.
*/
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: depca: Omit check for multicast bit in netdev_for_each_mc_addr
From: Tobias Klauser @ 2011-06-29 12:15 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
There is no need to check for the address being a multicast address in
the netdev_for_each_mc_addr loop, so remove it.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/depca.c | 21 ++++++++-------------
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/net/depca.c b/drivers/net/depca.c
index d54a0e9..a7ccaa6 100644
--- a/drivers/net/depca.c
+++ b/drivers/net/depca.c
@@ -1270,7 +1270,6 @@ static void SetMulticastFilter(struct net_device *dev)
{
struct depca_private *lp = netdev_priv(dev);
struct netdev_hw_addr *ha;
- char *addrs;
int i, j, bit, byte;
u16 hashcode;
u32 crc;
@@ -1285,19 +1284,15 @@ static void SetMulticastFilter(struct net_device *dev)
}
/* Add multicast addresses */
netdev_for_each_mc_addr(ha, dev) {
- addrs = ha->addr;
- if ((*addrs & 0x01) == 1) { /* multicast address? */
- crc = ether_crc(ETH_ALEN, addrs);
- hashcode = (crc & 1); /* hashcode is 6 LSb of CRC ... */
- for (j = 0; j < 5; j++) { /* ... in reverse order. */
- hashcode = (hashcode << 1) | ((crc >>= 1) & 1);
- }
-
-
- byte = hashcode >> 3; /* bit[3-5] -> byte in filter */
- bit = 1 << (hashcode & 0x07); /* bit[0-2] -> bit in byte */
- lp->init_block.mcast_table[byte] |= bit;
+ crc = ether_crc(ETH_ALEN, ha->addr);
+ hashcode = (crc & 1); /* hashcode is 6 LSb of CRC ... */
+ for (j = 0; j < 5; j++) { /* ... in reverse order. */
+ hashcode = (hashcode << 1) | ((crc >>= 1) & 1);
}
+
+ byte = hashcode >> 3; /* bit[3-5] -> byte in filter */
+ bit = 1 << (hashcode & 0x07); /* bit[0-2] -> bit in byte */
+ lp->init_block.mcast_table[byte] |= bit;
}
}
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: iseries_veth: Omit check for multicast bit in netdev_for_each_mc_addr
From: Tobias Klauser @ 2011-06-29 12:15 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
There is no need to check for the address being a multicast address in
the netdev_for_each_mc_addr loop, so remove it.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/iseries_veth.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
index b6c296f..242bf52 100644
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -964,11 +964,9 @@ static void veth_set_multicast_list(struct net_device *dev)
u8 *addr = ha->addr;
u64 xaddr = 0;
- if (addr[0] & 0x01) {/* multicast address? */
- memcpy(&xaddr, addr, ETH_ALEN);
- port->mcast_addr[port->num_mcast] = xaddr;
- port->num_mcast++;
- }
+ memcpy(&xaddr, addr, ETH_ALEN);
+ port->mcast_addr[port->num_mcast] = xaddr;
+ port->num_mcast++;
}
}
--
1.7.5.4
^ permalink raw reply related
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