* Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
From: Roopa Prabhu @ 2014-12-16 19:30 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: John Fastabend, Jamal Hadi Salim, Hubert Sokolowski,
netdev@vger.kernel.org, Vlad Yasevich
In-Reply-To: <54906A11.6030701@intel.com>
On 12/16/14, 9:21 AM, Samudrala, Sridhar wrote:
>
> On 12/16/2014 8:35 AM, John Fastabend wrote:
>>
>>> Is there no way to get the unicast/multicast mac addresses for such
>>> a driver?
>>
>> You can almost infer it from ip link by looking at all the stacked
>> drivers and figuring out how the address are propagated down. Then
>> look at the routes and figure out multicast address. But other than
>> the fdb dump mechanism I don't think there is anything.
>
> It looks like we can get the device specific unicast/multicast mac
> addresses via 'ip maddr' too.
if i remember correctly, 'ip maddr' was only for multicast list. And
there was no way to dump the unicast list until bridge self was introduced.
the only way to dump unicast addresses today is by using the `bridge fdb
show self`
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Michael Chan @ 2014-12-16 19:54 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Bjorn Helgaas, Rajat Jain, Nils Holland, David Miller, netdev,
linux-pci@vger.kernel.org, Rafael Wysocki, Prashant Sreedharan
In-Reply-To: <54907300.9050902@gmail.com>
On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
> It's a
> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
> Gigabit Ethernet PCI Express
> over here
>
> I put a WARN_ON(1) after those printks, and this is what I got:
>
> [ 1.550640] pci 0000:02:00.0: 1st 1 1
> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
> [ 1.550645] ------------[ cut here ]------------
> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
> [ 1.550669] Call Trace:
> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
So does it work if you use a non-zero crs_timeout? The driver has
called tg3_halt() which may affect configuration read responses. I need
to check with the hardware team to see if the 5722 will return CRS in
this scenario.
^ permalink raw reply
* Re: [PATCH net-next 2/3] Implementation of RFC 4898 Extended TCP Statistics (Web10G)
From: rapier @ 2014-12-16 20:01 UTC (permalink / raw)
To: David Miller, alexei.starovoitov; +Cc: netdev
In-Reply-To: <20141216.140919.44020047339373813.davem@davemloft.net>
On 12/16/14, 2:09 PM, David Miller wrote:
> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Date: Tue, 16 Dec 2014 10:24:31 -0800
>
>> imo that is very questionable design choice.
>> export a lot of in-kernel bits to be used by out-of-tree kernel module?
>
> It's a non-starter.
Understood. We're in the process of reviewing which symbols are required
by the DLKM we've provided and which are required by in tree modules
(e.g tcp_estats_enabled is required by tcp_htcp). In the meantime, I do
want to stress that the KIS is distinct from the control and management
functions in this patch. We'd like to make sure that problems with this
patch aren't negating the value of the instrument set.
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Marcelo Ricardo Leitner @ 2014-12-16 20:02 UTC (permalink / raw)
To: Michael Chan
Cc: Bjorn Helgaas, Rajat Jain, Nils Holland, David Miller, netdev,
linux-pci@vger.kernel.org, Rafael Wysocki, Prashant Sreedharan
In-Reply-To: <1418759684.4248.12.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
On 16-12-2014 17:54, Michael Chan wrote:
> On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
>> It's a
>> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
>> Gigabit Ethernet PCI Express
>> over here
>>
>> I put a WARN_ON(1) after those printks, and this is what I got:
>>
>> [ 1.550640] pci 0000:02:00.0: 1st 1 1
>> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
>> [ 1.550645] ------------[ cut here ]------------
>> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
>> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
>> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
>> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
>> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
>> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
>> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
>> [ 1.550669] Call Trace:
>> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
>> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
>> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
>> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
>> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
>> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
>> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
>> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
>
> So does it work if you use a non-zero crs_timeout? The driver has
> called tg3_halt() which may affect configuration read responses. I need
> to check with the hardware team to see if the 5722 will return CRS in
> this scenario.
Sorry, I replied to the thread that you weren't in yet.
It didn't..
http://thread.gmane.org/gmane.linux.network/342566/focus=37932
Marcelo
^ permalink raw reply
* Re: [PATCH net-next 2/3] Implementation of RFC 4898 Extended TCP Statistics (Web10G)
From: David Miller @ 2014-12-16 20:03 UTC (permalink / raw)
To: rapier; +Cc: alexei.starovoitov, netdev
In-Reply-To: <54908FAD.5060500@psc.edu>
From: rapier <rapier@psc.edu>
Date: Tue, 16 Dec 2014 15:01:49 -0500
> On 12/16/14, 2:09 PM, David Miller wrote:
>> It's a non-starter.
>
> Understood. We're in the process of reviewing which symbols are
> required by the DLKM we've provided and which are required by in tree
> modules (e.g tcp_estats_enabled is required by tcp_htcp).
You shouldn't need to export any symbols.
^ permalink raw reply
* [PATCH 2/2] ip_tunnel: Add missing validation of encap type to ip_tunnel_encap_setup()
From: Thomas Graf @ 2014-12-16 20:05 UTC (permalink / raw)
To: davem; +Cc: netdev, therbert
In-Reply-To: <cover.1418759998.git.tgraf@suug.ch>
The encap->type comes straight from Netlink. Validate it against
max supported encap types just like ip_encap_hlen() already does.
Fixes: a8c5f9 ("ip_tunnel: Ops registration for secondary encap (fou, gue)")
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
net/ipv4/ip_tunnel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 2f498f8..d3e4479 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -573,6 +573,9 @@ int ip_tunnel_encap(struct sk_buff *skb, struct ip_tunnel *t,
if (t->encap.type == TUNNEL_ENCAP_NONE)
return 0;
+ if (t->encap.type >= MAX_IPTUN_ENCAP_OPS)
+ return -EINVAL;
+
rcu_read_lock();
ops = rcu_dereference(iptun_encaps[t->encap.type]);
if (likely(ops && ops->build_header))
--
1.9.3
^ permalink raw reply related
* [PATCH 1/2] ip_tunnel: Add sanity checks to ip_tunnel_encap_add_ops()
From: Thomas Graf @ 2014-12-16 20:05 UTC (permalink / raw)
To: davem; +Cc: netdev, therbert
In-Reply-To: <cover.1418759998.git.tgraf@suug.ch>
The symbols are exported and could be used by external modules.
Fixes: a8c5f9 ("ip_tunnel: Ops registration for secondary encap (fou, gue)")
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
net/ipv4/ip_tunnel.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 63e745a..2f498f8 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -514,6 +514,9 @@ const struct ip_tunnel_encap_ops __rcu *
int ip_tunnel_encap_add_ops(const struct ip_tunnel_encap_ops *ops,
unsigned int num)
{
+ if (num >= MAX_IPTUN_ENCAP_OPS)
+ return -ERANGE;
+
return !cmpxchg((const struct ip_tunnel_encap_ops **)
&iptun_encaps[num],
NULL, ops) ? 0 : -1;
@@ -525,6 +528,9 @@ int ip_tunnel_encap_del_ops(const struct ip_tunnel_encap_ops *ops,
{
int ret;
+ if (num >= MAX_IPTUN_ENCAP_OPS)
+ return -ERANGE;
+
ret = (cmpxchg((const struct ip_tunnel_encap_ops **)
&iptun_encaps[num],
ops, NULL) == ops) ? 0 : -1;
--
1.9.3
^ permalink raw reply related
* [PATCH 0/2] ip_tunnel fixes
From: Thomas Graf @ 2014-12-16 20:05 UTC (permalink / raw)
To: davem; +Cc: netdev, therbert
Thomas Graf (2):
ip_tunnel: Add sanity checks to ip_tunnel_encap_add_ops()
ip_tunnel: Add missing validation of encap type to
ip_tunnel_encap_setup()
net/ipv4/ip_tunnel.c | 9 +++++++++
1 file changed, 9 insertions(+)
--
1.9.3
^ permalink raw reply
* Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
From: Samudrala, Sridhar @ 2014-12-16 20:11 UTC (permalink / raw)
To: Roopa Prabhu
Cc: John Fastabend, Jamal Hadi Salim, Hubert Sokolowski,
netdev@vger.kernel.org, Vlad Yasevich
In-Reply-To: <54908856.1070708@cumulusnetworks.com>
On 12/16/2014 11:30 AM, Roopa Prabhu wrote:
> On 12/16/14, 9:21 AM, Samudrala, Sridhar wrote:
>>
>> On 12/16/2014 8:35 AM, John Fastabend wrote:
>>>
>>>> Is there no way to get the unicast/multicast mac addresses for such
>>>> a driver?
>>>
>>> You can almost infer it from ip link by looking at all the stacked
>>> drivers and figuring out how the address are propagated down. Then
>>> look at the routes and figure out multicast address. But other than
>>> the fdb dump mechanism I don't think there is anything.
>>
>> It looks like we can get the device specific unicast/multicast mac
>> addresses via 'ip maddr' too.
> if i remember correctly, 'ip maddr' was only for multicast list. And
> there was no way to dump the unicast list until bridge self was
> introduced.
> the only way to dump unicast addresses today is by using the `bridge
> fdb show self`
Yes. 'ip maddr show' only lists the multicast macs as the name suggests.
I stand corrected.
May be we need 'ip uaddr show' to list unicast macs instead of
overloading 'bridge fdb show' to show unicast lists.
Thanks
Sridhar
^ permalink raw reply
* Re: [PATCH net-next 2/3] Implementation of RFC 4898 Extended TCP Statistics (Web10G)
From: rapier @ 2014-12-16 20:13 UTC (permalink / raw)
To: David Miller; +Cc: alexei.starovoitov, netdev
In-Reply-To: <20141216.150354.64901094367530710.davem@davemloft.net>
On 12/16/14, 3:03 PM, David Miller wrote:
> You shouldn't need to export any symbols.
As a point of clarification - is it acceptable to export symbols for use
with in tree modules such as tcp_htcp? We are more than willing to do
the work required to bring this in line with best practices.
^ permalink raw reply
* Re: FIXED_PHY is broken...
From: David Miller @ 2014-12-16 20:15 UTC (permalink / raw)
To: netdev; +Cc: f.fainelli
In-Reply-To: <20141216.143027.1243798311589198629.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 16 Dec 2014 14:30:27 -0500 (EST)
> From: David Miller <davem@davemloft.net>
> Date: Tue, 16 Dec 2014 11:25:34 -0500 (EST)
>
>> I get this now when I run oldconfig:
>>
>> warning: (NET_DSA_BCM_SF2 && BCMGENET && SYSTEMPORT) selects FIXED_PHY which has unmet direct dependencies (NETDEVICES && PHYLIB=y)
>
> Here is how I'm going to fix this.
>
> FIXED_PHY needs to be allowed to be modular, and built even if PHYLIB is
> modular too.
>
> ====================
> [PATCH] net: Allow FIXED_PHY to be modular.
Ok, it takes a little more work, the problem is that there is already
a module named fixed.ko in the regulator layer, so we have to rename
this to something else.
====================
[PATCH] net: Allow FIXED_PHY to be modular.
Otherwise we get things like:
warning: (NET_DSA_BCM_SF2 && BCMGENET && SYSTEMPORT) selects FIXED_PHY which has unmet direct dependencies (NETDEVICES && PHYLIB=y)
In order to make this work we have to rename fixed.c to fixed_phy.c
because the regulator drivers already have a module named "fixed.o".
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/phy/Kconfig | 4 ++--
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/{fixed.c => fixed_phy.c} | 0
include/linux/phy_fixed.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
rename drivers/net/phy/{fixed.c => fixed_phy.c} (100%)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index b4b0f80..a3c251b 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -119,8 +119,8 @@ config MICREL_PHY
Supports the KSZ9021, VSC8201, KS8001 PHYs.
config FIXED_PHY
- bool "Driver for MDIO Bus/PHY emulation with fixed speed/link PHYs"
- depends on PHYLIB=y
+ tristate "Driver for MDIO Bus/PHY emulation with fixed speed/link PHYs"
+ depends on PHYLIB
---help---
Adds the platform "fixed" MDIO Bus to cover the boards that use
PHYs that are not connected to the real MDIO bus.
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index eb3b18b..501ea76 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_BCM87XX_PHY) += bcm87xx.o
obj-$(CONFIG_ICPLUS_PHY) += icplus.o
obj-$(CONFIG_REALTEK_PHY) += realtek.o
obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
-obj-$(CONFIG_FIXED_PHY) += fixed.o
+obj-$(CONFIG_FIXED_PHY) += fixed_phy.o
obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
obj-$(CONFIG_NATIONAL_PHY) += national.o
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed_phy.c
similarity index 100%
rename from drivers/net/phy/fixed.c
rename to drivers/net/phy/fixed_phy.c
diff --git a/include/linux/phy_fixed.h b/include/linux/phy_fixed.h
index f2ca1b4..7e75bfe 100644
--- a/include/linux/phy_fixed.h
+++ b/include/linux/phy_fixed.h
@@ -11,7 +11,7 @@ struct fixed_phy_status {
struct device_node;
-#ifdef CONFIG_FIXED_PHY
+#if IS_ENABLED(CONFIG_FIXED_PHY)
extern int fixed_phy_add(unsigned int irq, int phy_id,
struct fixed_phy_status *status);
extern struct phy_device *fixed_phy_register(unsigned int irq,
--
1.7.11.7
^ permalink raw reply related
* Re: pull request: wireless 2014-12-16
From: David Miller @ 2014-12-16 20:17 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20141216181613.GF19658@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 16 Dec 2014 13:16:13 -0500
> Please pull this batch of fixes intended for the 3.19 stream!
Pulled, thanks a lot John.
^ permalink raw reply
* [PATCH netfilter-next] xt_osf: Use continue to reduce indentation
From: Joe Perches @ 2014-12-16 20:17 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
netfilter-devel, netdev, LKML
Invert logic in test to use continue.
This routine already uses continue, use it a bit more to
minimize > 80 column long lines and unnecessary indentation.
No change in compiled object file.
Other miscellanea:
o Remove trailing whitespace
o Realign arguments to multiline statement
Signed-off-by: Joe Perches <joe@perches.com>
---
net/netfilter/xt_osf.c | 169 +++++++++++++++++++++++++------------------------
1 file changed, 85 insertions(+), 84 deletions(-)
diff --git a/net/netfilter/xt_osf.c b/net/netfilter/xt_osf.c
index c529161..0778855 100644
--- a/net/netfilter/xt_osf.c
+++ b/net/netfilter/xt_osf.c
@@ -225,6 +225,8 @@ xt_osf_match_packet(const struct sk_buff *skb, struct xt_action_param *p)
rcu_read_lock();
list_for_each_entry_rcu(kf, &xt_osf_fingers[df], finger_entry) {
+ int foptsize, optnum;
+
f = &kf->finger;
if (!(info->flags & XT_OSF_LOG) && strcmp(info->genre, f->genre))
@@ -233,110 +235,109 @@ xt_osf_match_packet(const struct sk_buff *skb, struct xt_action_param *p)
optp = _optp;
fmatch = FMATCH_WRONG;
- if (totlen == f->ss && xt_osf_ttl(skb, info, f->ttl)) {
- int foptsize, optnum;
+ if (totlen != f->ss || !xt_osf_ttl(skb, info, f->ttl))
+ continue;
- /*
- * Should not happen if userspace parser was written correctly.
- */
- if (f->wss.wc >= OSF_WSS_MAX)
- continue;
+ /*
+ * Should not happen if userspace parser was written correctly.
+ */
+ if (f->wss.wc >= OSF_WSS_MAX)
+ continue;
- /* Check options */
+ /* Check options */
- foptsize = 0;
- for (optnum = 0; optnum < f->opt_num; ++optnum)
- foptsize += f->opt[optnum].length;
+ foptsize = 0;
+ for (optnum = 0; optnum < f->opt_num; ++optnum)
+ foptsize += f->opt[optnum].length;
- if (foptsize > MAX_IPOPTLEN ||
- optsize > MAX_IPOPTLEN ||
- optsize != foptsize)
- continue;
+ if (foptsize > MAX_IPOPTLEN ||
+ optsize > MAX_IPOPTLEN ||
+ optsize != foptsize)
+ continue;
- check_WSS = f->wss.wc;
+ check_WSS = f->wss.wc;
- for (optnum = 0; optnum < f->opt_num; ++optnum) {
- if (f->opt[optnum].kind == (*optp)) {
- __u32 len = f->opt[optnum].length;
- const __u8 *optend = optp + len;
- int loop_cont = 0;
+ for (optnum = 0; optnum < f->opt_num; ++optnum) {
+ if (f->opt[optnum].kind == (*optp)) {
+ __u32 len = f->opt[optnum].length;
+ const __u8 *optend = optp + len;
+ int loop_cont = 0;
- fmatch = FMATCH_OK;
+ fmatch = FMATCH_OK;
- switch (*optp) {
- case OSFOPT_MSS:
- mss = optp[3];
- mss <<= 8;
- mss |= optp[2];
+ switch (*optp) {
+ case OSFOPT_MSS:
+ mss = optp[3];
+ mss <<= 8;
+ mss |= optp[2];
- mss = ntohs((__force __be16)mss);
- break;
- case OSFOPT_TS:
- loop_cont = 1;
- break;
- }
+ mss = ntohs((__force __be16)mss);
+ break;
+ case OSFOPT_TS:
+ loop_cont = 1;
+ break;
+ }
- optp = optend;
- } else
- fmatch = FMATCH_OPT_WRONG;
+ optp = optend;
+ } else
+ fmatch = FMATCH_OPT_WRONG;
- if (fmatch != FMATCH_OK)
- break;
- }
+ if (fmatch != FMATCH_OK)
+ break;
+ }
- if (fmatch != FMATCH_OPT_WRONG) {
- fmatch = FMATCH_WRONG;
+ if (fmatch != FMATCH_OPT_WRONG) {
+ fmatch = FMATCH_WRONG;
- switch (check_WSS) {
- case OSF_WSS_PLAIN:
- if (f->wss.val == 0 || window == f->wss.val)
- fmatch = FMATCH_OK;
- break;
- case OSF_WSS_MSS:
- /*
- * Some smart modems decrease mangle MSS to
- * SMART_MSS_2, so we check standard, decreased
- * and the one provided in the fingerprint MSS
- * values.
- */
+ switch (check_WSS) {
+ case OSF_WSS_PLAIN:
+ if (f->wss.val == 0 || window == f->wss.val)
+ fmatch = FMATCH_OK;
+ break;
+ case OSF_WSS_MSS:
+ /*
+ * Some smart modems decrease mangle MSS to
+ * SMART_MSS_2, so we check standard, decreased
+ * and the one provided in the fingerprint MSS
+ * values.
+ */
#define SMART_MSS_1 1460
#define SMART_MSS_2 1448
- if (window == f->wss.val * mss ||
- window == f->wss.val * SMART_MSS_1 ||
- window == f->wss.val * SMART_MSS_2)
- fmatch = FMATCH_OK;
- break;
- case OSF_WSS_MTU:
- if (window == f->wss.val * (mss + 40) ||
- window == f->wss.val * (SMART_MSS_1 + 40) ||
- window == f->wss.val * (SMART_MSS_2 + 40))
- fmatch = FMATCH_OK;
- break;
- case OSF_WSS_MODULO:
- if ((window % f->wss.val) == 0)
- fmatch = FMATCH_OK;
- break;
- }
+ if (window == f->wss.val * mss ||
+ window == f->wss.val * SMART_MSS_1 ||
+ window == f->wss.val * SMART_MSS_2)
+ fmatch = FMATCH_OK;
+ break;
+ case OSF_WSS_MTU:
+ if (window == f->wss.val * (mss + 40) ||
+ window == f->wss.val * (SMART_MSS_1 + 40) ||
+ window == f->wss.val * (SMART_MSS_2 + 40))
+ fmatch = FMATCH_OK;
+ break;
+ case OSF_WSS_MODULO:
+ if ((window % f->wss.val) == 0)
+ fmatch = FMATCH_OK;
+ break;
}
+ }
- if (fmatch != FMATCH_OK)
- continue;
+ if (fmatch != FMATCH_OK)
+ continue;
- fcount++;
+ fcount++;
- if (info->flags & XT_OSF_LOG)
- nf_log_packet(net, p->family, p->hooknum, skb,
- p->in, p->out, NULL,
- "%s [%s:%s] : %pI4:%d -> %pI4:%d hops=%d\n",
- f->genre, f->version, f->subtype,
- &ip->saddr, ntohs(tcp->source),
- &ip->daddr, ntohs(tcp->dest),
- f->ttl - ip->ttl);
+ if (info->flags & XT_OSF_LOG)
+ nf_log_packet(net, p->family, p->hooknum, skb,
+ p->in, p->out, NULL,
+ "%s [%s:%s] : %pI4:%d -> %pI4:%d hops=%d\n",
+ f->genre, f->version, f->subtype,
+ &ip->saddr, ntohs(tcp->source),
+ &ip->daddr, ntohs(tcp->dest),
+ f->ttl - ip->ttl);
- if ((info->flags & XT_OSF_LOG) &&
- info->loglevel == XT_OSF_LOGLEVEL_FIRST)
- break;
- }
+ if ((info->flags & XT_OSF_LOG) &&
+ info->loglevel == XT_OSF_LOGLEVEL_FIRST)
+ break;
}
rcu_read_unlock();
^ permalink raw reply related
* Re: [PATCH net-next 2/3] Implementation of RFC 4898 Extended TCP Statistics (Web10G)
From: David Miller @ 2014-12-16 20:18 UTC (permalink / raw)
To: rapier; +Cc: alexei.starovoitov, netdev
In-Reply-To: <54909278.6090806@psc.edu>
From: rapier <rapier@psc.edu>
Date: Tue, 16 Dec 2014 15:13:44 -0500
> On 12/16/14, 3:03 PM, David Miller wrote:
>
>> You shouldn't need to export any symbols.
>
> As a point of clarification - is it acceptable to export symbols for
> use with in tree modules such as tcp_htcp? We are more than willing to
> do the work required to bring this in line with best practices.
I'm saying for data and TCP statistics collection, you shouldn't need
to add any new symbol exports.
Keep this in the main kernel, nothing external should be needed.
Extending tcp_info or similar is the only reasonable way to implement
this stuff.
^ permalink raw reply
* Re: [PATCH 0/2] ip_tunnel fixes
From: David Miller @ 2014-12-16 20:22 UTC (permalink / raw)
To: tgraf; +Cc: netdev, therbert
In-Reply-To: <cover.1418759998.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Tue, 16 Dec 2014 21:05:19 +0100
> Thomas Graf (2):
> ip_tunnel: Add sanity checks to ip_tunnel_encap_add_ops()
> ip_tunnel: Add missing validation of encap type to
> ip_tunnel_encap_setup()
Both applied, thanks Thomas.
^ permalink raw reply
* Re: [PATCHv1 net] xen-netfront: use napi_complete() correctly to prevent Rx stalling
From: David Miller @ 2014-12-16 20:22 UTC (permalink / raw)
To: david.vrabel; +Cc: netdev, xen-devel, konrad.wilk, boris.ostrovsky, edumazet
In-Reply-To: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
From: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 16 Dec 2014 18:59:46 +0000
> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
> masking in NAPI) the napi instance is removed from the per-cpu list
> prior to calling the n->poll(), and is only requeued if all of the
> budget was used. This inadvertently broke netfront because netfront
> does not use NAPI correctly.
>
> If netfront had not used all of its budget it would do a final check
> for any Rx responses and avoid calling napi_complete() if there were
> more responses. It would still return under budget so it would never
> be rescheduled. The final check would also not re-enable the Rx
> interrupt.
>
> Additionally, xenvif_poll() would also call napi_complete() /after/
> enabling the interrupt. This resulted in a race between the
> napi_complete() and the napi_schedule() in the interrupt handler. The
> use of local_irq_save/restore() avoided by race iff the handler is
> running on the same CPU but not if it was running on a different CPU.
>
> Fix both of these by always calling napi_compete() if the budget was
> not all used, and then calling napi_schedule() if the final checks
> says there's more work.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] ip_tunnel: Add missing validation of encap type to ip_tunnel_encap_setup()
From: Tom Herbert @ 2014-12-16 20:23 UTC (permalink / raw)
To: Thomas Graf; +Cc: David Miller, Linux Netdev List
In-Reply-To: <dd70de766b1111fdcb4794f6d671e4eca5053730.1418759998.git.tgraf@suug.ch>
On Tue, Dec 16, 2014 at 12:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
> The encap->type comes straight from Netlink. Validate it against
> max supported encap types just like ip_encap_hlen() already does.
>
> Fixes: a8c5f9 ("ip_tunnel: Ops registration for secondary encap (fou, gue)")
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> ---
> net/ipv4/ip_tunnel.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index 2f498f8..d3e4479 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -573,6 +573,9 @@ int ip_tunnel_encap(struct sk_buff *skb, struct ip_tunnel *t,
> if (t->encap.type == TUNNEL_ENCAP_NONE)
> return 0;
>
> + if (t->encap.type >= MAX_IPTUN_ENCAP_OPS)
> + return -EINVAL;
> +
I don't think this is technically needed, we should have already
verified the type when setting up the tunnel (ip_encap_hlen).
> rcu_read_lock();
> ops = rcu_dereference(iptun_encaps[t->encap.type]);
> if (likely(ops && ops->build_header))
> --
> 1.9.3
>
^ permalink raw reply
* Re: FIXED_PHY is broken...
From: Florian Fainelli @ 2014-12-16 20:23 UTC (permalink / raw)
To: David Miller, netdev
In-Reply-To: <20141216.151550.805808430085367492.davem@davemloft.net>
On 16/12/14 12:15, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 16 Dec 2014 14:30:27 -0500 (EST)
>
>> From: David Miller <davem@davemloft.net>
>> Date: Tue, 16 Dec 2014 11:25:34 -0500 (EST)
>>
>>> I get this now when I run oldconfig:
>>>
>>> warning: (NET_DSA_BCM_SF2 && BCMGENET && SYSTEMPORT) selects FIXED_PHY which has unmet direct dependencies (NETDEVICES && PHYLIB=y)
>>
>> Here is how I'm going to fix this.
>>
>> FIXED_PHY needs to be allowed to be modular, and built even if PHYLIB is
>> modular too.
You beat me to it, thanks David!
>>
>> ====================
>> [PATCH] net: Allow FIXED_PHY to be modular.
>
> Ok, it takes a little more work, the problem is that there is already
> a module named fixed.ko in the regulator layer, so we have to rename
> this to something else.
>
> ====================
> [PATCH] net: Allow FIXED_PHY to be modular.
>
> Otherwise we get things like:
>
> warning: (NET_DSA_BCM_SF2 && BCMGENET && SYSTEMPORT) selects FIXED_PHY which has unmet direct dependencies (NETDEVICES && PHYLIB=y)
>
> In order to make this work we have to rename fixed.c to fixed_phy.c
> because the regulator drivers already have a module named "fixed.o".
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/phy/Kconfig | 4 ++--
> drivers/net/phy/Makefile | 2 +-
> drivers/net/phy/{fixed.c => fixed_phy.c} | 0
> include/linux/phy_fixed.h | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
> rename drivers/net/phy/{fixed.c => fixed_phy.c} (100%)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index b4b0f80..a3c251b 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -119,8 +119,8 @@ config MICREL_PHY
> Supports the KSZ9021, VSC8201, KS8001 PHYs.
>
> config FIXED_PHY
> - bool "Driver for MDIO Bus/PHY emulation with fixed speed/link PHYs"
> - depends on PHYLIB=y
> + tristate "Driver for MDIO Bus/PHY emulation with fixed speed/link PHYs"
> + depends on PHYLIB
> ---help---
> Adds the platform "fixed" MDIO Bus to cover the boards that use
> PHYs that are not connected to the real MDIO bus.
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index eb3b18b..501ea76 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -17,7 +17,7 @@ obj-$(CONFIG_BCM87XX_PHY) += bcm87xx.o
> obj-$(CONFIG_ICPLUS_PHY) += icplus.o
> obj-$(CONFIG_REALTEK_PHY) += realtek.o
> obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
> -obj-$(CONFIG_FIXED_PHY) += fixed.o
> +obj-$(CONFIG_FIXED_PHY) += fixed_phy.o
> obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
> obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
> obj-$(CONFIG_NATIONAL_PHY) += national.o
> diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed_phy.c
> similarity index 100%
> rename from drivers/net/phy/fixed.c
> rename to drivers/net/phy/fixed_phy.c
> diff --git a/include/linux/phy_fixed.h b/include/linux/phy_fixed.h
> index f2ca1b4..7e75bfe 100644
> --- a/include/linux/phy_fixed.h
> +++ b/include/linux/phy_fixed.h
> @@ -11,7 +11,7 @@ struct fixed_phy_status {
>
> struct device_node;
>
> -#ifdef CONFIG_FIXED_PHY
> +#if IS_ENABLED(CONFIG_FIXED_PHY)
> extern int fixed_phy_add(unsigned int irq, int phy_id,
> struct fixed_phy_status *status);
> extern struct phy_device *fixed_phy_register(unsigned int irq,
>
^ permalink raw reply
* Re: [PATCH net] net/mlx4: Cache line CQE/EQE stride fixes
From: David Miller @ 2014-12-16 20:24 UTC (permalink / raw)
To: amirv; +Cc: netdev, yevgenyp, ogerlitz, clsoto, idos, weiyang
In-Reply-To: <54902597.50105@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Tue, 16 Dec 2014 14:29:11 +0200
> On 12/16/2014 1:28 PM, Amir Vadai wrote:
>> From: Ido Shamay <idos@mellanox.com>
>>
>> This commit contains 2 fixes for the 128B CQE/EQE stride feaure.
>> Wei found that mlx4_QUERY_HCA function marked the wrong capability
>> in flags (64B CQE/EQE), when CQE/EQE stride feature was enabled.
>> Also added small fix in initial CQE ownership bit assignment, when CQE
>> is size is not default 32B.
>>
>> Fixes: 77507aa24 (net/mlx4: Enable CQE/EQE stride support)
>> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>> Signed-off-by: Ido Shamay <idos@mellanox.com>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
>> ---
>> Dave Hi,
>>
>> Please pull this patch also to stable (at least 3.17)
>>
>> Thanks,
>> Amir
>
> Small correction: Should pull into -stable >= 3.18
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/1] net: fec: Fix NAPI race
From: David Miller @ 2014-12-16 20:24 UTC (permalink / raw)
To: b38611; +Cc: netdev, R49496, bhutchings, stephen
In-Reply-To: <1418725558-17287-1-git-send-email-b38611@freescale.com>
From: Fugang Duan <b38611@freescale.com>
Date: Tue, 16 Dec 2014 18:25:58 +0800
> Do camera capture test on i.MX6q sabresd board, and save the capture data to
> nfs rootfs. The command is:
> gst-launch-1.0 -e imxv4l2src device=/dev/video1 num-buffers=2592000 ! tee name=t !
> queue ! imxv4l2sink sync=false t. ! queue ! vpuenc ! queue ! mux. pulsesrc num-buffers=3720937
> blocksize=4096 ! 'audio/x-raw, rate=44100, channels=2' ! queue ! imxmp3enc ! mpegaudioparse !
> queue ! mux. qtmux name=mux ! filesink location=video_recording_long.mov
>
> After about 10 hours running, there have net watchdog timeout kernel dump:
...
> There might have a race in napi_schedule(), leaving interrupts disabled forever.
> After these patch, the case still work more than 40 hours running.
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH_V2] dm9000: Add regulator and reset support to dm9000
From: David Miller @ 2014-12-16 20:25 UTC (permalink / raw)
To: Zubair.Kakakhel; +Cc: devicetree, linux-kernel, netdev, paul.burton
In-Reply-To: <1418748391-9955-1-git-send-email-Zubair.Kakakhel@imgtec.com>
From: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Date: Tue, 16 Dec 2014 16:46:31 +0000
> In boards, the dm9000 chip's power and reset can be controlled by gpio.
>
> It makes sense to add them to the dm9000 driver and let dt be used to
> enable power and reset the phy.
>
> Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
> Signed-off-by: Paul Burton <paul.burton@imgtec.com>
This looks like a new feature to me, and therefore only appropriate
for net-next, which is closed right now.
Please resubmit this when the net-next tree opens back up.
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Nils Holland @ 2014-12-16 20:38 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: rajatxjain, David Miller, netdev, linux-pci@vger.kernel.org
In-Reply-To: <54907324.4040102@gmail.com>
On Tue, Dec 16, 2014 at 04:00:04PM -0200, Marcelo Ricardo Leitner wrote:
> On 16-12-2014 14:04, Rajat Jain wrote:
> > Hello All,
> >
> > Apologies for jumping in late, but for some reason I do not see the
> > original mail in my inbox. However I am taking a look at the mails as
> > sent on linux-pci (and I will keep an eye out for the bug report that
> > Bjorn asked for).
> >
>
> np!
> Nils would you create that BZ please? As you did all the bisect.. :)
I'm only just catching up with all the new messages in this thread,
but I've already opened a bug report, as requested. Come and find it
at:
https://bugzilla.kernel.org/show_bug.cgi?id=89821
Feel free to add more relevant details to it! :-)
Greetings,
Nils
^ permalink raw reply
* Re: [PATCH net] net: Disallow providing non zero VLAN ID for NIC drivers FDB add flow
From: David Miller @ 2014-12-16 20:41 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, jiri, gospo, jhs, john.r.fastabend
In-Reply-To: <1418573945-27840-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Sun, 14 Dec 2014 18:19:05 +0200
> The current implementations all use dev_uc_add_excl() and such whose API
> doesn't support vlans, so we can't make it with NICs HW for now.
>
> Fixes: f6f6424ba773 ('net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del')
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] ip_tunnel: Add missing validation of encap type to ip_tunnel_encap_setup()
From: Thomas Graf @ 2014-12-16 20:50 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx_364iHXxLkA=Ytb=34_2zEy9-3hqfOdt96Ckhm8NwFiQ@mail.gmail.com>
On 12/16/14 at 12:23pm, Tom Herbert wrote:
> On Tue, Dec 16, 2014 at 12:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
> > The encap->type comes straight from Netlink. Validate it against
> > max supported encap types just like ip_encap_hlen() already does.
> >
> > Fixes: a8c5f9 ("ip_tunnel: Ops registration for secondary encap (fou, gue)")
> > Signed-off-by: Thomas Graf <tgraf@suug.ch>
> > ---
> > net/ipv4/ip_tunnel.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> > index 2f498f8..d3e4479 100644
> > --- a/net/ipv4/ip_tunnel.c
> > +++ b/net/ipv4/ip_tunnel.c
> > @@ -573,6 +573,9 @@ int ip_tunnel_encap(struct sk_buff *skb, struct ip_tunnel *t,
> > if (t->encap.type == TUNNEL_ENCAP_NONE)
> > return 0;
> >
> > + if (t->encap.type >= MAX_IPTUN_ENCAP_OPS)
> > + return -EINVAL;
> > +
>
> I don't think this is technically needed, we should have already
> verified the type when setting up the tunnel (ip_encap_hlen).
Right, assuming that every API user always calls ip_tunnel_encap_setup()
on changelink. It's currently the case but since this is a exported
API I figured we better be safe than sorry, in particular as
ip_tunnel_encap() is called before ip_encap_hlen() on xmit.
^ permalink raw reply
* Re: Adding Unisys virtnic.c to the Network Tree
From: Erik Arfvidson @ 2014-12-16 20:52 UTC (permalink / raw)
To: davem, netdev
Cc: benjamin.romer, dzickus, prarit, Bruce.Vessey, sparmaintainer
In-Reply-To: <5490976C.20409@redhat.com>
Hi Dave,
I'm a partner engineer at Red Hat working for Unisys. Currently most of
our driver for our system reside in the staging tree Maintained by Greg
KH. It was suggested by one of the engineers at Red Hat Don Zickus that
in order to accelerate the process of moving the remaining drivers we
pushed directly to their specific system in the Linux Kernel. Currently
virtnic which is our Virtual Network driver resides internally at Unisys
and dependencies are in the staging tree(drivers/staging/unisys/). So
would you be willing to take a look at our Network driver in order to
add it to your Network tree?
Cheers,
Erik Arfvidson
^ 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