Tested the same case with 4.4-RC1, it was fixed in 4.4-RC1.
But don't know which commit fixed it.
# echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
# cat /proc/sys/net/ipv4/ip_local_port_range
102465535
# echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
# cat /proc/sys/net/ipv4/tcp_tw_re
On 11/13/2015 05:20 PM, Jason Wang wrote:
>
> On 11/12/2015 08:02 PM, Felipe Franciosi wrote:
>> Hi Jason,
>>
>> I understand your busy loop timeout is quite conservative at 50us. Did you
>> try any other values?
> I've also tried 20us. And results shows 50us was better in:
>
> - very small pack
On Mon, 2015-11-16 at 21:02 -0800, Tom Herbert wrote:
> It's really hard to tell what is happening without seeing the full
> patch your using. Maybe you're not setting the TCP correctly or
> transport header is not set right in skb.
BTW, using trafgen from netsniff-ng would save you Ben lots of
h
On 11/16/2015 11:00 PM, Michael S. Tsirkin wrote:
> commit 5d9a07b0de512b77bf28d2401e5fe3351f00a240 ("vhost: relax used
> address alignment") fixed the alignment for the used virtual address,
> but not for the physical address used for logging.
>
> That's a mistake: alignment should clearly be th
On Mon, Nov 16, 2015 at 4:20 PM, Ben Greear wrote:
> Hello!
>
> I'm hacking on (my already hacked) pktgen, trying to get it to send TCP
> frames.
>
> And, having issues getting checksums to work properly.
>
> I'm trying this:
> struct iphdr *iph = ip_hdr(skb);
> struct net_device *
On 11/16/2015 8:41 PM, Alexei Starovoitov wrote:
On Mon, Nov 16, 2015 at 08:37:11PM -0800, Z Lim wrote:
On Mon, Nov 16, 2015 at 2:35 PM, Yang Shi wrote:
Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
in prologue in order to get the correct stack backtrace.
...
CC: Zi
On Mon, Nov 16, 2015 at 08:37:11PM -0800, Z Lim wrote:
> On Mon, Nov 16, 2015 at 2:35 PM, Yang Shi wrote:
> > Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> > in prologue in order to get the correct stack backtrace.
...
> > CC: Zi Shen Lim
> > CC: Xi Wang
> > Signed-of
On Mon, Nov 16, 2015 at 2:35 PM, Yang Shi wrote:
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
> change during function call so it may
On Mon, Nov 16, 2015 at 11:25 PM, Hannes Frederic Sowa
wrote:
> Have a look at __dev_queue_xmit and the per_cpu recursion limits
> implemented there:
>
> if (__this_cpu_read(xmit_recursion) >
> RECURSION_LIMIT)
> goto
On Wed, Oct 21, 2015 at 08:57:34PM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, May 27, 2015 at 12:03:12AM +0200, Marek Marczykowski-Górecki wrote:
> > On Tue, May 26, 2015 at 11:56:00AM +0100, David Vrabel wrote:
> > > On 22/05/15 12:49, Marek Marczykowski-Górecki wrote:
> > > > Hi all,
> >
Hi Eric,
On Mon, Nov 16, 2015 at 11:28 PM, Eric Dumazet wrote:
> There is very little chance we'll accept a new member in sk_buff, unless
> proven needed.
I actually have no intention of doing this! I'm wondering if there
already is a member in sk_buff that moonlights as my desired ttl
counter,
Hi all
Back in March/April 2013 I instigated this thread in connection with what
appeared to be a regression in the r8169 driver. To briefly recap, we have
external hardware which transfers data at moderate rates (150-300 Mbits/sec)
to a Linux system using UDP packets. The transfer stream lasts
From: Paul Gortmaker
Date: Mon, 16 Nov 2015 20:45:25 -0500
> Just a heads up that this breaks all arm64 builds in linux-next from
> Monday; bisect says:
>
> 00fd38d938db3f1ab1c486549afc450cb7e751b1 is the first bad commit
> commit 00fd38d938db3f1ab1c486549afc450cb7e751b1
> Author: Eric Dumazet
>
On Sun, Nov 15, 2015 at 6:37 PM, David Miller wrote:
> From: Eric Dumazet
> Date: Thu, 12 Nov 2015 08:43:18 -0800
>
>> From: Eric Dumazet
>>
>> Some functions access TCP sockets without holding a lock and
>> might output non consistent data, depending on compiler and or
>> architecture.
>>
>> tc
Hello!
I'm hacking on (my already hacked) pktgen, trying to get it to send TCP frames.
And, having issues getting checksums to work properly.
I'm trying this:
struct iphdr *iph = ip_hdr(skb);
struct net_device *odev = pkt_dev->odev;
if (pkt_dev->flags & F_TCP) {
On Tue, Nov 17, 2015 at 12:57 AM, Jason A. Donenfeld wrote:
> 2. irq_fpu_usable() is FALSE for UDP! Since in_interrupt() is always
> true in ndo_start_xmit, this means that in this case, both
> interrupted_user_mode() and interrupted_kernel_fpu_idle() are false!
> Investigating further, will repor
Hi Hannes,
Thanks for your response.
On Mon, Nov 16, 2015 at 11:27 PM, Hannes Frederic Sowa
wrote:
> Use the irqsoff tracer to find the problematic functions which disable
> interrupts and try to work around it in case of UDP. This could benefit
> the whole stack.
I didn't know about the irqsof
Ondrej Zary :
[...]
> diff --git a/drivers/net/ethernet/dlink/dl2k.c
> b/drivers/net/ethernet/dlink/dl2k.c
> index ccca479..23d13c5 100644
> --- a/drivers/net/ethernet/dlink/dl2k.c
> +++ b/drivers/net/ethernet/dlink/dl2k.c
[..]
> @@ -522,6 +515,28 @@ rio_open (struct net_device *dev)
> macc
Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
in prologue in order to get the correct stack backtrace.
However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
change during function call so it may cause the BPF prog stack base address
change too.
Use x25
Add suspend/resume support to dl2k driver.
Tested on Asus NX1101 (IP1000A) and D-Link DGE-550T (DL-2000).
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/dlink/dl2k.c | 189 +
1 file changed, 128 insertions(+), 61 deletions(-)
diff --git a/drivers/net/et
On Mon, 2015-11-16 at 14:30 -0800, Eric Dumazet wrote:
> On Mon, 2015-11-16 at 23:18 +0100, Hannes Frederic Sowa wrote:
> > > need something that handles all cases properly.
> >
> > I just wanted to shut up the gcc warning which is added if a function
> > uses more than 2048 bytes of stack space.
The NOLINK state will poll the phy once a second to see if the link
has come up. If the phy has an interrupt line, this polling can be
skipped, since the phy should interrupt when the link returns.
Signed-off-by: Andrew Lunn
---
drivers/net/phy/phy.c | 3 +++
1 file changed, 3 insertions(+)
dif
The 88E1540 can be found embedded in the Marvell 88E6352 switch. It
is compatible with the 88E1510, so add support for it, using the
88E1510 specific functions.
Signed-off-by: Andrew Lunn
---
drivers/net/phy/marvell.c | 16
include/linux/marvell_phy.h | 1 +
2 files changed,
On Mon, 2015-11-16 at 23:18 +0100, Hannes Frederic Sowa wrote:
> > need something that handles all cases properly.
>
> I just wanted to shut up the gcc warning which is added if a function
> uses more than 2048 bytes of stack space. We normally don't have the
> problem and could also divide the fu
On Mon, 2015-11-16 at 21:55 +0100, Jason A. Donenfeld wrote:
> Hi Sowmini,
>
> Neat. Though, in my case, I'm not actually just prepending a header.
> I'm doing some more substantial transformations of a packet. And this
> needs to work with v4 too. So I'm not sure implementing a v6 spec will
> hel
An AF_UNIX datagram socket being the client in an n:1 association with
some server socket is only allowed to send messages to the server if the
receive queue of this socket contains at most sk_max_ack_backlog
datagrams. This implies that prospective writers might be forced to go
to sleep despite no
Hi Jason,
On Mon, Nov 16, 2015, at 21:58, Jason A. Donenfeld wrote:
> Hi David,
>
> On Mon, Nov 16, 2015 at 9:32 PM, David Miller
> wrote:
> > Network device driver transmit executes with software interrupts
> > disabled.
> >
> > Therefore on x86, you cannot use the FPU.
>
> That is extremely p
Hi Jason,
On Mon, Nov 16, 2015, at 21:14, Jason A. Donenfeld wrote:
> A few tunnel devices, like geneve or vxlan, are using
> udp_tunnel_xmit_skb, or related functions for transmitting packets,
> and are doing the usual FIB lookup to get the dst entry. I see a lot
> of code like this:
>
>
Hi,
On Mon, Nov 16, 2015, at 21:38, David Miller wrote:
> From: Hannes Frederic Sowa
> Date: Mon, 16 Nov 2015 12:05:03 +0100
>
> > By declaring the huge stack allocations as static. We can do so
> > because we hold rtnl.
>
> Look across the tree, this is an idiom copied all over the place.
> If
An AF_UNIX datagram socket being the client in an n:1 association with
some server socket is only allowed to send messages to the server if the
receive queue of this socket contains at most sk_max_ack_backlog
datagrams. This implies that prospective writers might be forced to go
to sleep despite no
From: Ondrej Zary
Date: Sun, 15 Nov 2015 22:36:12 +0100
> Now that IP1000A chips are supported by dl2k driver, the buggy ipg
> driver can be removed.
>
> Signed-off-by: Ondrej Zary
Also applied, thanks again.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
From: Ondrej Zary
Date: Sun, 15 Nov 2015 22:36:11 +0100
> Add support for IP1000A chips to dl2k driver.
> IP1000A chip looks like a TC9020 with integrated PHY.
>
> This allows IP1000A chips to work reliably because the ipg driver is
> buggy - it loses packets under load and then completely stops
From: Sabrina Dubroca
Date: Mon, 16 Nov 2015 22:54:20 +0100
> Reset pskb in macvlan_handle_frame in case skb_share_check returned a
> clone.
>
> Fixes: 8a4eb5734e8d ("net: introduce rx_handler results and logic around
> that")
> Signed-off-by: Sabrina Dubroca
Thanks for finding all of these b
Reset pskb in macvlan_handle_frame in case skb_share_check returned a
clone.
Fixes: 8a4eb5734e8d ("net: introduce rx_handler results and logic around that")
Signed-off-by: Sabrina Dubroca
---
drivers/net/macvlan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/macvlan.c b/driv
ipvlan_handle_frame is a rx_handler, and when it returns a value other
than RX_HANDLER_CONSUMED (here, NET_RX_DROP aka RX_HANDLER_ANOTHER),
__netif_receive_skb_core expects that the skb still exists and will
process it further, but we just freed it.
Fixes: 2ad7bf363841 ("ipvlan: Initial check-in o
On Mon, Nov 16, 2015 at 10:33 PM, David Miller wrote:
> Someone already did a Linux implemenation of exactly that two decades
> ago, we rejected that design and did what we did.
It's not exactly IPSec though, so don't worry. It's a totally new
thing that combines a lot of different recent ideas,
From: Neil Horman
Date: Mon, 16 Nov 2015 13:09:10 -0500
> the OUTMCAST stat is double incremented, getting bumped once in the mcast code
> itself, and again in the common ip output path. Remove the mcast bump, as its
> not needed
>
> Validated by the reporter, with good results
>
> Signed-off-
Pass a **skb to ipvlan_rcv_frame so that if skb_share_check returns a
new skb, we actually use it during further processing.
It's safe to ignore the new skb in the ipvlan_xmit_* functions, because
they call ipvlan_rcv_frame with local == true, so that dev_forward_skb
is called and always takes own
From: "Jason A. Donenfeld"
Date: Mon, 16 Nov 2015 22:28:52 +0100
> I'm making a simpler replacement for IPSec that operates as an
> device driver on the interface level
Someone already did a Linux implemenation of exactly that two decades
ago, we rejected that design and did what we did.
--
To u
On Mon, Nov 16, 2015 at 10:17 PM, David Miller wrote:
>
> Not without a complete redesign of the x86 fpu save/restore mechanism.
Urg, okay. I still wonder why irq_fpu_usable() is true when using TCP but not
when using UDP... Any ideas on this?
> The driver is the wrong place to do software crypt
From: Pavel Fedin
Date: Mon, 16 Nov 2015 17:51:34 +0300
> In some cases the crash is caused by nicvf_remove() being called from
> outside. For example, if we try to feed the device to vfio after the
> probe has failed for some reason. So, move the check to better place.
>
> Signed-off-by: Pavel
From: Bjørn Mork
Date: Mon, 16 Nov 2015 19:16:40 +0100
> A recent flaw in the netdev feature setting resulted in warnings
> like this one from VLAN interfaces:
>
> WARNING: CPU: 1 PID: 4975 at net/core/dev.c:2419
> skb_warn_bad_offload+0xbc/0xcb()
> : caps=(0x001b5820, 0x001b5
David Miller writes:
> From: Måns Rullgård
> Date: Mon, 16 Nov 2015 20:59:18 +
>
>> Anything else?
>
> Sorry, when I find one problem I give you the feedback for that
> and move on to the 100s of other patches I have in my queue.
Some people prefer to comment on more than one issue, if pres
On Mon, 16 Nov 2015, David Miller wrote:
> From: Shrikrishna Khare
> Date: Fri, 13 Nov 2015 15:42:10 -0800
>
> > Signed-off-by: Shrikrishna Khare
> > Reported-by: Masao Uebayashi
> > Signed-off-by: Bhavesh Davda
>
> You guys really have to stop targetting simple, straightforward,
> bug fixe
From: Måns Rullgård
Date: Mon, 16 Nov 2015 20:59:18 +
> Anything else?
Sorry, when I find one problem I give you the feedback for that
and move on to the 100s of other patches I have in my queue.
Or would you like me to devote all of my time to just your driver
instead of taking everyone's
From: "Jason A. Donenfeld"
Date: Mon, 16 Nov 2015 21:58:49 +0100
> That is extremely problematic for me. Is there a way to make this
> not so?
Not without a complete redesign of the x86 fpu save/restore mechanism.
The driver is the wrong place to do software cryptographic transforms
anyways.
J
> Neat. Though, in my case, I'm not actually just prepending a header.
> I'm doing some more substantial transformations of a packet. And this
> needs to work with v4 too. So I'm not sure implementing a v6 spec will
Understood, that spec was just referenced to indicate that there
are more issues (
David Miller writes:
> From: Mans Rullgard
> Date: Mon, 16 Nov 2015 18:23:35 +
>
>> +static int nb8800_alloc_rx(struct net_device *dev, int i, bool napi)
>
> "i" is passed in as a signed int here, but:
>
>> +static void nb8800_receive(struct net_device *dev, unsigned i, unsigned len)
> ...
Hi David,
On Mon, Nov 16, 2015 at 9:32 PM, David Miller wrote:
> Network device driver transmit executes with software interrupts
> disabled.
>
> Therefore on x86, you cannot use the FPU.
That is extremely problematic for me. Is there a way to make this not
so? A driver flag that would allow thi
Hi Sowmini,
Neat. Though, in my case, I'm not actually just prepending a header.
I'm doing some more substantial transformations of a packet. And this
needs to work with v4 too. So I'm not sure implementing a v6 spec will
help with things. I need to identify the right mechanism inside the
kernel t
From: Mans Rullgard
Date: Mon, 16 Nov 2015 18:23:35 +
> +static int nb8800_alloc_rx(struct net_device *dev, int i, bool napi)
"i" is passed in as a signed int here, but:
> +static void nb8800_receive(struct net_device *dev, unsigned i, unsigned len)
...
> + err = nb8800_alloc_r
When a vlan is configured with REORDER_HEADER set to 0, the vlan
header is put back into the packet and makes it appear that
the vlan header is still there even after it's been processed.
This posses a problem for bridge and macvlan ports. The packets
passed to those device may be forwarded and at
A while ago Phil Sutter brought up an issue with vlans without
REORDER_HEADER and bridges. The problem was that if a vlan
without REORDER_HEADER was a port in the bridge, the bridge ended
up forwarding corrupted packets that still contained the vlan header.
The same issue exists for bridge mode ma
When we have multiple stacked vlan devices all of which have
turned off REORDER_HEADER flag, the untag operation does not
locate the ethernet addresses correctly for nested vlans.
The reason is that in case of REORDER_HEADER flag being off,
the outer vlan headers are put back and the mac_len is adj
From: Hannes Frederic Sowa
Date: Mon, 16 Nov 2015 16:25:56 +0100
> In case multiple writes to a unix stream socket race we could end up in a
> situation where we pre-allocate a new skb for use in unix_stream_sendpage
> but have to free it again in the locked section because another skb
> has been
From: Hannes Frederic Sowa
Date: Mon, 16 Nov 2015 12:05:03 +0100
> By declaring the huge stack allocations as static. We can do so
> because we hold rtnl.
Look across the tree, this is an idiom copied all over the place.
If putting a rtnl_link_stats64 object on the stack is truly a
problem, we h
On (11/16/15 21:14), Jason A. Donenfeld wrote:
>
> But what about in devices for which self-routing might actually be
> useful? For example, let's say that if an incoming skb is headed for
> dst X, it gets encapsulated and sent to dst A, and for dst Y it gets
> encapsulated and sent to dst B, and
From: "Jason A. Donenfeld"
Date: Mon, 16 Nov 2015 20:52:28 +0100
> This works fine with, say, iperf3 in TCP mode. The AVX performance
> is great. However, when using iperf3 in UDP mode, irq_fpu_usable()
> is mostly false! I added a dump_stack() call to see why, except
> nothing looks strange; the
From: Rajesh Borundia
Date: Mon, 16 Nov 2015 05:58:47 -0500
> + } else {
> + if (atomic_read(&mbx->rsp_status) != rsp_status)
> + qlcnic_83xx_notify_mbx_response(mbx);
Here we go with more of some "We don't understand what atomic_t's
actually do"...
atomic_re
From: Dragos Tatulea
Date: Mon, 16 Nov 2015 10:52:48 +0100
> rtnl_fdb_dump always expects an index to be returned by the ndo_fdb_dump op,
> but when CONFIG_NET_SWITCHDEV is off, it returns an error.
>
> Fix that by returning the given unmodified idx.
>
> A similar fix was 0890cf6cb6ab ("switchd
Hi folks,
A few tunnel devices, like geneve or vxlan, are using
udp_tunnel_xmit_skb, or related functions for transmitting packets,
and are doing the usual FIB lookup to get the dst entry. I see a lot
of code like this:
if (rt->dst.dev == dev) {
netdev_dbg(
From: Yuval Mintz
Date: Sun, 15 Nov 2015 15:02:16 +0200
> Commit 05cc5a39ddb7 "bnx2x: add vlan filtering offload" introduced
> a regression in regard for vlans for 57710, 57711 adapters -
> Loading 8021q module on a machine with such an adapter would cause
> a null pointer dereference, as the dri
I'm starting to grow quite weary of these "unnecessary check" changes.
Sometimes it is better to have them, either because the path is a hot
path or some atomic sequence is involved.
But there is never harm in them being there.
All of this is a matter of taste, of course. But one thing I know
From: Yoshihiro Kaneko
Date: Sun, 15 Nov 2015 21:34:42 +0900
> From: Masaru Nagai
>
> This driver does not handle the AVB-DMAC Receive FIFO Warning interrupt
> now, so the interrupt should not be enabled.
>
> Signed-off-by: Masaru Nagai
> Signed-off-by: Yoshihiro Kaneko
Applied, thanks.
--
On 16/11/15 12:05, Adrian Chadd wrote:
> On 16 November 2015 at 11:48, Florian Fainelli wrote:
>> On 16/11/15 11:29, Adrian Chadd wrote:
>>> hi,
>>>
>>> I'm debugging an issue on the Broadcom parts (using unimac-mdio.c as
>>> the mdio bus) where i occasionally see MDIO bus read failures, which
>>>
From: Ben Cartwright-Cox
Date: Sat, 14 Nov 2015 15:13:58 +
> Sending ICMP packets with raw sockets ends up in the SNMP counters
> logging the type as the first byte of the IPv4 header rather than
> the ICMP header. This is fixed by adding the IP Header Length to
> the casting into a icmphdr s
From: Julia Lawall
Date: Sat, 14 Nov 2015 11:06:53 +0100
> This pci_error_handlers structure is never modified, like all the other
> pci_error_handlers structures, so declare it as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Applied.
--
To unsubscribe from thi
From: Julia Lawall
Date: Sat, 14 Nov 2015 11:06:57 +0100
> This pci_error_handlers structure is never modified, like all the other
> pci_error_handlers structures, so declare it as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Applied.
--
To unsubscribe from thi
From: Shrikrishna Khare
Date: Fri, 13 Nov 2015 15:42:10 -0800
> Signed-off-by: Shrikrishna Khare
> Reported-by: Masao Uebayashi
> Signed-off-by: Bhavesh Davda
You guys really have to stop targetting simple, straightforward,
bug fixes at net-next. That is not appropriate.
Bug fixes should ta
On 16 November 2015 at 11:48, Florian Fainelli wrote:
> On 16/11/15 11:29, Adrian Chadd wrote:
>> hi,
>>
>> I'm debugging an issue on the Broadcom parts (using unimac-mdio.c as
>> the mdio bus) where i occasionally see MDIO bus read failures, which
>> causes phy.c to transition the PHY to PHY_HALT
From: Daniele Palmas
Date: Fri, 13 Nov 2015 18:01:21 +0100
> Since Dell DW5580 is a 3G modem, this patch adds the device as a
> mobile broadband adapter
>
> Signed-off-by: Daniele Palmas
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to m
From: Nikolay Aleksandrov
Date: Fri, 13 Nov 2015 15:20:24 +0100
> From: Nikolay Aleksandrov
>
> If ndo_set_features fails __netdev_update_features() will return -1 but
> this is wrong because it is expected to return 0 if no features were
> changed (see netdev_update_features()), which will cau
From: Nikolay Aleksandrov
Date: Fri, 13 Nov 2015 14:54:01 +0100
> From: Nikolay Aleksandrov
>
> When __netdev_update_features() was updated to ensure some features are
> disabled on new lower devices, an error was introduced for devices which
> don't have the ndo_set_features() method set. Befo
From: Ido Schimmel
Date: Fri, 13 Nov 2015 13:06:12 +0200
> When NET_SWITCHDEV=n, switchdev_port_attr_set simply returns EOPNOTSUPP.
> In this case we should not emit errors and warnings to the kernel log.
>
> Reported-by: Sander Eikelenboom
> Fixes: 0bc05d585d38 ("switchdev: allow caller to exp
Hi David & Folks,
I have a virtual device driver that does some fancy processing of
packets in ndo_start_xmit before forwarding them onward out of a
tunnel elsewhere. In order to make that fancy processing fast, I have
AVX and AVX2 implementations. This means I need to use the FPU.
So, I do the u
On 16/11/15 11:29, Adrian Chadd wrote:
> hi,
>
> I'm debugging an issue on the Broadcom parts (using unimac-mdio.c as
> the mdio bus) where i occasionally see MDIO bus read failures, which
> causes phy.c to transition the PHY to PHY_HALTED. It stays in this
> state until the link is bounced.
Ther
On 11/13/2015 6:39 PM, Z Lim wrote:
Yang, I noticed another thing...
On Fri, Nov 13, 2015 at 10:09 AM, Yang Shi wrote:
Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
in prologue in order to get the correct stack backtrace.
However, ARM64 JIT used FP (x29) as eBPF fp r
From: Ivan Vecera
Date: Fri, 13 Nov 2015 11:36:57 +0100
> Remove rsstable array and its initialization from be_set_rss_hash_opts().
> The array became unused after "e255787 be2net: Support for configurable
> RSS hash key". The initial RSS table is now filled and stored for later
> usage during Rx
From: Ivan Vecera
Date: Fri, 13 Nov 2015 11:36:58 +0100
> Signed-off-by: Ivan Vecera
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Yoshihiro Kaneko
Date: Fri, 13 Nov 2015 19:24:49 +0900
> From: Masaru Nagai
>
> When RX/TX interrupt for Network Control queue and Best Effort queue
> is issued at the same time, the interrupt mask of Network Control
> queue will be reset when the mask of Best Effort queue is set.
> This
From: Pavel Fedin
Date: Fri, 13 Nov 2015 09:46:59 +0300
> On certain hardware after software reboot the chip may get stuck and fail
> to reinitialize during reset. This can be fixed by ensuring that PHY is
> reset too.
>
> Old PHY resetting method required operational MDIO interface, therefore
>
From: Daniel Borkmann
Date: Sat, 14 Nov 2015 01:26:53 +0100
> During review I noticed that the icache range we're flushing should
> start at header already and not at ctx.image.
>
> Reason is that after 55309dd3d4cd ("net: bpf: arm: address randomize
> and write protect JIT code"), we also want
From: Yang Shi
Date: Thu, 12 Nov 2015 14:07:46 -0800
> commit 338d4f49d6f7114a017d294ccf7374df4f998edc
> ("arm64: kernel: Add support for Privileged Access Never") includes sysreg.h
> into futex.h and uaccess.h. But, the inline assembly used by asm/sysreg.h is
> incompatible with llvm so it will
From: Yang Shi
Date: Thu, 12 Nov 2015 13:57:00 -0800
> BPF fp should point to the top of the BPF prog stack. The original
> implementation made it point to the bottom incorrectly.
> Move A64_SP to fp before reserve BPF prog stack space.
>
> CC: Zi Shen Lim
> CC: Xi Wang
> Signed-off-by: Yang S
On Mon, Nov 16, 2015 at 8:17 PM, David Miller wrote:
> So another fix could have been to do local_bh_disable() in the
> udp_tunnel6_xmit_skb() helper.
This would have fixed one problem, but everywhere
udp_tunnel_xmit_skb() (4, not 6) is called, iptunnel_xmit_stats is
called right after it, so the
hi,
I'm debugging an issue on the Broadcom parts (using unimac-mdio.c as
the mdio bus) where i occasionally see MDIO bus read failures, which
causes phy.c to transition the PHY to PHY_HALTED. It stays in this
state until the link is bounced.
So, what's the expectation to handle this and recover f
From: Mans Rullgard
Date: Thu, 12 Nov 2015 17:40:20 +
> Commit 77a993942 "phy/at8031: enable at8031 to work on interrupt mode"
> added interrupt support for the 8031 PHY but left out the other two
> chips supported by this driver.
>
> This patch sets the .ack_interrupt and .config_intr funct
From: Mans Rullgard
Date: Thu, 12 Nov 2015 18:41:12 +
> This adds support for the Vitesse VSC8601 PHY. Generic functions are
> used for everything except interrupt handling.
>
> Signed-off-by: Mans Rullgard
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
th
From: "Jason A. Donenfeld"
Date: Thu, 12 Nov 2015 17:35:58 +0100
> Drivers like vxlan use the recently introduced
> udp_tunnel_xmit_skb/udp_tunnel6_xmit_skb APIs. udp_tunnel6_xmit_skb
> makes use of ip6tunnel_xmit, and ip6tunnel_xmit, after sending the
> packet, updates the struct stats using the
On Sun, Nov 15, 2015 at 04:54:57PM +0300, Vladimir Davydov wrote:
> On Thu, Nov 12, 2015 at 06:41:33PM -0500, Johannes Weiner wrote:
> > Let the networking stack know when a memcg is under reclaim pressure
> > so that it can clamp its transmit windows accordingly.
> >
> > Whenever the reclaim effi
This adds a driver for the Aurora VLSI NB8800 Ethernet controller.
It is an almost complete rewrite of a driver originally found in
a Sigma Designs 2.6.22 tree.
Signed-off-by: Mans Rullgard
---
Changes:
- Use napi_gro_receive()
- Ignore xmit_more if using last tx descriptor
- Perform tx cleanup f
On Mon, Nov 16, 2015 at 04:59:25PM +0100, Michal Hocko wrote:
> On Thu 12-11-15 18:41:32, Johannes Weiner wrote:
> > Socket memory can be a significant share of overall memory consumed by
> > common workloads. In order to provide reasonable resource isolation in
> > the unified hierarchy, this type
A recent flaw in the netdev feature setting resulted in warnings
like this one from VLAN interfaces:
WARNING: CPU: 1 PID: 4975 at net/core/dev.c:2419
skb_warn_bad_offload+0xbc/0xcb()
: caps=(0x001b5820, 0x001b5829) len=2782 data_len=0
gso_size=1348 gso_type=16 ip_summed=3
The
the OUTMCAST stat is double incremented, getting bumped once in the mcast code
itself, and again in the common ip output path. Remove the mcast bump, as its
not needed
Validated by the reporter, with good results
Signed-off-by: Neil Horman
Reported-by: Claus Jensen
CC: Claus Jensen
CC: David
On Fri, 2015-10-09 at 19:33 +0200, Daniel Borkmann wrote:
> On 10/09/2015 04:35 AM, Alexei Starovoitov wrote:
> > On 10/8/15 5:50 PM, Devon H. O'Dell wrote:
> >>> with the amount of skb_sender_cpu_clear() all over the code base
> >>> >I wonder whether there is a better solution to all of these.
> >
Hello Eric
2015-11-12, 09:26:42 -0800, Eric Dumazet wrote:
> Note that the following patch (and corresponding part for ipv6) might
> also have solve the issue ?
>
> This would supposedly save some cycles when MSG_PEEK is used and user
> provides short buffers.
Your patch looks correct to me, fee
On Sat, Nov 14, 2015 at 07:33:10PM +0300, Vladimir Davydov wrote:
> On Thu, Nov 12, 2015 at 06:41:24PM -0500, Johannes Weiner wrote:
> > Move the jump-label from sock_update_memcg() and sock_release_memcg()
> > to the callsite, and so eliminate those function calls when socket
> > accounting is not
** CID 1056375: Error handling issues (CHECKED_RETURN)
/drivers/net/ethernet/mellanox/mlx5/core/cq.c: 133 in mlx5_core_create_cq()
*** CID 1056375: Error handling issues (CHECKED_RETURN)
/
On 16/11/2015 07:07, Eric Dumazet wrote:
On Sun, 2015-11-15 at 16:58 -0800, Grant Zhang wrote:
Hi Patrick,
Have you tried the two patches Eric mentioned? One of my 4.1.11 server
just hanged with very similar stack trace and I am wondering whether the
aforementioned patches would help.
Thanks,
On Mon, 2015-11-16 at 16:25 +0100, Hannes Frederic Sowa wrote:
> In case multiple writes to a unix stream socket race we could end up in a
> situation where we pre-allocate a new skb for use in unix_stream_sendpage
> but have to free it again in the locked section because another skb
> has been app
1 - 100 of 148 matches
Mail list logo
