* Re: [net-next-2.6 PATCH] af_packet: do not accept mc address smaller then dev->addr_len in packet_mc_add()
From: David Miller @ 2010-02-26 12:19 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100225095703.GB2667@psychotron.lab.eng.brq.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 25 Feb 2010 10:57:04 +0100
> There is no point of accepting an address of smaller length than dev->addr_len
> here. Therefore change this for stonger check.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] myri10ge: optimize 4k-boundary check when stocking rx pages
From: David Miller @ 2010-02-26 12:19 UTC (permalink / raw)
To: brice; +Cc: netdev
In-Reply-To: <4B85A407.5050800@myri.com>
From: Brice Goglin <brice@myri.com>
Date: Wed, 24 Feb 2010 23:11:19 +0100
> Small optimization to the code which checks to see if we'd cross
> a 4K boundary when stocking RX ring.
>
> Signed-off-by: Brice Goglin <brice@myri.com>
> Signed-off-by: Andrew Gallatin <gallatin@myri.com>
> Signed-off-by: Guillaume Morin <guillaume@morinfr.org>
Applied.
^ permalink raw reply
* Re: [PATCH] be2net: fix tx completion polling
From: David Miller @ 2010-02-26 12:19 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100225115516.GA10784@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Thu, 25 Feb 2010 17:25:16 +0530
> In tx/mcc polling, napi_complete() is being incorrectly called
> before reaping tx completions. This can cause tx compl processing
> to be scheduled on another cpu concurrently which can result in a panic.
> This if fixed by calling napi complete() after tx/mcc compl processing
> but before re-enabling interrupts (via a cq notify).
>
> Pls apply to net-2.6.
net-2.6 is closed, 2.6.33 has been released.
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
This patch does not apply to net-next-2.6
^ permalink raw reply
* (unknown),
From: POWERBALL-WHEEL E-GAME LOTTO 2010 UK @ 2010-02-26 1:47 UTC (permalink / raw)
POWERBALL-WHEEL E-GAME LOTTO 2010 UK Ref No.PBL/CN/6654/CP winning
number PBL2348974321. This is to inform you that your email address
have just won a cash price of GBP5,500,000.00 POUNDS in the UK
powerball lotto Online Wheel E-game.you are to contact the online
claims agent below:
Name: Mr. Cut Smith
Email: claimsdept092009@hotmail.com
EMAIL: powerballlotto19@yahoo.com
Tel: +44-704-575-1007
Tel: +44-703-592-5669
Provide the Following Information:Name, Address, Age, Sex, Tel, Occupationon.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [PATCH 0/7] pci: Add VPD parsing support
From: David Miller @ 2010-02-26 12:13 UTC (permalink / raw)
To: mcarlson; +Cc: jbarnes, linux-pci, netdev, andy
In-Reply-To: <1267121962-6077-1-git-send-email-mcarlson@broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Thu, 25 Feb 2010 10:19:15 -0800
> This patch adds code to help parse a device's VPD. The bnx2 and tg3
> network drivers are modified as an example on how to use the API. I
> believe the bnx2x driver will also use this API in the future.
Matt, once the PCI folks take your VPD interfaces and defines,
resubmit the network driver changes to me.
Thanks.
^ permalink raw reply
* Re: [PATCH 6/6] C/R: Add checkpoint support to macvlan driver
From: David Miller @ 2010-02-26 12:09 UTC (permalink / raw)
To: danms; +Cc: containers, benjamin.thery, den, ebiederm, netdev
In-Reply-To: <1267130595-23637-7-git-send-email-danms@us.ibm.com>
From: Dan Smith <danms@us.ibm.com>
Date: Thu, 25 Feb 2010 12:43:15 -0800
> This has an small hidden gotcha. Since the macvlan device is moved
> completely into a container's network namespace, the init netns cannot
> freeze traffic to and from it in order to migrate live network connections
> by simply utilizing its netfilter tables. A helper process in the container
> or something like what was recently discussed on the containers list[1]
> would provide a way to do this.
>
> [1]: https://lists.linux-foundation.org/pipermail/containers/2010-February/023001.html
>
> Signed-off-by: Dan Smith <danms@us.ibm.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 5/6] C/R: Add a checkpoint handler to the 'sit' device
From: David Miller @ 2010-02-26 12:09 UTC (permalink / raw)
To: danms; +Cc: containers, benjamin.thery, den, ebiederm, netdev
In-Reply-To: <1267130595-23637-6-git-send-email-danms@us.ibm.com>
From: Dan Smith <danms@us.ibm.com>
Date: Thu, 25 Feb 2010 12:43:14 -0800
> This handler doesn't really do much to checkpoint the device, other
> than the minimum required to support the restart process. When we
> add IPv6 support to this, then we can fill this out.
>
> This allows us to avoid skipping unsupported interfaces on a normal
> system.
>
> Signed-off-by: Dan Smith <danms@us.ibm.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 4/6] C/R: Add loopback checkpoint support (v2)
From: David Miller @ 2010-02-26 12:09 UTC (permalink / raw)
To: danms; +Cc: containers, benjamin.thery, den, ebiederm, netdev
In-Reply-To: <1267130595-23637-5-git-send-email-danms@us.ibm.com>
From: Dan Smith <danms@us.ibm.com>
Date: Thu, 25 Feb 2010 12:43:13 -0800
> Adds a small ndo_checkpoint() handler for loopback devices to write the
> name and addresses like other interfaces.
>
> Changes in v2:
> - Add CONFIG_CHECKPOINT around the handler
>
> Signed-off-by: Dan Smith <danms@us.ibm.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 3/6] C/R: Add checkpoint support for veth devices (v2)
From: David Miller @ 2010-02-26 12:09 UTC (permalink / raw)
To: danms; +Cc: containers, benjamin.thery, den, ebiederm, netdev
In-Reply-To: <1267130595-23637-4-git-send-email-danms@us.ibm.com>
From: Dan Smith <danms@us.ibm.com>
Date: Thu, 25 Feb 2010 12:43:12 -0800
> Adds an ndo_checkpoint() handler for veth devices to checkpoint themselves.
> Writes out the pairing information, addresses, and initiates a checkpoint
> on the peer if the peer won't be reached from another netns. Throws an
> error of our peer's netns isn't already in the hash (i.e., a tree leak).
>
> Changes in v2:
> - Fix check detecting if peer is in the init netns
>
> Signed-off-by: Dan Smith <danms@us.ibm.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 2/6] C/R: Basic support for network namespaces and devices (v5)
From: David Miller @ 2010-02-26 12:08 UTC (permalink / raw)
To: danms; +Cc: containers, benjamin.thery, den, ebiederm, netdev
In-Reply-To: <1267130595-23637-3-git-send-email-danms@us.ibm.com>
From: Dan Smith <danms@us.ibm.com>
Date: Thu, 25 Feb 2010 12:43:11 -0800
> When checkpointing a task tree with network namespaces, we hook into
> do_checkpoint_ns() along with the others. Any devices in a given namespace
> are checkpointed (including their peer, in the case of veth) sequentially.
> Each network device stores a list of protocol addresses, as well as other
> information, such as hardware address.
>
> This patch supports veth pairs, as well as the loopback adapter. The
> loopback support is there to make sure that any additional addresses and
> state (such as up/down) is copied to the loopback adapter that we are
> given in the new network namespace.
>
> On restart, we instantiate new network namespaces and veth pairs as
> necessary. Any device we encounter that isn't in a network namespace
> that was checkpointed as part of a task is left in the namespace of the
> restarting process. This will be the case for a veth half that exists
> in the init netns to provide network access to a container.
To be safe you should probably use __be32 and store the IP
addresses in network byte order.
But other than that:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 1/6] C/R: Add checkpoint and collect hooks to net_device_ops
From: David Miller @ 2010-02-26 12:08 UTC (permalink / raw)
To: danms; +Cc: containers, benjamin.thery, den, ebiederm, netdev
In-Reply-To: <1267130595-23637-2-git-send-email-danms@us.ibm.com>
From: Dan Smith <danms@us.ibm.com>
Date: Thu, 25 Feb 2010 12:43:10 -0800
> These will be implemented per-driver by those that support such
> operations.
>
> Signed-off-by: Dan Smith <danms@us.ibm.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-26 12:06 UTC (permalink / raw)
To: avorontsov
Cc: Paul Gortmaker, linuxppc-dev list, netdev, linux-kernel,
Sandeep Gopalpet, davem, Kumar Gala
In-Reply-To: <20100226031452.GA11319@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
> [...]
>
>> I was able to reproduce it on an 8641D and bisected it down to this:
>>
>> -----------
>> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
>> Author: Anton Vorontsov <avorontsov@ru.mvista.com>
>> Date: Tue Nov 10 14:11:10 2009 +0000
>>
>> gianfar: Revive SKB recycling
>>
>
> Thanks for the bisect. I have a guess why tx hangs in
> SMP case. Could anyone try the patch down below?
>
Yup, no problem. I'm afraid it doesn't resolve the problem for me.
> [...]
>
>> ...which probably explains why you weren't seeing it on non-SMP.
>> I'd imagine it would show up on any of the e500mc boards too.
>>
>
> Yeah.. Pity, I don't have SMP boards anymore. I'll try
> to get one though.
>
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 8bd3c9f..3ff3bd0 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -2614,6 +2614,8 @@ static int gfar_poll(struct napi_struct *napi, int budget)
> tx_queue = priv->tx_queue[rx_queue->qindex];
>
> tx_cleaned += gfar_clean_tx_ring(tx_queue);
> + if (!tx_cleaned && !tx_queue->num_txbdfree)
> + tx_cleaned += 1; /* don't complete napi */
> rx_cleaned_per_queue = gfar_clean_rx_ring(rx_queue,
> budget_per_queue);
> rx_cleaned += rx_cleaned_per_queue;
>
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: [PATCH V2] net: add accounting for socket backlog
From: David Miller @ 2010-02-26 12:05 UTC (permalink / raw)
To: yi.zhu; +Cc: netdev, eric.dumazet
In-Reply-To: <1267176464-426-1-git-send-email-yi.zhu@intel.com>
From: Zhu Yi <yi.zhu@intel.com>
Date: Fri, 26 Feb 2010 17:27:44 +0800
> We got system OOM while running some UDP netperf testing on the loopback
> device. The case is multiple senders sent stream UDP packets to a single
> receiver via loopback on local host. Of course, the receiver is not able
> to handle all the packets in time. But we surprisingly found that these
> packets were not discarded due to the receiver's sk->sk_rcvbuf limit.
> Instead, they are kept queuing to sk->sk_backlog and finally ate up all
> the memory. We believe this is a secure hole that a none privileged user
> can crash the system.
>
> The root cause for this problem is, when the receiver is doing
> __release_sock() (i.e. after userspace recv, kernel udp_recvmsg ->
> skb_free_datagram_locked -> release_sock), it moves skbs from backlog to
> sk_receive_queue with the softirq enabled. In the above case, multiple
> busy senders will almost make it an endless loop. The skbs in the
> backlog end up eat all the system memory.
>
> The patch fixed this problem by adding accounting for the socket
> backlog. So that the backlog size can be restricted by protocol's choice
> (i.e. UDP).
>
> Reported-by: Alex Shi <alex.shi@intel.com>
> Cc: David Miller <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
So remind me why TCP, or any other non-UDP protocol, won't
intrinsically have this problem too?
It seems pretty trivial to do with any protocol, especially remotely,
with a packet generator. The code in TCP, for example, which queues
to the backlog, doesn't care about sequence numbers or anything like
that.
So you could spray a machine with the same TCP frame over and over
again, as fast as possible, as long as it matches the socket identity.
And in this way fill up the backlog endlessly and OOM the system.
^ permalink raw reply
* Re: [PATCH] ipv6: Remove IPV6_ADDR_RESERVED
From: David Miller @ 2010-02-26 11:59 UTC (permalink / raw)
To: uweber; +Cc: netdev
In-Reply-To: <20100226092858.GA5986@babylon>
From: Ulrich Weber <uweber@astaro.com>
Date: Fri, 26 Feb 2010 10:28:58 +0100
> RFC 4291 section 2.4 states that all uncategorized addresses
> should be considered as Global Unicast.
>
> This will remove IPV6_ADDR_RESERVED completely
> and return IPV6_ADDR_UNICAST in ipv6_addr_type() instead.
>
> Signed-off-by: Ulrich Weber <uweber@astaro.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: Use 1280 as min MTU for ipv6 forwarding
From: David Miller @ 2010-02-26 11:59 UTC (permalink / raw)
To: uweber; +Cc: netdev
In-Reply-To: <20100226092752.GA5969@babylon>
From: Ulrich Weber <uweber@astaro.com>
Date: Fri, 26 Feb 2010 10:27:52 +0100
> Clients will set their MTU to 1280 if they receive a
> ICMPV6_PKT_TOOBIG message with an MTU less than 1280.
>
> To allow encapsulating of packets over a 1280 link
> we should always accept packets with a size of 1280
> for forwarding even if the path has a lower MTU and
> fragment the encapsulated packets afterwards.
>
> In case a forwarded packet is not going to be encapsulated
> a ICMPV6_PKT_TOOBIG msg will still be send by ip6_fragment()
> with the correct MTU.
>
> Signed-off-by: Ulrich Weber <uweber@astaro.com>
Patch does not apply to net-next-2.6, icmpv6_send() no longer
takes the final 'dev' argument.
^ permalink raw reply
* [ethtool PATCH 2/2] ethtool: Update manpage with n-tuple information
From: Jeff Kirsher @ 2010-02-26 11:56 UTC (permalink / raw)
To: jeff; +Cc: netdev, gospo, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20100226115544.20259.36760.stgit@localhost.localdomain>
From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
Add n-tuple information to the ethtool manpage.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
ethtool.8 | 102 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 102 insertions(+), 0 deletions(-)
diff --git a/ethtool.8 b/ethtool.8
index b45d171..eb6430b 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -214,6 +214,40 @@ ethtool \- Display or change ethernet card settings
.I ethX
.RI FILE
.RI [ N ]
+
+.B ethtool \-u|\-\-show\-ntuple
+.I ethX
+
+.B ethtool \-U|\-\-config\-ntuple
+.I ethX
+.RB [ flow-type
+.RB tcp4|udp4|sctp4 ]
+.RB [ src-ip
+.IR addr ]
+.RB [ src-ip-mask
+.IR mask ]
+.RB [ dst-ip
+.IR addr ]
+.RB [ dst-ip-mask
+.IR mask ]
+.RB [ src-port
+.IR port ]
+.RB [ src-port-mask
+.IR mask ]
+.RB [ dst-port
+.IR port ]
+.RB [ dst-port-mask
+.IR mask ]
+.RB [ vlan
+.IR VLAN-tag ]
+.RB [ vlan-mask
+.IR mask ]
+.RB [ user-def
+.IR data ]
+.RB [ user-def-mask
+.IR mask ]
+.RB [ action
+.IR queue\ or\ drop ]
.SH DESCRIPTION
.BI ethtool
is used for querying settings of an ethernet device and changing them.
@@ -517,6 +551,74 @@ A number to identify flash region where the image should be flashed.
Default region is 0 which denotes all regions in the flash.
.PD
.RE
+.TP
+.B \-u \-\-show-ntuple
+Get Rx ntuple filters and actions, then display them to the user.
+.PD
+.RE
+.TP
+.B \-U \-\-config-ntuple
+Configure Rx ntuple filters and actions
+.TP
+.B flow-type tcp4|udp4|sctp4
+.RS
+.PD 0
+.TP 3
+.BR "tcp4" " TCP over IPv4"
+.TP 3
+.BR "udp4" " UDP over IPv4"
+.TP 3
+.BR "sctp4" " SCTP over IPv4"
+.PD
+.RE
+.TP
+.BI src-ip \ addr
+Includes the source IP address, specified in hex.
+.TP
+.BI src-ip-mask \ mask
+Specify a mask for the source IP address, specified in hex.
+.TP
+.BI dst-ip \ addr
+Includes the destination IP address, specified in hex.
+.TP
+.BI dst-ip-mask \ mask
+Specify a mask for the destination IP address, specified in hex.
+.TP
+.BI src-port \ port
+Includes the source port, specified in decimal.
+.TP
+.BI src-port-mask \ mask
+Specify a mask for the source port, specified in hex.
+.TP
+.BI dst-port \ port
+Includes the destination port, specified in decimal.
+.TP
+.BI dst-port-mask \ mask
+Specify a mask for the destination port, specified in hex.
+.TP
+.BI vlan \ VLAN-tag
+Includes the VLAN tag, specified in hex.
+.TP
+.BI vlan-mask \ mask
+Specify a mask for the VLAN tag, specified in hex.
+.TP
+.BI user-def \ data
+Includes 64-bits of user-specific data, specified in hex.
+.TP
+.BI user-def-mask \ mask
+Specify a mask for the user-specific data, specified in hex.
+.TP
+.BI action \ N
+Specifies either the Rx queue to send packets to, or to drop
+the matched flow.
+.RS
+.PD 0
+.TP 3
+.BR "-1" " Drop the matched flow"
+.TP 3
+.BR "0 or higher" " Rx queue to route the flow"
+.PD
+.RE
.SH BUGS
Not supported (in part or whole) on all ethernet drivers.
.SH AUTHOR
^ permalink raw reply related
* [ethtool PATCH 1/2] ethtool: Correctly pull n-tuple string length for get_rx_ntuple
From: Jeff Kirsher @ 2010-02-26 11:55 UTC (permalink / raw)
To: jeff; +Cc: netdev, gospo, Peter P Waskiewicz Jr, Jeff Kirsher
From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
This patch fixes inconsistencies with the kernel header files, while
correctly gets the variable length string counts for the get_rx_ntuple
return value.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
ethtool-copy.h | 3 +--
ethtool.c | 13 +++++++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 8681f5e..7d4e80a 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -63,6 +63,7 @@ struct ethtool_drvinfo {
char reserved2[12];
__u32 n_priv_flags; /* number of flags valid in ETHTOOL_GPFLAGS */
__u32 n_stats; /* number of u64's from ETHTOOL_GSTATS */
+ __u32 n_ntuples; /* number of n-tuple filters from GSTRINGS */
__u32 testinfo_len;
__u32 eedump_len; /* Size of data from ETHTOOL_GEEPROM (bytes) */
__u32 regdump_len; /* Size of data from ETHTOOL_GREGS (bytes) */
@@ -389,8 +390,6 @@ struct ethtool_rx_ntuple_flow_spec {
#define ETHTOOL_RXNTUPLE_ACTION_DROP -1
};
-#define ETHTOOL_MAX_NTUPLE_LIST_ENTRY 1024
-#define ETHTOOL_MAX_NTUPLE_STRING_PER_ENTRY 14
struct ethtool_rx_ntuple {
__u32 cmd;
struct ethtool_rx_ntuple_flow_spec fs;
diff --git a/ethtool.c b/ethtool.c
index fc9e419..4f39263 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -2657,11 +2657,20 @@ static int do_srxntuple(int fd, struct ifreq *ifr)
static int do_grxntuple(int fd, struct ifreq *ifr)
{
+ struct ethtool_drvinfo drvinfo;
struct ethtool_gstrings *strings;
int sz_str, n_strings, err, i;
- n_strings = ETHTOOL_MAX_NTUPLE_LIST_ENTRY *
- ETHTOOL_MAX_NTUPLE_STRING_PER_ENTRY;
+ drvinfo.cmd = ETHTOOL_GDRVINFO;
+ ifr->ifr_data = (caddr_t)&drvinfo;
+ err = send_ioctl(fd, ifr);
+
+ if (err < 0) {
+ perror("Cannot get driver information");
+ return 71;
+ }
+
+ n_strings = drvinfo.n_ntuples;
sz_str = n_strings * ETH_GSTRING_LEN;
strings = calloc(1, sz_str + sizeof(struct ethtool_gstrings));
^ permalink raw reply related
* [net-next-2.6 PATCH] ethtool: Add n-tuple string length to drvinfo and return it
From: Jeff Kirsher @ 2010-02-26 11:54 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Peter P Waskiewicz Jr, Jeff Kirsher
From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
The drvinfo struct should include the number of strings that
get_rx_ntuple will return. It will be variable if an underlying
driver implements its own get_rx_ntuple routine, so userspace
needs to know how much data is coming.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
include/linux/ethtool.h | 1 +
net/core/ethtool.c | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index cca1c3d..f7992a2 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -63,6 +63,7 @@ struct ethtool_drvinfo {
char reserved2[12];
__u32 n_priv_flags; /* number of flags valid in ETHTOOL_GPFLAGS */
__u32 n_stats; /* number of u64's from ETHTOOL_GSTATS */
+ __u32 n_ntuples; /* number of n-tuple filters from GSTRINGS */
__u32 testinfo_len;
__u32 eedump_len; /* Size of data from ETHTOOL_GEEPROM (bytes) */
__u32 regdump_len; /* Size of data from ETHTOOL_GREGS (bytes) */
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 31b1edd..1c94f48 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -224,6 +224,9 @@ static noinline int ethtool_get_drvinfo(struct net_device *dev, void __user *use
rc = ops->get_sset_count(dev, ETH_SS_PRIV_FLAGS);
if (rc >= 0)
info.n_priv_flags = rc;
+ rc = ops->get_sset_count(dev, ETH_SS_NTUPLE_FILTERS);
+ if (rc >= 0)
+ info.n_ntuples = rc;
}
if (ops->get_regs_len)
info.regdump_len = ops->get_regs_len(dev);
^ permalink raw reply related
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-26 11:51 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev list, netdev, linux-kernel, Sandeep Gopalpet, davem,
Kumar Gala
In-Reply-To: <20100225165141.GA9686@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Thu, Feb 25, 2010 at 04:46:54PM +0000, Martyn Welch wrote:
> [...]
>
>>> nfs: server 192.168.0.1 not responding, still trying
>>>
>>>
>> Further testing has shown that this isn't restricted to warm reboots, it
>> happens from cold as well. In addition, the exact timing of the failure
>> seems to vary, some boots have got further before failing.
>>
>
> Unfortunately I don't have any 8641 boards near me, so I can't
> debug this myself. Though, I tested gianfar on MPC8568E-MDS with
> 2.6.33 kernel, and it seems to work just fine.
>
> I see you use SMP. Can you try to turn it off? If that will fix
> the issue, then it'll be a good data point.
>
> Meanwhile, I'll try SMP kernel on MPC8568 (UP), and let you
> know the results.
>
> Thanks
I removed the second core from the dts file rather than truly disabling
SMP in the kernel config. Doing this allowed the board to boot reliably.
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: convert multiple drivers to use netdev_for_each_mc_addr, part5 V2
From: Jiri Pirko @ 2010-02-26 10:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100226.020333.13570565.davem@davemloft.net>
Fri, Feb 26, 2010 at 11:03:33AM CET, davem@davemloft.net wrote:
>
>100 EURO says you didn't compile test this.
>
>@@ -975,7 +968,7 @@ static void do_set_multicast_list(struct net_device *dev)
>
> if(dev->flags&IFF_PROMISC)
> ei_outb_p(E8390_RXCONFIG | 0x18, e8390_base + EN0_RXCR);
>- else if(dev->flags&IFF_ALLMULTI || dev->mc_list)
>+ else if (dev->flags & IFF_ALLMULTI || !netdev_mc_addr(dev))
> ei_outb_p(E8390_RXCONFIG | 0x08, e8390_base + EN0_RXCR);
> else
> ei_outb_p(E8390_RXCONFIG, e8390_base + EN0_RXCR);
>
>I'll fix it up, but you have to start getting proper build
>coverage of your patches!
>
>I really don't care how slow your netbook is, this case could have
>been easily prevented.
I'm really sorry, I do compile test all my patches, but I must have missed this
:(
I promise I'll reserve 2xtime next time. You'll have a beer on me :)
Jirka
^ permalink raw reply
* Re: [PATCH net-next 6/6] cnic: Update version to 2.1.1.
From: David Miller @ 2010-02-26 10:11 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1267058529-18454-6-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 24 Feb 2010 16:42:09 -0800
> And update copyright to 2010.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 5/6] cnic: Use union for the status blocks of different devices.
From: David Miller @ 2010-02-26 10:11 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1267058529-18454-5-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 24 Feb 2010 16:42:08 -0800
> We only need to assign the status block address once and it also saves
> space in the structure.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Benjamin Li <benli@broadcom.com>
> Signed-off-by: Eddie Wai <waie@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 4/6] cnic: Simplify route checking during iSCSI connection.
From: David Miller @ 2010-02-26 10:11 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1267058529-18454-4-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 24 Feb 2010 16:42:07 -0800
> With a separate IP address for iSCSI, connections should proceed
> whether or not we can get a route to the target from the network stack.
> It is possible that the network IP address may not reach the iSCSI target.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Benjamin Li <benli@broadcom.com>
> Signed-off-by: Eddie Wai <waie@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/6] cnic: Fix panic in cnic_iscsi_nl_msg_recv() when device is down.
From: David Miller @ 2010-02-26 10:11 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1267058529-18454-3-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 24 Feb 2010 16:42:06 -0800
> Some data structures are freed when the device is down and it will
> crash if an ISCSI netlink message is received. Add RCU protection
> to prevent this. In the shutdown path, ulp_ops[CNIC_ULP_L4] is
> assigned NULL and rcu_synchronized before freeing the data
> structures.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/6] cnic: Finetune iSCSI connection reset.
From: David Miller @ 2010-02-26 10:11 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1267058529-18454-2-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 24 Feb 2010 16:42:05 -0800
> From: Eddie Wai <waie@broadcom.com>
>
> For bnx2 devices, always send notification to bnx2i to let it initiate
> the cleanup when RST is received.
>
> For bnx2x devices, add unsolicited RST_COMP handling to start the cleanup.
>
> Signed-off-by: Eddie Wai <waie@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Benjamin Li <benli@broadcom.com>
Applied.
^ 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