* Re: [RFC net-next] netpoll: use static branch
From: Stephen Hemminger @ 2012-09-19 20:00 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, Eric Dumazet, netdev
In-Reply-To: <1348030210.11754.7.camel@cr0>
On Wed, 19 Sep 2012 12:50:10 +0800
Cong Wang <amwang@redhat.com> wrote:
> On Tue, 2012-09-18 at 14:10 -0700, Stephen Hemminger wrote:
> > This is an attempt to optimize netpoll when not used.
> >
> > Since distro's enable everything and netpoll is only occasionally
> > used, improve performance by getting netpoll condition check
> > out of the Rx fastpath.
> >
> > Compile tested only, I have no real use for netpoll.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> >
> > ---
> > include/linux/netpoll.h | 28 ++++++++++++++++++++--------
> > net/core/netpoll.c | 8 +++++++-
> > 2 files changed, 27 insertions(+), 9 deletions(-)
> >
> > --- a/include/linux/netpoll.h 2012-09-18 13:25:15.575750004 -0700
> > +++ b/include/linux/netpoll.h 2012-09-18 13:29:16.245323347 -0700
> > @@ -66,10 +66,16 @@ static inline void netpoll_send_skb(stru
> >
> >
> > #ifdef CONFIG_NETPOLL
> > +extern struct static_key netpoll_needed;
> > +
> > static inline bool netpoll_rx_on(struct sk_buff *skb)
> > {
> > - struct netpoll_info *npinfo = rcu_dereference_bh(skb->dev->npinfo);
> > + struct netpoll_info *npinfo;
> > +
> > + if (static_key_true(&netpoll_needed))
> > + return false;
> >
>
> I think we should use static_key_false() here, as netpoll is an
> "unlikely" code path.
>
> Using static branch is a good idea though.
>
> Thanks.
But static_key_true is just a wrapper around !static_key_false()
^ permalink raw reply
* [PATCH] net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200
From: Bjørn Mork @ 2012-09-19 20:03 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Bjørn Mork,
Fangxiaozhi (Franko), Thomas Schäfer, Dan Williams,
Shawn J. Goff
One of the modes of Huawei E367 has this QMI/wwan interface:
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=07 Driver=(none)
E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Huawei use subclass and protocol to identify vendor specific
functions, so adding a new vendor rule for this combination.
The Pantech devices UML290 (106c:3718) and P4200 (106c:3721) use
the same subclass to identify the QMI/wwan function. Replace the
existing device specific UML290 entries with generic vendor matching,
adding support for the Pantech P4200.
The ZTE MF683 has 6 vendor specific interfaces, all using
ff/ff/ff for cls/sub/prot. Adding a match on interface #5 which
is a QMI/wwan interface.
Cc: Fangxiaozhi (Franko) <fangxiaozhi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Cc: Thomas Schäfer <tschaefer-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
Cc: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Shawn J. Goff <shawn7400-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
drivers/net/usb/qmi_wwan.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index b1ba68f..3543c9e 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -366,16 +366,20 @@ static const struct usb_device_id products[] = {
},
/* 2. Combined interface devices matching on class+protocol */
+ { /* Huawei E367 and possibly others in "Windows mode" */
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 7),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
{ /* Huawei E392, E398 and possibly others in "Windows mode" */
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 17),
.driver_info = (unsigned long)&qmi_wwan_shared,
},
- { /* Pantech UML290 */
- USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
+ { /* Pantech UML290, P4200 and more */
+ USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
.driver_info = (unsigned long)&qmi_wwan_shared,
},
{ /* Pantech UML290 - newer firmware */
- USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
+ USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
.driver_info = (unsigned long)&qmi_wwan_shared,
},
@@ -383,6 +387,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x19d2, 0x0055, 1)}, /* ZTE (Vodafone) K3520-Z */
{QMI_FIXED_INTF(0x19d2, 0x0063, 4)}, /* ZTE (Vodafone) K3565-Z */
{QMI_FIXED_INTF(0x19d2, 0x0104, 4)}, /* ZTE (Vodafone) K4505-Z */
+ {QMI_FIXED_INTF(0x19d2, 0x0157, 5)}, /* ZTE MF683 */
{QMI_FIXED_INTF(0x19d2, 0x0167, 4)}, /* ZTE MF820D */
{QMI_FIXED_INTF(0x19d2, 0x0326, 4)}, /* ZTE MF821D */
{QMI_FIXED_INTF(0x19d2, 0x1008, 4)}, /* ZTE (Vodafone) K3570-Z */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 2/2] Using LP firmware for taking advantage of the low-power capabilities.
From: Jarl Friis @ 2012-09-19 20:10 UTC (permalink / raw)
To: Stefano Brivio, Gábor Stefanik
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, John W. Linville, Jarl Friis
In-Reply-To: <1348053493-22955-2-git-send-email-jarl-bE7lSbLpGj1/SzgSGea1oA@public.gmane.org>
2012/9/19 Jarl Friis <jarl-bE7lSbLpGj1/SzgSGea1oA@public.gmane.org>:
> This is using the LP specific firmware to better take advantage of the
> Low-Power capabilities.
Gosh... I just realized that the code I introduced is completely
untested. My hardware does not reach these pieces of code...
Sorry...
However the code seems natural (due to the firmware file name pattern)
for a PHY-LP hardware, that is a bcm4313 chip (pciid 14e4:4315).
So if there is anybody with such hardware... you might want to try it... Sorry.
Jarl
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] tcp: flush DMA queue before sk_wait_data if rcv_wnd is zero
From: David Miller @ 2012-09-19 20:10 UTC (permalink / raw)
To: mkubecek; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20120914170432.C8B8DC6405@unicorn.suse.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Fri, 14 Sep 2012 16:59:52 +0200
> If recv() syscall is called for a TCP socket so that
> - IOAT DMA is used
> - MSG_WAITALL flag is used
> - requested length is bigger than sk_rcvbuf
> - enough data has already arrived to bring rcv_wnd to zero
> then when tcp_recvmsg() gets to calling sk_wait_data(), receive
> window can be still zero while sk_async_wait_queue exhausts
> enough space to keep it zero. As this queue isn't cleaned until
> the tcp_service_net_dma() call, sk_wait_data() cannot receive
> any data and blocks forever.
>
> If zero receive window and non-empty sk_async_wait_queue is
> detected before calling sk_wait_data(), process the queue first.
>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Applied and queued up for -stable, thanks.
> Cc: <stable@vger.kernel.org>
Please do not CC: stable on networking bug fixes like this.
Simply ask me to add it to the networking -stable queue instead.
I do not want fixes to propagate immedately to -stable right when they
hit Linus's tree. Rather, I want them to soak upstream for a while
before they get submitted to -stable.
And that's why I maintain a special queue for networking fixes
which should be submitted to -stable at some point in the future
at:
http://patchwork.ozlabs.org/user/bundle/2566/?state=*
Thanks.
^ permalink raw reply
* Re: [PATCH v4] ipconfig: Inform user if carrier is not ready
From: David Miller @ 2012-09-19 20:13 UTC (permalink / raw)
To: erwanaliasr1; +Cc: netdev
In-Reply-To: <1347656179-17638-1-git-send-email-erwanaliasr1@gmail.com>
From: Erwan Velu <erwanaliasr1@gmail.com>
Date: Fri, 14 Sep 2012 22:56:19 +0200
> While using the ip= option at the cmdline, the kernel can hold the boot
> process for 2 minutes (CONF_CARRIER_TIMEOUT) if the carrier is not
> present.
>
> While waiting the carrier, user is not informed about this situation and
> so could think the kernel is frozen.
>
> If we don't get the carrier after some seconds, let's display a message to
> inform the user about the remaining time before reaching the timeout.
>
> Signed-off-by: Erwan Velu <erwanaliasr1@gmail.com>
> ---
> net/ipv4/ipconfig.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
> index 67e8a6b..fb17bad 100644
> --- a/net/ipv4/ipconfig.c
> +++ b/net/ipv4/ipconfig.c
> @@ -90,6 +90,7 @@
> /* Define the friendly delay before and after opening net devices */
> #define CONF_POST_OPEN 10 /* After opening: 10 msecs */
> #define CONF_CARRIER_TIMEOUT 120000 /* Wait for carrier timeout */
> +#define CONF_WARN_CARRIER_TIMEOUT 5000 /* Time before showing a warning message */
>
> /* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
> #define CONF_OPEN_RETRIES 2 /* (Re)open devices twice */
> @@ -205,6 +206,7 @@ static int __init ic_open_devs(void)
> struct net_device *dev;
> unsigned short oflags;
> unsigned long start;
> + unsigned int loops = 0;
>
> last = &ic_first_dev;
> rtnl_lock();
> @@ -266,6 +268,17 @@ static int __init ic_open_devs(void)
> if (ic_is_init_dev(dev) && netif_carrier_ok(dev))
> goto have_carrier;
>
> + /* This loop is blocking the boot process until
> + * we get the carrier or reach the timeout.
> + * We have to inform the user about the situation as
> + * it could look like a kernel freeze.
> + * After CONF_WARN_CARRIER_TIMEOUT milliseconds,
> + * we display the remaing time before reaching the timeout.
> + */
Please format this comment consistently. On the first line you have one
leading space, and on all the subsequent lines you use two leading spaces.
This looks ugly, use one leading space on every. line
/* This loop is blocking the boot process until
* we get the carrier or reach the timeout.
* We have to inform the user about the situation as
* it could look like a kernel freeze.
* After CONF_WARN_CARRIER_TIMEOUT milliseconds,
* we display the remaing time before reaching the timeout.
*/
> + if (++loops == CONF_WARN_CARRIER_TIMEOUT) {
> + pr_info("IP-Config: Waiting up to %d seconds for carrier on interface\n",
> + (CONF_CARRIER_TIMEOUT - CONF_WARN_CARRIER_TIMEOUT)/ 1000);
> + }
Missing space right before the "/" in the calculation and this line
non-trivially exceeds 80 columns. Perhaps split it up like:
((CONF_CARRIER_TIMEOUT -
CONF_WARN_CARRIER_TIMEOUT)
/ 1000));
^ permalink raw reply
* Re: [PATCH] net: do not disable sg for AoE
From: Ed Cashin @ 2012-09-19 20:14 UTC (permalink / raw)
To: David Miller
Cc: akpm@linux-foundation.org, jesse@nicira.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20120919.160009.1489407274317336389.davem@davemloft.net>
On Sep 19, 2012, at 4:00 PM, David Miller wrote:
> Please do not incorporate the date of the commit in your local tree
> into the Date: field advertised in your outgoing emails when you post
> patches.
Noted. I will remove the Date field added by git-format-patch from now on.
Sorry for the inconvenience.
--
Ed Cashin
ecashin@coraid.com
^ permalink raw reply
* Re: [RFC] tcp: use order-3 pages in tcp_sendmsg()
From: Ben Hutchings @ 2012-09-19 20:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1348067659.26523.949.camel@edumazet-glaptop>
On Wed, 2012-09-19 at 17:14 +0200, Eric Dumazet wrote:
> On Mon, 2012-09-17 at 13:07 -0400, David Miller wrote:
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Mon, 17 Sep 2012 19:04:53 +0200
> >
> > > On Mon, 2012-09-17 at 19:02 +0200, Eric Dumazet wrote:
> > >
> > >> A driver already exports a dev->gso_max_size, dev->gso_max_segs, I guess
> > >> it could export a dev->max_seg_order (default to 0)
> > >
> > > Oh well, if we use a per thread order-3 page, a driver wont define an
> > > order, but the max size of a segment (dev->max_seg_size).
> >
> > Since you said that your audit showed that most can handle arbitrary
> > segment sizes, it's better to default to infinity or similar.
> >
> > Otherwise we'll have to annotate almost every single driver with a
> > non-zero value, that's not an efficient way to handle this and
> > deploy the higher performance quickly.
>
> I did some tests and got no problem so far, even using splice() [ this
> one was tricky because it only deals with order-0 pages at this moment ]
>
> NIC tested : ixgbe, igb, bnx2x, tg3, mellanox mlx4
I think sfc would also be fine with this; we split at 4K boundaries
regardless of the host page size.
My only concern is fragmentation on busy machines making high-order
allocations more prone to failure (though this change might well slow
that fragmentation). The larger allocation size should at least be made
dependent on (sk->sk_allocation & GFP_KERNEL) == GPF_KERNEL. (Even
then, I've seen some stress test failures where ring reallocation
(similar size, GFP_KERNEL) fails. But those were done with an older
kernel version and the current mm should do better.)
Ben.
> On loopback, performance of netperf goes from 31900 Mb/s to 38500 Mb/s,
> thats a 20 % increase.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [patch net] sky2: fix rx filter setup on link up
From: Stephen Hemminger @ 2012-09-19 20:22 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, mlindner, linux-kernel
In-Reply-To: <1347894617-13614-1-git-send-email-jiri@resnulli.us>
Rather than saving and restoring values, why not just redo the
full setup? This would also determine if the change was a result
of something outside the driver.
--- a/drivers/net/ethernet/marvell/sky2.c 2012-09-18 21:12:01.156438131 -0700
+++ b/drivers/net/ethernet/marvell/sky2.c 2012-09-19 13:20:40.373620276 -0700
@@ -2201,6 +2201,8 @@ static void sky2_link_up(struct sky2_por
sky2_enable_rx_tx(sky2);
+ sky2_set_multicast(sky2->netdev);
+
gm_phy_write(hw, port, PHY_MARV_INT_MASK, PHY_M_DEF_MSK);
netif_carrier_on(sky2->netdev);
^ permalink raw reply
* Re: Netfilter lacks ability to filter packets via Application-origin
From: Ben Hutchings @ 2012-09-19 20:24 UTC (permalink / raw)
To: Chad Gray; +Cc: netdev@vger.kernel.org
In-Reply-To: <COL002-W12C33BCBEB56AC8ADFF6B0F39B0@phx.gbl>
On Wed, 2012-09-19 at 15:40 -0400, Chad Gray wrote:
> Users need the ability for Linux firewall to filter packets based on what
> Application they are originating from. This ability is present in Mac and
> Windows firewalls, but not Linux.
>
> For example, users would like ability to open Port 80 for Firefox, but keep
> Port 80 closed for other applications.
>
> This ability enhances Privacy & Security of the user but also helps to better
> inform the user about the comings and goings of internet traffic and what
> application/s are causing the traffic.
Most of the Linux Security Modules seem to support this sort of network
policy.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] sched: fix virtual-start-time update in QFQ
From: David Miller @ 2012-09-19 20:25 UTC (permalink / raw)
To: paolo.valente; +Cc: shemminger, jhs, fchecconi, rizzo, netdev, linux-kernel
In-Reply-To: <20120915104134.GA29862@paolo-ThinkPad-W520>
From: Paolo Valente <paolo.valente@unimore.it>
Date: Sat, 15 Sep 2012 12:41:35 +0200
> If the old timestamps of a class, say cl, are stale when the class
> becomes active, then QFQ may assign to cl a much higher start time
> than the maximum value allowed. This may happen when QFQ assigns to
> the start time of cl the finish time of a group whose classes are
> characterized by a higher value of the ratio
> max_class_pkt/weight_of_the_class with respect to that of
> cl. Inserting a class with a too high start time into the bucket list
> corrupts the data structure and may eventually lead to crashes.
> This patch limits the maximum start time assigned to a class.
>
> Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Applied and queued up for -stable, thanks.
Please use "pkt_sched" instead of just plain "sched" in the prefixes
of your subject lines for packet scheduler changes so such changes
can be distinguished from process scheduler changes.
I fixed it up for you this time.
Thanks.
^ permalink raw reply
* Re: [PATCH] fix ZOMBIE state bug in PPPOE driver
From: David Miller @ 2012-09-19 20:26 UTC (permalink / raw)
To: stid.smth; +Cc: linux-kernel, netdev
In-Reply-To: <CANEcBPQnsV26UkyGxms0vKM9wK1NxfKjN4Z0qGipQtV4UPZgGA@mail.gmail.com>
From: Xiaodong Xu <stid.smth@gmail.com>
Date: Sun, 16 Sep 2012 10:30:53 +0800
> Hi All,
>
> I found a bug in kernel PPPOE driver.
> When PPPOE is running over a virtual ethernet interface (e.g., a
> bonding interface) and the user tries to delete the interface in case
> the PPPOE state is ZOMBIE, the kernel will loop infinitely while
> unregistering net_device for the reference count is not reset to zero
> which should be done by dev_put().
>
> The following patch could fix this issue:
>
> $ git diff
Please read Documentation/SubmittingPatches in the kernel source tree
to learn how to properly submit a patch.
In particular your patch was missing a proper signoff and your Subject
line is incorrectly specified.
Thanks.
^ permalink raw reply
* Re: [PATCH v3] net-tcp: TCP/IP stack bypass for loopback connections
From: David Miller @ 2012-09-19 20:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: brutus, edumazet, netdev
In-Reply-To: <1347913239.26523.173.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 17 Sep 2012 22:20:39 +0200
> On Mon, 2012-09-17 at 11:58 -0700, Bruce "Brutus" Curtis wrote:
>> From: "Bruce \"Brutus\" Curtis" <brutus@google.com>
>>
>> TCP/IP loopback socket pair stack bypass, based on an idea by, and
>> rough upstream patch from, David Miller <davem@davemloft.net> called
>> "friends", the data structure modifcations and connection scheme are
>> reused with extensive data-path changes.
>
> ...
>
>>
>> + if (skb->friend) {
>> + /*
>> + * If friends haven't been made yet, our sk_friend
>> + * still == NULL, then update with the ACK's friend
>> + * value (the listen()er's sock addr) which is used
>> + * as a place holder.
>> + */
>> + cmpxchg(&sk->sk_friend, NULL, skb->friend);
>> + }
>
>
> There is a fundamental issue with this patch
>
> Setting skb->friend to a socket structure, without holding a reference
> on it is going to add subtle races and bugs.
>
> In this code, we have no guarantee the socket pointed by skb->friend was
> eventually freed and/or reused.
>
> But adding references might be overkill, as we need to unref them in
> some places, in hot path.
I have an idea on how to handle this.
In drivers/net/loopback.c:loopback_tx(), skip the SKB orphan operation
if there is a friend socket at skb->friend.
When sending such friend SKBs out at connection startup, arrange it
such that the skb->destructor will zap the skb->friend pointer to
NULL.
Also, in skb_orphan*(), if necessary, set skb->friend to NULL.
skb->sk will hold a reference to the socket, and since skb->friend
will be equal, this will make sure a pointer to an unreferenced
socket does not escape.
^ permalink raw reply
* Re: [patch net] sky2: fix rx filter setup on link up
From: Jiri Pirko @ 2012-09-19 20:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, mlindner, linux-kernel
In-Reply-To: <20120919132248.5fced1c7@s6510.linuxnetplumber.net>
Wed, Sep 19, 2012 at 10:22:48PM CEST, shemminger@vyatta.com wrote:
>Rather than saving and restoring values, why not just redo the
>full setup? This would also determine if the change was a result
>of something outside the driver.
You cannot call sky2_set_multicast() directly here. It is called from
__dev_set_rx_mode(). You would have to take at lease netif_addr_lock()
here. I think that clearer is to remember computed value....
>
>
>--- a/drivers/net/ethernet/marvell/sky2.c 2012-09-18 21:12:01.156438131 -0700
>+++ b/drivers/net/ethernet/marvell/sky2.c 2012-09-19 13:20:40.373620276 -0700
>@@ -2201,6 +2201,8 @@ static void sky2_link_up(struct sky2_por
>
> sky2_enable_rx_tx(sky2);
>
>+ sky2_set_multicast(sky2->netdev);
>+
> gm_phy_write(hw, port, PHY_MARV_INT_MASK, PHY_M_DEF_MSK);
>
> netif_carrier_on(sky2->netdev);
^ permalink raw reply
* Re: [PATCH net-next] netdev: make address const in device address management
From: David Miller @ 2012-09-19 20:38 UTC (permalink / raw)
To: shemminger; +Cc: jeffrey.t.kirsher, john.r.fastabend, netdev
In-Reply-To: <20120917130326.028dac29@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 17 Sep 2012 13:03:26 -0700
> The internal functions for add/deleting addresses don't change
> their argument.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [Patch net-next] l2tp: fix compile error when CONFIG_IPV6=m and CONFIG_L2TP=y
From: David Miller @ 2012-09-19 20:44 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1347947642-20330-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Tue, 18 Sep 2012 13:54:02 +0800
> When CONFIG_IPV6=m and CONFIG_L2TP=y, I got the following compile error:
...
> This is due to l2tp uses symbols from IPV6, so when l2tp is
> builtin, IPV6 has to be builtin too.
>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
The correct way to express this is:
depends on (IPV6 || IPV6=n)
Which results in the KCONFIG option only being offers in modes
compatible with the dependency. Using a 'select' doesn't work
properly in these kinds of cases.
Anyways, grep for that string to see how it is used in other similar
situations.
^ permalink raw reply
* Re: Opportunity to backport pch_gbe patches to stable 3.2.x
From: Ben Hutchings @ 2012-09-19 20:49 UTC (permalink / raw)
To: Erwan Velu; +Cc: netdev
In-Reply-To: <505A11E2.8000403@gmail.com>
On Wed, Sep 19, 2012 at 08:41:38PM +0200, Erwan Velu wrote:
> Hi there,
>
> I'm using on a daily use and in production 3.2.x kernels (.29 currently) on a Kontron Nano-etx board that features the pch_gbe network driver.
>
> I've been experiencing lots of troubles on this kernel series but since I've backported the following commits back to my 3.2.x, it works far better.
>
> So from the history of next the following commits apply perfectly and runs very well.
>
> I do think that other users of pch_gbe will appreciate this.
>
> 1a0bdadb4e36abac63b0a9787f372aac30c11a9e
[...]
This first one is adding support for an extra hardware feature, which
is not suitable material for stable. Please pick out only the
important bug fixes, per Documentation/stable_kernel_rules.txt.
If you want the driver to be completely backported, look at the
compat-drivers project
<https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers>
or distribution kernels instead of stable.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
^ permalink raw reply
* Re: Netfilter lacks ability to filter packets via Application-origin
From: John Fastabend @ 2012-09-19 20:50 UTC (permalink / raw)
To: Chad Gray; +Cc: Ben Hutchings, netdev@vger.kernel.org
In-Reply-To: <1348086252.2636.58.camel@bwh-desktop.uk.solarflarecom.com>
On 9/19/2012 1:24 PM, Ben Hutchings wrote:
> On Wed, 2012-09-19 at 15:40 -0400, Chad Gray wrote:
>> Users need the ability for Linux firewall to filter packets based on what
>> Application they are originating from. This ability is present in Mac and
>> Windows firewalls, but not Linux.
>>
>> For example, users would like ability to open Port 80 for Firefox, but keep
>> Port 80 closed for other applications.
>>
>> This ability enhances Privacy & Security of the user but also helps to better
>> inform the user about the comings and goings of internet traffic and what
>> application/s are causing the traffic.
>
> Most of the Linux Security Modules seem to support this sort of network
> policy.
>
> Ben.
>
Another approach might be to use the net_cls cgroups and set the
classid matching against it with tc or netfilters.
.John
^ permalink raw reply
* Re: [PATCH v3] net-tcp: TCP/IP stack bypass for loopback connections
From: Eric Dumazet @ 2012-09-19 21:03 UTC (permalink / raw)
To: David Miller; +Cc: brutus, edumazet, netdev
In-Reply-To: <20120919.163406.487082174277409074.davem@davemloft.net>
On Wed, 2012-09-19 at 16:34 -0400, David Miller wrote:
> I have an idea on how to handle this.
>
> In drivers/net/loopback.c:loopback_tx(), skip the SKB orphan operation
> if there is a friend socket at skb->friend.
>
> When sending such friend SKBs out at connection startup, arrange it
> such that the skb->destructor will zap the skb->friend pointer to
> NULL.
>
> Also, in skb_orphan*(), if necessary, set skb->friend to NULL.
>
> skb->sk will hold a reference to the socket, and since skb->friend
> will be equal, this will make sure a pointer to an unreferenced
> socket does not escape.
I now am wondering if we still need skb->friend field.
If skb->sk is not zeroed by a premature skb_orphan(), then
skb->sk->sk_friend gives the friend ?
^ permalink raw reply
* Re: kernel BUG at kernel/timer.c:748!
From: Dave Jones @ 2012-09-19 21:10 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Julian Anastasov, netdev
In-Reply-To: <CAK6E8=cAOTqOzrzWCG=_wcQkWKS4bKh1HJ0UAH2vJNqvDPh+GQ@mail.gmail.com>
On Sat, Sep 15, 2012 at 11:16:52AM -0700, Yuchung Cheng wrote:
> On Fri, Sep 14, 2012 at 2:29 PM, Dave Jones <davej@redhat.com> wrote:
> > On Wed, Sep 05, 2012 at 11:48:29PM +0300, Julian Anastasov wrote:
> >
> > > > kernel BUG at kernel/timer.c:748!
> > > > Call Trace:
> > > > ? lock_sock_nested+0x8d/0xa0
> > > > sk_reset_timer+0x1c/0x30
> > > > ? sock_setsockopt+0x8c/0x960
> > > > inet_csk_reset_keepalive_timer+0x20/0x30
> > > > tcp_set_keepalive+0x3d/0x50
> > > > sock_setsockopt+0x923/0x960
> > > > ? trace_hardirqs_on_caller+0x16/0x1e0
> > > > ? fget_light+0x24c/0x520
> > > > sys_setsockopt+0xc6/0xe0
> > > > system_call_fastpath+0x1a/0x1f
> > >
> > > Can this help? In case you see ICMPV6_PKT_TOOBIG...
> > >
> > > [PATCH] tcp: fix possible socket refcount problem for ipv6
> >
> > I just managed to reproduce this bug on rc5 with this patch,
> > so it doesn't seem to help.
> Could you post some tcpdump traces?
It's likely that there aren't any packets. The fuzzer isn't smart
enough (yet) to do anything too clever to the sockets it creates.
More likely is that this is some race where thread A is doing a setsockopt
while thread B is doing a tear-down of the same socket.
Dave
^ permalink raw reply
* Re: [PATCH v3] net-tcp: TCP/IP stack bypass for loopback connections
From: David Miller @ 2012-09-19 21:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: brutus, edumazet, netdev
In-Reply-To: <1348088634.31352.26.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 19 Sep 2012 23:03:54 +0200
> On Wed, 2012-09-19 at 16:34 -0400, David Miller wrote:
>
>> I have an idea on how to handle this.
>>
>> In drivers/net/loopback.c:loopback_tx(), skip the SKB orphan operation
>> if there is a friend socket at skb->friend.
>>
>> When sending such friend SKBs out at connection startup, arrange it
>> such that the skb->destructor will zap the skb->friend pointer to
>> NULL.
>>
>> Also, in skb_orphan*(), if necessary, set skb->friend to NULL.
>>
>> skb->sk will hold a reference to the socket, and since skb->friend
>> will be equal, this will make sure a pointer to an unreferenced
>> socket does not escape.
>
> I now am wondering if we still need skb->friend field.
>
> If skb->sk is not zeroed by a premature skb_orphan(), then
>
> skb->sk->sk_friend gives the friend ?
Good point.
^ permalink raw reply
* Re: [PATCH v3] net-tcp: TCP/IP stack bypass for loopback connections
From: Bruce Curtis @ 2012-09-19 21:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, edumazet, netdev
In-Reply-To: <1348088634.31352.26.camel@edumazet-glaptop>
On Wed, Sep 19, 2012 at 2:03 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> On Wed, 2012-09-19 at 16:34 -0400, David Miller wrote:
>
> > I have an idea on how to handle this.
> >
> > In drivers/net/loopback.c:loopback_tx(), skip the SKB orphan operation
> > if there is a friend socket at skb->friend.
> >
> > When sending such friend SKBs out at connection startup, arrange it
> > such that the skb->destructor will zap the skb->friend pointer to
> > NULL.
> >
> > Also, in skb_orphan*(), if necessary, set skb->friend to NULL.
> >
> > skb->sk will hold a reference to the socket, and since skb->friend
> > will be equal, this will make sure a pointer to an unreferenced
> > socket does not escape.
>
> I now am wondering if we still need skb->friend field.
>
> If skb->sk is not zeroed by a premature skb_orphan(), then
>
> skb->sk->sk_friend gives the friend ?
>
>
Good question, in the friends data path it's only used to
differentiate a friend directly Q'd skb so should work, I'll look into
it.
^ permalink raw reply
* Re: [Patch net-next] netpoll: call ->ndo_select_queue() in tx path
From: David Miller @ 2012-09-19 21:21 UTC (permalink / raw)
To: amwang; +Cc: netdev, s.munaut, edumazet
In-Reply-To: <1347948991-20860-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Tue, 18 Sep 2012 14:16:31 +0800
> In netpoll tx path, we miss the chance of calling ->ndo_select_queue(),
> thus could cause problems when bonding is involved.
>
> This patch makes dev_pick_tx() extern (and rename it to netdev_pick_tx())
> to let netpoll call it in netpoll_send_skb_on_dev().
>
> Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Cong Wang <amwang@redhat.com>
> Tested-by: Sylvain Munaut <s.munaut@whatever-company.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] mlx4: use dev_kfree_skb() instead of dev_kfree_skb_any()
From: Ying Cai @ 2012-09-19 21:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Yevgeny Petrilin, David Miller, netdev, Or Gerlitz
In-Reply-To: <1348056777.26523.750.camel@edumazet-glaptop>
Hi Yevgeny,
It seems all the TxQs are sharing the same interrupt for Tx
completions. Will it be better to have separate interrupt per
num_tx_rings_p_up (8) queues? E.g. for a 16 core system, with 16 * 8
Tx queues, to have 16 interrupts for Tx completions of those 128 Tx
queues?
Also I'm looking at mlx4_en_select_queue(), it is using
__skb_tx_hash(). Use something to achieve XPS may bring better
performances.
Thanks.
On Wed, Sep 19, 2012 at 5:12 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> On Wed, 2012-09-19 at 07:58 +0000, Yevgeny Petrilin wrote:
> > >
> > > Since commit e22979d96a5 (mlx4_en: Moving to Interrupts for TX
> > > completions), we no longer can free TX skb from hard IRQ, but only
> > > from
> > > normal softirq or process context.
> > >
> > > Therefore, we can directly call dev_kfree_skb() from
> > > mlx4_en_free_tx_desc() like other conventional NAPI drivers.
> > >
> >
> > Hi Eric,
> > At the moment the TX completion processing is done from IRQ context.
> > So I think we need to change the driver to work with NAPI for TX
> > completions
> > before making this change.
> >
> > I'll send the patch in a few days.
>
> Oops you're right, it seems I misread e22979d96 commit.
>
> irq term is a bit generic, you might add soft/hard qualifiers to
> distinguish the variant.
>
> Thanks
>
>
^ permalink raw reply
* Re: [PATCH] asix: Support DLink DUB-E100 H/W Ver C1
From: David Miller @ 2012-09-19 21:21 UTC (permalink / raw)
To: sgh; +Cc: netdev, stable
In-Reply-To: <1347954657-8975-1-git-send-email-sgh@sgh.dk>
From: Søren Holm <sgh@sgh.dk>
Date: Tue, 18 Sep 2012 09:50:57 +0200
> Signed-off-by: Søren Holm <sgh@sgh.dk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v4 net-next 0/4] ipv6: fix the reassembly expire code in nf_conntrack
From: David Miller @ 2012-09-19 21:28 UTC (permalink / raw)
To: amwang; +Cc: netdev, netfilter-devel, herbert, pablo
In-Reply-To: <1348023011-16195-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Wed, 19 Sep 2012 10:50:07 +0800
> V4: some coding style fix
>
> V3: rename struct netns_nf_ct to struct netns_nf_frag
>
> V2: use IS_ENABLED(CONFIG_IPV6) to fix a build error
> rebase to latest net-next
>
> ipv6: add a new namespace for nf_conntrack_reasm
> ipv6: unify conntrack reassembly expire code with standard one
> ipv6: make ip6_frag_nqueues() and ip6_frag_mem() static
> ipv6: unify fragment thresh handling code
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Pablo Neira Ayuso <pablo@netfilter.org>
> Signed-off-by: Cong Wang <amwang@redhat.com>
All applied to net-next, thanks.
^ 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