* Re: [PATCH] ipv4/ipmr and ipv6/ip6mr: Convert int mroute_do_<foo> to bool
From: David Miller @ 2012-11-25 21:40 UTC (permalink / raw)
To: joe; +Cc: eric.dumazet, netdev
In-Reply-To: <1353872130.6558.17.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sun, 25 Nov 2012 11:35:30 -0800
> Save a few bytes per table by convert mroute_do_assert and
> mroute_do_pim from int to bool.
>
> Remove !! as the compiler does that when assigning int to bool.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: ipmr: various fixes and cleanups
From: David Miller @ 2012-11-25 21:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1353861705.30446.675.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 25 Nov 2012 08:41:45 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> 1) ip_mroute_setsockopt() & ip_mroute_getsockopt() should not
> access/set raw_sk(sk)->ipmr_table before making sure the socket
> is a raw socket, and protocol is IGMP
>
> 2) MRT_INIT should return -EINVAL if optlen != sizeof(int), not
> -ENOPROTOOPT
>
> 3) MRT_ASSERT & MRT_PIM should validate optlen
>
> 4) " (v) ? 1 : 0 " can be written as " !!v "
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add Q: patchwork entries for net/ and drivers/net/
From: David Miller @ 2012-11-25 21:17 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1353791905.6558.7.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sat, 24 Nov 2012 13:18:25 -0800
> Add the netdev patchwork entries for networking drivers.
> Change the W: entry to Q:for networking.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] smsc: Add logging message newlines
From: David Miller @ 2012-11-25 21:15 UTC (permalink / raw)
To: joe; +Cc: steve.glendinning, gregkh, netdev, linux-usb, linux-kernel
In-Reply-To: <1353756469.6558.3.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sat, 24 Nov 2012 03:27:49 -0800
> Avoid any possible message logging interleaving by adding
> missing newlines.
>
> Align arguments.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] qlcnic: fix sparse check endian warnings
From: David Miller @ 2012-11-25 21:14 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver, shahed.shaikh
In-Reply-To: <1353751012-28431-2-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Sat, 24 Nov 2012 04:56:52 -0500
> From: Shahed Shaikh <shahed.shaikh@qlogic.com>
>
> Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH V2 resend] net: dsa/slave: Fix compilation warnings
From: David Miller @ 2012-11-25 21:12 UTC (permalink / raw)
To: viresh.kumar; +Cc: bhutchings, akpm, netdev, linaro-dev, linux-kernel, patches
In-Reply-To: <ecc711bf44722707f57188ee953bbde2f1e20c8c.1353736229.git.viresh.kumar@linaro.org>
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Sat, 24 Nov 2012 11:23:54 +0530
> Currently when none of CONFIG_NET_DSA_TAG_DSA, CONFIG_NET_DSA_TAG_EDSA and
> CONFIG_NET_DSA_TAG_TRAILER is defined, we get following compilation warnings:
>
> net/dsa/slave.c:51:12: warning: 'dsa_slave_init' defined but not used [-Wunused-function]
> net/dsa/slave.c:60:12: warning: 'dsa_slave_open' defined but not used [-Wunused-function]
> net/dsa/slave.c:98:12: warning: 'dsa_slave_close' defined but not used [-Wunused-function]
> net/dsa/slave.c:116:13: warning: 'dsa_slave_change_rx_flags' defined but not used [-Wunused-function]
> net/dsa/slave.c:127:13: warning: 'dsa_slave_set_rx_mode' defined but not used [-Wunused-function]
> net/dsa/slave.c:136:12: warning: 'dsa_slave_set_mac_address' defined but not used [-Wunused-function]
> net/dsa/slave.c:164:12: warning: 'dsa_slave_ioctl' defined but not used [-Wunused-function]
>
> Earlier approach to fix this was discussed here:
>
> lkml.org/lkml/2012/10/29/549
>
> This is another approach to fix it. This is done by some changes in config
> options, which make more sense than the earlier approach. As, atleast one
> tagging option must always be selected for using net/dsa/ infrastructure, this
> patch selects NET_DSA from tagging configs instead of having it as an selectable
> config.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] atm: br2684: Fix excessive queue bloat
From: David Miller @ 2012-11-25 21:09 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, blogic, dave.taht, krzysiek, chas
In-Reply-To: <1353715292.26346.237.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Sat, 24 Nov 2012 00:01:32 +0000
> + /* Allow two packets in the ATM queue. One actually being sent, and one
> + for the ATM 'TX done' handler to send. It shouldn't take long to get
> + the next one from the netdev queue, when we need it. More than that
> + would be bufferbloat. */
Please format this:
/* Like
* this.
*/
and I'll apply this, thanks.
^ permalink raw reply
* Re: [PATCH] net: sched: enable CAN Identifier to be build into kernel
From: David Miller @ 2012-11-25 21:06 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1353667497-25676-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 23 Nov 2012 11:44:57 +0100
> This patch makes it possible to build the CAN Identifier into the kernel, even
> if the CAN support is build as a module.
>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied to net-next, thanks.
> is there a nicer solution to this problem? Or remove the "&& CAN" at all?
I don't see how enabling this with CAN disabled could be
useful, so better to have the dependency there.
^ permalink raw reply
* Re: [PATCH] bonding: in balance-rr mode, set curr_active_slave only if it is up
From: David Miller @ 2012-11-25 21:03 UTC (permalink / raw)
To: mkubecek; +Cc: netdev, fubar, andy, linux-kernel
In-Reply-To: <20121122125202.14252C35B8@unicorn.suse.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Thu, 22 Nov 2012 13:48:39 +0100
> If all slaves of a balance-rr bond with ARP monitor are enslaved
> with down link state, bond keeps down state even after slaves
> go up.
>
> This is caused by bond_enslave() setting curr_active_slave to
> first slave not taking into account its link state. As
> bond_loadbalance_arp_mon() uses curr_active_slave to identify
> whether slave's down->up transition should update bond's link
> state, bond stays down even if slaves are up (until first slave
> goes from up to down at least once).
>
> Before commit f31c7937 "bonding: start slaves with link down for
> ARP monitor", this was masked by slaves always starting in UP
> state with ARP monitor (and MII monitor not relying on
> curr_active_slave being NULL if there is no slave up).
>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Jay/Andy please review.
^ permalink raw reply
* Re: [PATCH] sctp: fix -ENOMEM result with invalid user space pointer in sendto() syscall
From: David Miller @ 2012-11-25 21:03 UTC (permalink / raw)
To: tt.rantala; +Cc: linux-sctp, netdev, nhorman, vyasevich, sri, davej
In-Reply-To: <1353590596-12216-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Thu, 22 Nov 2012 15:23:16 +0200
> Consider the following program, that sets the second argument to the
> sendto() syscall incorrectly:
...
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
This also looks good, Vlad please review this.
Thanks.
^ permalink raw reply
* Re: [PATCH] sctp: fix memory leak in sctp_datamsg_from_user() when copy from user space fails
From: David Miller @ 2012-11-25 21:01 UTC (permalink / raw)
To: tt.rantala; +Cc: linux-sctp, netdev, nhorman, vyasevich, sri, davej
In-Reply-To: <1353590491-12166-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Thu, 22 Nov 2012 15:21:31 +0200
> Trinity (the syscall fuzzer) discovered a memory leak in SCTP,
> reproducible e.g. with the sendto() syscall by passing invalid
> user space pointer in the second argument:
...
> As far as I can tell, the leak has been around since ~2003.
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Looks good to me, Vlad please review.
^ permalink raw reply
* Re: [PATCH] 8139cp: re-enable interrupts after tx timeout
From: David Miller @ 2012-11-25 20:57 UTC (permalink / raw)
To: romieu; +Cc: dwmw2, netdev, jasowang, gilboad, jgarzik
In-Reply-To: <20121124225855.GA17340@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Sat, 24 Nov 2012 23:58:55 +0100
> David Woodhouse <dwmw2@infradead.org> :
>> Recovery doesn't work too well if we leave interrupts disabled...
>>
>> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH] 8139cp: enable bql
From: David Miller @ 2012-11-25 20:55 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, codel
In-Reply-To: <1353590218.26346.214.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 22 Nov 2012 13:16:58 +0000
> This adds support for byte queue limits on RTL8139C+
>
> Tested on real hardware.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> Acked-By: Dave Täht <dave.taht@bufferbloat.net>
Applied to net-next.
> --- drivers/net/ethernet/realtek/8139cp.c~ 2012-11-21 20:49:47.000000000 +0000
> +++ drivers/net/ethernet/realtek/8139cp.c 2012-11-22 13:07:26.119076315 +0000
Please "-p1" root your patches in the future.
^ permalink raw reply
* Re: [PATCH] 8139cp: set ring address after enabling C+ mode
From: David Miller @ 2012-11-25 20:54 UTC (permalink / raw)
To: dwmw2; +Cc: jgarzik, jasowang, netdev
In-Reply-To: <1353529639.26346.164.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Wed, 21 Nov 2012 20:27:19 +0000
> This fixes (for me) a regression introduced by commit b01af457 ("8139cp:
> set ring address before enabling receiver"). That commit configured the
> descriptor ring addresses earlier in the initialisation sequence, in
> order to avoid the possibility of triggering stray DMA before the
> correct address had been set up.
>
> Unfortunately, it seems that the hardware will scribble garbage into the
> TxRingAddr registers when we enable "plus mode" Tx in the CpCmd
> register. Observed on a Traverse Geos router board.
>
> To deal with this, while not reintroducing the problem which led to the
> original commit, we augment cp_start_hw() to write to the CpCmd register
> *first*, then set the descriptor ring addresses, and then finally to
> enable Rx and Tx in the original 8139 Cmd register. The datasheet
> actually indicates that we should enable Tx/Rx in the Cmd register
> *before* configuring the descriptor addresses, but that would appear to
> re-introduce the problem that the offending commit b01af457 was trying
> to solve. And this variant appears to work fine on real hardware.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Applied to net-next.
^ permalink raw reply
* [PATCH] net: ipmr: limit MRT_TABLE identifiers
From: Eric Dumazet @ 2012-11-25 19:44 UTC (permalink / raw)
To: Chen Gang; +Cc: David Miller, netdev
In-Reply-To: <50AC9CF6.2020501@asianux.com>
From: Eric Dumazet <edumazet@google.com>
Name of pimreg devices are built from following format :
char name[IFNAMSIZ]; // IFNAMSIZ == 16
sprintf(name, "pimreg%u", mrt->id);
We must therefore limit mrt->id to 9 decimal digits
or risk a buffer overflow and a crash.
Restrict table identifiers in [0 ... 999999999] interval.
Reported-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ipmr.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 6168c4d..3eab2b2 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1318,6 +1318,10 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
if (get_user(v, (u32 __user *)optval))
return -EFAULT;
+ /* "pimreg%u" should not exceed 16 bytes (IFNAMSIZ) */
+ if (v != RT_TABLE_DEFAULT && v >= 1000000000)
+ return -EINVAL;
+
rtnl_lock();
ret = 0;
if (sk == rtnl_dereference(mrt->mroute_sk)) {
^ permalink raw reply related
* [PATCH] ipv4/ipmr and ipv6/ip6mr: Convert int mroute_do_<foo> to bool
From: Joe Perches @ 2012-11-25 19:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1353870787.30446.831.camel@edumazet-glaptop>
Save a few bytes per table by convert mroute_do_assert and
mroute_do_pim from int to bool.
Remove !! as the compiler does that when assigning int to bool.
Signed-off-by: Joe Perches <joe@perches.com>
---
> mroute is probably used only by a very limited
> number of machines in the world.
>
> Please submit an additional patch, as I already put too many
> things in mine.
On top of Eric's cleanup...
net/ipv4/ipmr.c | 6 +++---
net/ipv6/ip6mr.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 0394a8e..fc09ef9 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -83,8 +83,8 @@ struct mr_table {
struct vif_device vif_table[MAXVIFS];
int maxvif;
atomic_t cache_resolve_queue_len;
- int mroute_do_assert;
- int mroute_do_pim;
+ bool mroute_do_assert;
+ bool mroute_do_pim;
#if defined(CONFIG_IP_PIMSM_V1) || defined(CONFIG_IP_PIMSM_V2)
int mroute_reg_vif_num;
#endif
@@ -1289,7 +1289,7 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
return -EINVAL;
if (get_user(v, (int __user *)optval))
return -EFAULT;
- mrt->mroute_do_assert = !!v;
+ mrt->mroute_do_assert = v;
return 0;
}
#ifdef CONFIG_IP_PIMSM
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index d7330f8..79bb490 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -66,8 +66,8 @@ struct mr6_table {
struct mif_device vif6_table[MAXMIFS];
int maxvif;
atomic_t cache_resolve_queue_len;
- int mroute_do_assert;
- int mroute_do_pim;
+ bool mroute_do_assert;
+ bool mroute_do_pim;
#ifdef CONFIG_IPV6_PIMSM_V2
int mroute_reg_vif_num;
#endif
@@ -1648,7 +1648,7 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, uns
int v;
if (get_user(v, (int __user *)optval))
return -EFAULT;
- mrt->mroute_do_assert = !!v;
+ mrt->mroute_do_assert = v;
return 0;
}
^ permalink raw reply related
* Re: [PATCH net-next] ipv4: ipmr: various fixes and cleanups
From: Eric Dumazet @ 2012-11-25 19:13 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, netdev
In-Reply-To: <1353868023.6558.10.camel@joe-AO722>
On Sun, 2012-11-25 at 10:27 -0800, Joe Perches wrote:
> On Sun, 2012-11-25 at 08:41 -0800, Eric Dumazet wrote:
> > 4) " (v) ? 1 : 0 " can be written as " !!v "
>
> Or maybe the compiler could do it by changing
> mroute_do_assert and mroute_do_pim to bool to
> save a few bytes per table too.
>
>
Yeah, but mroute is probably used only by a very limited
number of machines in the world.
Please submit an additional patch, as I already put too many
things in mine.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: ipmr: various fixes and cleanups
From: Joe Perches @ 2012-11-25 18:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1353861705.30446.675.camel@edumazet-glaptop>
On Sun, 2012-11-25 at 08:41 -0800, Eric Dumazet wrote:
> 4) " (v) ? 1 : 0 " can be written as " !!v "
Or maybe the compiler could do it by changing
mroute_do_assert and mroute_do_pim to bool to
save a few bytes per table too.
^ permalink raw reply
* [PATCH net-next] ipv4: ipmr: various fixes and cleanups
From: Eric Dumazet @ 2012-11-25 16:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
1) ip_mroute_setsockopt() & ip_mroute_getsockopt() should not
access/set raw_sk(sk)->ipmr_table before making sure the socket
is a raw socket, and protocol is IGMP
2) MRT_INIT should return -EINVAL if optlen != sizeof(int), not
-ENOPROTOOPT
3) MRT_ASSERT & MRT_PIM should validate optlen
4) " (v) ? 1 : 0 " can be written as " !!v "
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ipmr.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 6168c4d..af4ef54 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1207,6 +1207,10 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
struct net *net = sock_net(sk);
struct mr_table *mrt;
+ if (sk->sk_type != SOCK_RAW ||
+ inet_sk(sk)->inet_num != IPPROTO_IGMP)
+ return -EOPNOTSUPP;
+
mrt = ipmr_get_table(net, raw_sk(sk)->ipmr_table ? : RT_TABLE_DEFAULT);
if (mrt == NULL)
return -ENOENT;
@@ -1219,11 +1223,8 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
switch (optname) {
case MRT_INIT:
- if (sk->sk_type != SOCK_RAW ||
- inet_sk(sk)->inet_num != IPPROTO_IGMP)
- return -EOPNOTSUPP;
if (optlen != sizeof(int))
- return -ENOPROTOOPT;
+ return -EINVAL;
rtnl_lock();
if (rtnl_dereference(mrt->mroute_sk)) {
@@ -1284,9 +1285,11 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
case MRT_ASSERT:
{
int v;
+ if (optlen != sizeof(v))
+ return -EINVAL;
if (get_user(v, (int __user *)optval))
return -EFAULT;
- mrt->mroute_do_assert = (v) ? 1 : 0;
+ mrt->mroute_do_assert = !!v;
return 0;
}
#ifdef CONFIG_IP_PIMSM
@@ -1294,9 +1297,11 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
{
int v;
+ if (optlen != sizeof(v))
+ return -EINVAL;
if (get_user(v, (int __user *)optval))
return -EFAULT;
- v = (v) ? 1 : 0;
+ v = !!v;
rtnl_lock();
ret = 0;
@@ -1325,7 +1330,8 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
} else {
if (!ipmr_new_table(net, v))
ret = -ENOMEM;
- raw_sk(sk)->ipmr_table = v;
+ else
+ raw_sk(sk)->ipmr_table = v;
}
rtnl_unlock();
return ret;
@@ -1351,6 +1357,10 @@ int ip_mroute_getsockopt(struct sock *sk, int optname, char __user *optval, int
struct net *net = sock_net(sk);
struct mr_table *mrt;
+ if (sk->sk_type != SOCK_RAW ||
+ inet_sk(sk)->inet_num != IPPROTO_IGMP)
+ return -EOPNOTSUPP;
+
mrt = ipmr_get_table(net, raw_sk(sk)->ipmr_table ? : RT_TABLE_DEFAULT);
if (mrt == NULL)
return -ENOENT;
^ permalink raw reply related
* Re: [RFC net-next PATCH V1 0/9] net: fragmentation performance scalability on NUMA/SMP systems
From: Eric Dumazet @ 2012-11-25 16:11 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David S. Miller, Florian Westphal, netdev, Pablo Neira Ayuso,
Thomas Graf, Cong Wang, Patrick McHardy, Paul E. McKenney,
Herbert Xu
In-Reply-To: <1353833627.11754.134.camel@localhost>
On Sun, 2012-11-25 at 09:53 +0100, Jesper Dangaard Brouer wrote:
> Yes, for the default large 64k packets size, its just a "fake"
> benchmark. And notice with my fixes, we are even faster than the
> none-frag/single-UDP packet case... but its because we are getting a
> GSO/GRO effect.
Could you elaborate on this GSO/GRO effect ?
^ permalink raw reply
* [PATCH] net: qmi_wwan: add Huawei E173
From: Bjørn Mork @ 2012-11-25 16:03 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Thomas Schäfer, Bjørn Mork
The Huawei E173 is a QMI/wwan device which normally appear
as 12d1:1436 in Linux. The descriptors displayed in that
mode will be picked up by cdc_ether. But the modem has
another mode with a different device ID and a slightly
different set of descriptors. This is the mode used by
Windows like this:
3Modem: USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001
Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002
PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3b566fa..1ea91f4 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -385,6 +385,7 @@ static const struct usb_device_id products[] = {
},
/* 3. Combined interface devices matching on interface number */
+ {QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */
{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
{QMI_FIXED_INTF(0x19d2, 0x0012, 1)},
{QMI_FIXED_INTF(0x19d2, 0x0017, 3)},
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] ewrk3: silence GCC warning
From: richard -rw- weinberger @ 2012-11-25 10:45 UTC (permalink / raw)
To: Paul Bolle; +Cc: netdev, linux-kernel
In-Reply-To: <1353759165.1420.33.camel@x61.thuisdomein>
On Sat, Nov 24, 2012 at 1:12 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> Building ewrk3.o triggers this GCC warning:
> drivers/net/ethernet/dec/ewrk3.c: In function '__check_irq':
> drivers/net/ethernet/dec/ewrk3.c:1915:1: warning: return from incompatible pointer type [enabled by default]
>
> This can be trivially fixed by changing the 'irq' parameter from int to
> byte (which is the alias for unsigned char for module parameters).
>
> While we're touching this code also drop an outdated comment, that
> should have been dropped with the patch named "MODULE_PARM conversions"
> from early 2005.
Please send this change as an additional patch.
--
Thanks,
//richard
^ permalink raw reply
* Re: [RFC net-next PATCH V1 0/9] net: fragmentation performance scalability on NUMA/SMP systems
From: Jesper Dangaard Brouer @ 2012-11-25 8:53 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Florian Westphal, netdev, Pablo Neira Ayuso,
Thomas Graf, Cong Wang, Patrick McHardy, Paul E. McKenney,
Herbert Xu
In-Reply-To: <1353810665.2590.4774.camel@edumazet-glaptop>
On Sat, 2012-11-24 at 18:31 -0800, Eric Dumazet wrote:
> On Fri, 2012-11-23 at 14:08 +0100, Jesper Dangaard Brouer wrote:
> > This patchset implements significant performance improvements for
> > fragmentation handling in the kernel, with a focus on NUMA and SMP
> > based systems.
> >
> > Review:
> >
> > Please review these patches. I have on purpose added comments in the
> > code with the "//" comments style. These comments are to be removed
> > before applying. They serve as a questions to, you, the reviewer.
> >
> > The fragmentation code today:
> >
> > The fragmentation code "protects" kernel resources, by implementing
> > some memory resource limitation code. This is centered around a
> > global readers-writer lock, and (per network namespace) an atomic mem
> > counter and a LRU (Least-Recently-Used) list. (Although separate
> > global variables and namespace resources, are kept for IPv4, IPv6
> > and Netfilter reassembly.)
> >
> > The code tries to keep the memory usage between a high and low
> > threshold (see: /proc/sys/net/ipv4/ipfrag_{high,low}_thresh). The
> > "evictor" code cleans up fragments, when the high threshold is
> > exceeded, and stops only, when the low threshold is reached.
> >
> > The scalability problem:
> >
> > Having a global/central variable for a resource limit is obviously a
> > scalability issue on SMP systems, and even amplified on a NUMA based
> > system.
> >
>
>
> But ... , what practical workload even use fragments ?
(1) DNS (default for Bind) will use up-to 3 UDP fragments before
switching to TCP. This is getting more and more relevant after the
introduction of DNSSEC. That's why I'm explicit testing the 3xUDP
fragments so heavily.
(2) For IPVS (load-balancing) we have recently allowed fragmentation in
tunnel mode, towards the realservers (to hide the MTU reduction for the
clients). Thus, we need better frag performance in this case.
(3) I also have a customer that have a usage scenario/application (at
4x10G) that needs this... but I'm trying to convince them to fix/change
their application...
Scenario (1) is the real reason I want to fix this scalability issue in
the code.
> Sure, netperf -t UDP_STREAM uses frags, but its a benchmark.
Yes, for the default large 64k packets size, its just a "fake"
benchmark. And notice with my fixes, we are even faster than the
none-frag/single-UDP packet case... but its because we are getting a
GSO/GRO effect.
That's why I'm adjusting the UDP "frag" packet size to get a more
realistic use case... to simulate the DNS use-case (1).
> The only heavy user was NFS in the days it was using UDP, a very long
> time ago.
>
> A single lost fragment means the whole packet is lost.
That is correct, that's why we need the fix in patch-01.
(It actually reminds me of the problem with ADSL/ATM, where (small) ATM
frame are used for carrying IP packets, and when some (more central) ATM
link gets overloaded and starts to drops ATM frames, not taking the AAL5
packets into account).
> Another problem with fragments is the lack of 4-tuple hashing, as only
> the first frag contains the dst/src ports.
>
> Also there is the sysctl_ipfrag_max_dist issue...
>
> Hint : many NIC provide TSO (TCP offload), but none provide UFO,
> probably because there is no demand for it.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* private netdev flags into UAPI?
From: Or Gerlitz @ 2012-11-25 7:43 UTC (permalink / raw)
To: David Howells, netdev
not sure if this has been brought up before, but I realized that the
private IFF_yyy netdevice flags which weren't exposed to user space so
far have been moved to include/uapi/linux/if.h, isn't that wrong?
Or.
> /* Private (from user) interface flags (netdevice->priv_flags). */
> #define IFF_802_1Q_VLAN 0x1 /* 802.1Q VLAN device. */
> #define IFF_EBRIDGE 0x2 /* Ethernet bridging device. */
> [...] * change when it's running */
^ permalink raw reply
* [PATCH net] ipv4: avoid passing NULL to inet_putpeer() in icmpv4_xrlim_allow()
From: Neal Cardwell @ 2012-11-25 4:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell
inet_getpeer_v4() can return NULL under OOM conditions, and while
inet_peer_xrlim_allow() is OK with a NULL peer, inet_putpeer() will
crash.
This code path now uses the same idiom as the others from:
1d861aa4b3fb08822055345f480850205ffe6170 ("inet: Minimize use of
cached route inetpeer.").
Signed-off-by: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/icmp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index f2eccd5..17ff9fd 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -257,7 +257,8 @@ static inline bool icmpv4_xrlim_allow(struct net *net, struct rtable *rt,
struct inet_peer *peer = inet_getpeer_v4(net->ipv4.peers, fl4->daddr, 1);
rc = inet_peer_xrlim_allow(peer,
net->ipv4.sysctl_icmp_ratelimit);
- inet_putpeer(peer);
+ if (peer)
+ inet_putpeer(peer);
}
out:
return rc;
--
1.7.7.3
^ 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