Re: [GIT] Networking

On Fri, Nov 6, 2015 at 7:27 AM, David Laight wrote: >> From: Linus Torvalds >> Sent: 03 November 2015 20:45 >> On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds >> wrote: >> > result = add_overflow( >> > mul_overflow(sec,

[PATCH net] bonding: fix panic on non-ARPHRD_ETHER enslave failure

Since commit 7d5cd2ce529b, when bond_enslave fails on devices that are not ARPHRD_ETHER, if needed, it resets the bonding device back to ARPHRD_ETHER by calling ether_setup. Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP if the bond device is up, leaving it in a

Re: [PATCH v4 3/4] Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping

Richard/Thomas: On Tue, 13 Oct 2015 06:59:26 -0700, Richard Cochran wrote: On Mon, Oct 12, 2015 at 11:45:21AM -0700, Christopher S. Hall wrote: +struct ptp_sys_offset_precise { + unsigned int rsv[4];/* Reserved for future use. */ + struct

[RFC PATCH net-next v2 5/8] openvswitch: Find existing conntrack entry after upcall.

Add a new function ovs_ct_find_existing() to find an existing conntrack entry for which this packet was already applied to. This is only to be called when there is evidence that the packet was already tracked and committed, but we lost the ct reference due to an userspace upcall.

[RFC PATCH net-next v2 8/8] openvswitch: Interface with NAT.

Extend OVS conntrack interface to cover NAT. New nested OVS_CT_ATTR_NAT attribute may be used to include NAT with a CT action. A bare OVS_CT_ATTR_NAT only mangles existing and expected connections. If OVS_NAT_ATTR_SRC or OVS_NAT_ATTR_DST is included within the nested attributes, new

[RFC PATCH net-next v2 0/8] openvswitch: NAT support.

This series adds NAT support to openvswitch kernel module. A few changes are needed to the netfilter code to facilitate this (patches 1-3/8). Patches 4-7 make the openvswitch kernel module ready for the patch 8 that adds the NAT support for calling into netfilter NAT code from the openvswitch

[RFC PATCH net-next v2 1/8] netfilter: Remove IP_CT_NEW_REPLY definition.

Remove the definition of IP_CT_NEW_REPLY from the kernel as it does not make sense. This allows the definition of IP_CT_NUMBER to be simplified as well. Signed-off-by: Jarno Rajahalme --- include/uapi/linux/netfilter/nf_conntrack_common.h | 12 +---

[RFC PATCH net-next v2 7/8] openvswitch: Delay conntrack helper call for new connections.

There is no need to help connections that are not confirmed, so we can delay helping new connections to the time when they are confirmed. This change is needed for NAT support, and having this as a separate patch will make the following NAT patch a bit easier to review. Signed-off-by: Jarno

[RFC PATCH net-next v2 3/8] netfilter: Allow calling into nat helper without skb_dst.

NAT checksum recalculation code assumes existence of skb_dst, which becomes a problem for a later patch in the series ("openvswitch: Interface with NAT."). Simplify this by removing the check on skb_dst, as the checksum will be dealt with later in the stack. Suggested-by: Pravin Shelar

[RFC PATCH net-next v2 6/8] openvswitch: Handle NF_REPEAT in conntrack action.

Repeat the nf_conntrack_in() call when it returns NF_REPEAT. This avoids dropping a SYN packet re-opening an existing TCP connection. Signed-off-by: Jarno Rajahalme --- net/openvswitch/conntrack.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff

[RFC PATCH net-next v2 4/8] openvswitch: Update the CT state key only after nf_conntrack_in().

Only a successful nf_conntrack_in() call can effect a connection state change, so if suffices to update the key only after the nf_conntrack_in() returns. This change is needed for the later NAT patches. Signed-off-by: Jarno Rajahalme --- net/openvswitch/conntrack.c | 9

[RFC PATCH net-next v2 2/8] netfilter: Factor out nf_ct_get_info().

Define a new inline function to map conntrack status to enum ip_conntrack_info. This removes the need to otherwise duplicate this code in a later patch ("openvswitch: Find existing conntrack entry after upcall."). Signed-off-by: Jarno Rajahalme ---

Re: Regression in bonding driver - devices without set_mac

Toby Corkindale wrote: [...] >The thing is, I've been running PPP devices in balance-rr mode for >quite a while. It worked fine, and I'd like to continue having that >functionality. These changes to the kernel have broken that >functionality, by requiring the MAC address

Re: Regression in bonding driver - devices without set_mac

Toby Corkindale wrote: >I originally reported this in Dec 2014, as: >https://bugzilla.kernel.org/show_bug.cgi?id=89161 > >The bug is still present in the 4.2 Linux kernel. I had some time to look into this today, and there is a related code path that panics the

Re: [PATCH] inet: delay address promotion check until last request in message

Hello, On Fri, 6 Nov 2015, Neil Horman wrote: > The solution is to recognize that its pointless to promote an address to be a > new primary, if there is a possibility that it will just be removed in the > near > future. As such this patch peeks ahead to the next request in the

Re: [PATCH -next] net: hisilicon: Never build on SPARC

On 11/06/2015 12:30 PM, Arnd Bergmann wrote: On Friday 06 November 2015 11:16:52 Guenter Roeck wrote: On Wed, Oct 21, 2015 at 02:53:20PM -0700, Guenter Roeck wrote: On Wed, Oct 21, 2015 at 09:11:53PM +0200, Arnd Bergmann wrote: On Wednesday 21 October 2015 10:03:05 Guenter Roeck wrote:

Re: [PATCH net] bonding: fix panic on non-ARPHRD_ETHER enslave failure

On 11/07/2015 02:23 AM, Jay Vosburgh wrote: > Since commit 7d5cd2ce529b, when bond_enslave fails on devices that > are not ARPHRD_ETHER, if needed, it resets the bonding device back to > ARPHRD_ETHER by calling ether_setup. > > Unfortunately, ether_setup clobbers dev->flags, clearing

Re: [PATCH net-next] drivers: net: xgene: fix RGMII 10/100Mb mode

From: Iyappan Subramanian Date: Thu, 5 Nov 2015 21:35:06 -0800 > This patch fixes the RGMII 10/100M mode by reprogramming the clock. > > Signed-off-by: Iyappan Subramanian > Tested-by: Fushen Chen Why are you targetting a bug fix at

[PATCH] arm64: bpf: fix JIT stack setup

ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to change during function call so it may cause the BPF prog stack base address change too. Whenever, it pointed to the bottom of BPF prog stack instead of the top. So, when copying data via bpf_probe_read, it will be copied to (SP -

Re: [PATCH] arm64: bpf: fix JIT stack setup

Please ignore this one, forgot to cc to linux-arm-kernel list. Sorry for the inconvenience. Yang On 11/6/2015 9:34 PM, Yang Shi wrote: ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to change during function call so it may cause the BPF prog stack base address change too.

[PATCH] arm64: bpf: fix JIT stack setup

ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to change during function call so it may cause the BPF prog stack base address change too. Whenever, it pointed to the bottom of BPF prog stack instead of the top. So, when copying data via bpf_probe_read, it will be copied to (SP -

[PATCH] bpf: doc: correct arch list for supported eBPF JIT

aarch64 and s390x support eBPF JIT too, correct document to reflect this and avoid any confusion. Signed-off-by: Yang Shi --- Documentation/networking/filter.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/networking/filter.txt

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

From: Michal Hocko Date: Fri, 6 Nov 2015 17:46:57 +0100 > On Fri 06-11-15 11:19:53, Johannes Weiner wrote: >> You might think sending these emails is helpful, but it really >> isn't. Not only is it not contributing code, insights, or solutions, >> you're now actively

Re: Regression in bonding driver - devices without set_mac

On 7 November 2015 at 13:31, Jay Vosburgh wrote: > > Toby Corkindale wrote: > [...] > >The thing is, I've been running PPP devices in balance-rr mode for > >quite a while. It worked fine, and I'd like to continue having that > >functionality.

4.3.0 r8169: "rtl_counters_cond == 1 (loop: 1000, delay: 10)." log spam

related: https://bugzilla.kernel.org/show_bug.cgi?id=107421 https://bugzilla.kernel.org/show_bug.cgi?id=104351 4.3.0 smp x86_64 [4.384336] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [4.384747] r8169 :0e:00.0 eth0: RTL8101e at 0xc906, 00:1b:38:b5:9f:d6, XID 9420

Re: [PATCH] DWC Ethernet QoS: Delete an unnecessary check before the function call "of_node_put"

From: SF Markus Elfring Date: Fri, 6 Nov 2015 08:15:30 +0100 > From: Markus Elfring > Date: Fri, 6 Nov 2015 08:00:22 +0100 > > The of_node_put() function tests whether its argument is NULL and then > returns immediately. Thus the

Re: question about checksumming and tcp_sendpage

On Fri, Nov 6, 2015 at 6:34 AM, ronny.hegew...@online.de wrote: > While reading through net-code i came across some code in tcp_sendpage which > i think > it is not working in the intended way all tie time. But as this code is at > that a > central place and pretty

[PATCH] fjes: Delete an unnecessary check before the function call "vfree"

From: Markus Elfring Date: Fri, 6 Nov 2015 09:30:29 +0100 The vfree() function performs also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: ... > > 3) keep only some (safe) cache types enabled by default with the current > >failing semantic and require an explicit enabling for the complete > >kmem

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu 05-11-15 17:52:00, Johannes Weiner wrote: > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > > > This would be true if they moved on to the new cgroup API intentionally. > > > The reality is more complicated

Re: [PATCH] decnet: remove macro-local declarations

> > Would it be preferable to remove the macro entirely and inline the for > > loop header? > > Could you show me an example of how this would look exactly? One possible solution is below. I moved the initialization of the nh pointer inside the loop to reduce the size of the loop header. One

Re: [PATCH 1/1] commit c6825c0976fa7893692e0e43b09740b419b23c09 upstream.

On Wed, Nov 04, 2015 at 03:46:54PM -0800, Ani Sinha wrote: > (removed a bunch of people from CC list) > > On Mon, Oct 26, 2015 at 1:06 PM, Pablo Neira Ayuso > wrote: > > > Then we can review and, if no major concerns, I can submit this to > > -stable. > > Now that Neal

Re: [PATCH net 4/5] bnxt_en: Fix comparison of u16 sw_id against negative value.

Hello. On 11/6/2015 12:25 AM, Michael Chan wrote: Assign the return value from bitmap_find_free_region() to an integer variable and check for negative error codes first, before assigning the bit ID to the unsigned sw_id field. Reported-by: Dan Carpenter Cc: Dan

Re: [PATCH] [BACKPORT] [3.14.56] bnx2x: Don't notify about scratchpad parities

On Thu, Nov 05, 2015 at 11:18:37AM +0100, Patrick Schaaf wrote: > bnx2x: Don't notify about scratchpad parities > > This is a (trivial) "backport" of ad6afbe9578d1fa26680faf78c846bd8c00d1d6e to > stable kernel 3.14.56. This patch isn't in 4.1 either, do you want it there as well? thanks, greg

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu 05-11-15 17:32:51, Johannes Weiner wrote: > On Thu, Nov 05, 2015 at 05:28:03PM +0100, Michal Hocko wrote: [...] > > Yes, that part is clear and Johannes made it clear that the kmem tcp > > part is disabled by default. Or are you considering also all the slab > > usage by the networking code

[PATCH] net: netfilter: fix GCC uninitialized warning

With x86_64_defconfig: GCC thinks that in nfulnl_recv_config flags parameter is not inited but it was under the same condition (nfula[NFULA_CFG_FLAGS] == true). Suppress this warning: net/netfilter/nfnetlink_log.c: In function ‘nfulnl_recv_config’:

Re: [PATCH] net: netfilter: fix GCC uninitialized warning

On Fri, Nov 06, 2015 at 09:48:14PM +0300, Dmitry Safonov wrote: > With x86_64_defconfig: > GCC thinks that in nfulnl_recv_config flags parameter is not inited but > it was under the same condition (nfula[NFULA_CFG_FLAGS] == true). > Suppress this warning: > net/netfilter/nfnetlink_log.c: In

Re: [netfilter-core] [PATCH] net: netfilter: fix GCC uninitialized warning

Pablo Neira Ayuso wrote: > On Fri, Nov 06, 2015 at 09:48:14PM +0300, Dmitry Safonov wrote: > > With x86_64_defconfig: > > GCC thinks that in nfulnl_recv_config flags parameter is not inited but > > it was under the same condition (nfula[NFULA_CFG_FLAGS] == true). > > Suppress

Re: [RFC PATCH 2/2] net: mvneta: Add naive RSS support

Hi Gregory, 2015-11-06 19:35 GMT+01:00 Gregory CLEMENT : > This patch add the support for the RSS related ethtool > function. Currently it only use one entry in the indirection table which > allows associating an mveneta interface to a given CPU. > >

Re: Aw: Re: question about checksumming and tcp_sendpage

On Fri, 2015-11-06 at 20:14 +0100, ronny.hegew...@online.de wrote: > I think the checksum-building is not broken because of this on itself. The > problem i see is for example in case pages are sent from a block-device > over the net. > > Depending on the block-device this pages might be

Aw: Re: question about checksumming and tcp_sendpage

> Well, looking at the code I don't readily see how this works either, > but note that tcp_sendmsg has the same check also. If your analysis is > correct then checksum for IPv6 would commonly be broken (i.e. several > devices support IPv4 checksum but not IPv6)-- so I find that hard to > believe

Re: [PATCH] net: netfilter: fix GCC uninitialized warning

I thought, it was decided to use 0/NULL/whatever, than uninitialized_var()? Is right now? http://thread.gmane.org/gmane.linux.kernel/1383415 2015-11-06 22:10 GMT+03:00 Pablo Neira Ayuso : > On Fri, Nov 06, 2015 at 09:48:14PM +0300, Dmitry Safonov wrote: >> With

Re: [PATCH -next] net: hisilicon: Never build on SPARC

Arnd, On Wed, Oct 21, 2015 at 02:53:20PM -0700, Guenter Roeck wrote: > On Wed, Oct 21, 2015 at 09:11:53PM +0200, Arnd Bergmann wrote: > > On Wednesday 21 October 2015 10:03:05 Guenter Roeck wrote: > > > > > > > > Something like this? > > > > > > > > static inline u64 of_translate_address(struct

[PATCH] net: netfilter: fix false positive GCC warnings

With x86_64_defconfig: GCC thinks that in nfulnl_recv_config flags parameter is not inited but it was under the same condition (nfula[NFULA_CFG_FLAGS] == true). Suppress this warning: net/netfilter/nfnetlink_log.c: In function ‘nfulnl_recv_config’:

Re: [RFC PATCH 0/2] net: mvneta: Introduce RSS support

Hi Gregory, > I also choose to associate all the TX queues on the same CPU that the > one associated to the RX queue. It allows to contain all the > interrupts on the same CPU. I think that an improvement on this side > would be the support of the XPS. > Did you make some tries? E.g. after

[PATCH net] net/qlcnic: fix mac address restore in bond mode 5/6

The bonding driver saves a copy of slaves' original mac address and then assigns whatever mac as needed to the slave, depending on mode. In at least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the mac address of another slave. On release from the bond, the original mac address

Re: [PATCH net] selinux: fix random read in selinux_ip_postroute_compat()

On Fri, 2015-11-06 at 14:52 +0100, Dmitry Vyukov wrote: > Fixed the issue for me. Thanks Dmitry I'll submit ~6 additional patches, after doing a long due audit. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More

Re: Use-after-free in ep_remove_wait_queue

On 11/06/2015 08:06 AM, Dmitry Vyukov wrote: > On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov wrote: >> On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet wrote: >>> On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote: >>> Probably the issue

RE: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

From: Al Viro > Sent: 04 November 2015 16:28 > On Wed, Nov 04, 2015 at 03:54:09PM +, David Laight wrote: > > > Sigh... The kernel has no idea when other threads are done with "all > > > io activities using that fd" - it can wait for them to leave the > > > kernel mode, but there's fuck-all it

Re: Use-after-free in ep_remove_wait_queue

Jason Baron writes: > On 11/06/2015 08:06 AM, Dmitry Vyukov wrote: >> On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov wrote: >>> On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet >>> wrote: On Mon, 2015-10-12 at 14:02 +0200, Michal

RE: [GIT] Networking

> From: Linus Torvalds > Sent: 03 November 2015 20:45 > On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds > wrote: > > result = add_overflow( > > mul_overflow(sec, SEC_CONVERSION, ), > > mul_overflow(nsec, NSEC_CONVERSION, ), > > ); > > >

Re: Deadlock between bind and splice

On Fri, 2015-11-06 at 13:58 +0100, Dmitry Vyukov wrote: > Hello, > > I am on revision d1e41ff11941784f469f17795a4d9425c2eb4b7a (Nov 5) and > seeing the following lockdep reports. I don't have exact reproducer > program as it is caused by several independent programs (state > accumulated in kernel

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri, Nov 06, 2015 at 11:57:24AM +0100, Michal Hocko wrote: > On Thu 05-11-15 17:52:00, Johannes Weiner wrote: > > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > > > > This would be true if they moved on to

Re: [PATCH net] net/qlcnic: fix mac address restore in bond mode 5/6

Jarod Wilson wrote: The bonding driver saves a copy of slaves' original mac address and then assigns whatever mac as needed to the slave, depending on mode. In at least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the mac address of another slave. On release from the bond,

Please backport commit to 3.12+

Hi, We recently faced the issue described in the patch below on 3.14.56. This fix was merged in 4.2-rc7. I checked Davem's queue and stable queue and it's not there yet. Could we please have it in 3.12 and above ? (feature was introduced in 3.11). I can confirm that it properly fixes the problem

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri, Nov 06, 2015 at 12:05:55PM +0300, Vladimir Davydov wrote: > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > ... > > > 3) keep only some (safe) cache types enabled by default with the current > > >

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri 06-11-15 11:19:53, Johannes Weiner wrote: > On Fri, Nov 06, 2015 at 11:57:24AM +0100, Michal Hocko wrote: > > On Thu 05-11-15 17:52:00, Johannes Weiner wrote: > > > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > > > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal

Re: [PATCH] decnet: remove macro-local declarations

On Fri, 6 Nov 2015, walter harms wrote: > +1 > > I like this more since it is much more obvious what is done. > > more over we can remove a macro with only 2 users. It's not to bad because it turns out to be pretty concise. But I don't agree about the 2 users. There are 2 users for this

Re: [PATCH net] selinux: fix random read in selinux_ip_postroute_compat()

On Thu, Nov 5, 2015 at 10:46 PM, David Miller wrote: > From: Eric Dumazet > Date: Thu, 05 Nov 2015 13:39:24 -0800 > >> From: Eric Dumazet >> >> In commit e446f9dfe17b ("net: synack packets can be attached to request >> sockets"),

Re: NETIF_F_GSO_SOFTWARE vs NETIF_F_GSO

On Fri, Nov 6, 2015 at 5:58 AM, Herbert Xu wrote: > I don't see anything fundamentally wrong with your idea. After > all what you're describing is the basis of GSO, i.e., letting > data stay in the form of super-packets for as long as we can. > > Of course there's

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu 05-11-15 15:55:22, Johannes Weiner wrote: > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > > On Wed 04-11-15 14:50:37, Johannes Weiner wrote: [...] > > This would be true if they moved on to the new cgroup API intentionally. > > The reality is more complicated though. AFAIK

Re: AF_PACKET mmap() v4...

On 11/05/2015 11:56 PM, Daniel Borkmann wrote: On 11/05/2015 05:17 PM, Eric Dumazet wrote: On Thu, 2015-11-05 at 13:56 +0100, Daniel Borkmann wrote: On 11/05/2015 12:38 PM, Eric Dumazet wrote: If I am not mistaken, af_packet also lacks the ability to properly set skb->protocol I noticed

Deadlock between bind and splice

Hello, I am on revision d1e41ff11941784f469f17795a4d9425c2eb4b7a (Nov 5) and seeing the following lockdep reports. I don't have exact reproducer program as it is caused by several independent programs (state accumulated in kernel across invocations); if the report is not enough I can try to cook

Re: Use-after-free in ep_remove_wait_queue

On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov wrote: > On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet wrote: >> On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote: >> >>> Probably the issue discussed in >>> >>>

[PATCH] NFC: nci: Fix error check of nci_hci_create_pipe() result

net/nfc/nci/hci.c: In function ‘nci_hci_connect_gate’: net/nfc/nci/hci.c:679: warning: comparison is always false due to limited range of data type In case of error, nci_hci_create_pipe() returns NCI_HCI_INVALID_PIPE, and not a negative error code. Correct the check to fix this. Signed-off-by:

[iproute PATCH] ip_common.h header cleanup

- Drop 'extern' keyword from all function prototypes. - Make line breaking of print_* functions consistent. - Make print_ntable() and ipntable_reset_filter() static and remove their declaration. - Drop declaration of non-existent ipaddr_list() and iproute_monitor(). Signed-off-by: Phil Sutter

4.3.0, neighbour: arp_cache: neighbor table overflow! and panic

Hi I have several pppoe servers running under older kernels, and upgraded two of them to 4.3.0 After that, one of them randomly rebooting and stacktrace always different. Also i noticed message appearing, that didnt exist before on older kernels, appearing on both now: "neighbour: arp_cache:

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri, Nov 06, 2015 at 05:46:57PM +0100, Michal Hocko wrote: > The basic problem was that the Delegate feature has been backported to > our systemd package without further consideration and that has > invalidated a lot of performance testing because some resource > controllers have measurable

Re: [PATCH net 4/5] bnxt_en: Fix comparison of u16 sw_id against negative value.

On Fri, 2015-11-06 at 14:57 +0300, Sergei Shtylyov wrote: > Hello. > > On 11/6/2015 12:25 AM, Michael Chan wrote: > > > Assign the return value from bitmap_find_free_region() to an integer > > variable and check for negative error codes first, before assigning > > the bit ID to the unsigned

[RFC PATCH 0/2] net: mvneta: Introduce RSS support

Hi, this series is a first attempt to add RSS support on mvneta. this series will allow associating an ethernet interface to a given CPU through RSS by using "ethtool -X ethX weight". Indeed, currently I only enable one entry in the RSS lookup table. Even if it is not really RSS, it allows to

[RFC PATCH 1/2] net: mvneta: Associate RX queues with each CPU

We enable the percpu interrupt for all the CPU and we just associate a CPU to a few queue at the neta level. The mapping between the CPUs and the queues is static. The queues are associated to the CPU module the number of CPUs. However currently we only use on RX queue for a given Ethernet port.

[RFC PATCH 2/2] net: mvneta: Add naive RSS support

This patch add the support for the RSS related ethtool function. Currently it only use one entry in the indirection table which allows associating an mveneta interface to a given CPU. Signed-off-by: Gregory CLEMENT --- drivers/net/ethernet/marvell/mvneta.c |

Re: [PATCH] [BACKPORT] [3.14.56] bnx2x: Don't notify about scratchpad parities

On Friday 06 November 2015 09:32:46 Greg KH wrote: > On Thu, Nov 05, 2015 at 11:18:37AM +0100, Patrick Schaaf wrote: > > bnx2x: Don't notify about scratchpad parities > > > > This is a (trivial) "backport" of ad6afbe9578d1fa26680faf78c846bd8c00d1d6e > > to stable kernel 3.14.56. > > This patch

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

On Fri, Nov 06, 2015 at 03:07:30PM +, David Laight wrote: > > Oh, _lovely_. So instead of continuation of that write(2) going down > > the throat of something opened by unrelated thread, it (starting from a > > pretty arbitrary point) will go into the descriptor the closing thread > > passed

[PATCH] inet: delay address promotion check until last request in message

I recently got a report that, after a user added 40,000 addresses to an interface and ran ip addr flush , their system blocked on interface access for literally hours, and issued hundreds of hung task warnings. due to rtnl being held during this operation. While its certainly arguable that long

linux-next network throughput performance regression

I compared the network throughput performance on SLES12 bare metal servers, between SLES12 default kernel and latest linux-next (2015-11-05) kernel, based on the test results, I suspect there is a network regression exists on Linux-Next over the 40G Ethernet network: a) iperf3 reports 50%

Re: linux-next network throughput performance regression

On 11/6/15 1:31 PM, Simon Xiao wrote: I compared the network throughput performance on SLES12 bare metal servers, between SLES12 default kernel and latest linux-next (2015-11-05) kernel, based on the test results, I suspect there is a network regression exists on Linux-Next over the 40G

Re: [PATCH -next] net: hisilicon: Never build on SPARC

On Friday 06 November 2015 11:16:52 Guenter Roeck wrote: > On Wed, Oct 21, 2015 at 02:53:20PM -0700, Guenter Roeck wrote: > > On Wed, Oct 21, 2015 at 09:11:53PM +0200, Arnd Bergmann wrote: > > > On Wednesday 21 October 2015 10:03:05 Guenter Roeck wrote: > > > > Anyway, if it gets that complicated,

Re: [PATCH] decnet: remove macro-local declarations

+1 I like this more since it is much more obvious what is done. more over we can remove a macro with only 2 users. re, wh Am 06.11.2015 11:57, schrieb Julia Lawall: >>> Would it be preferable to remove the macro entirely and inline the for >>> loop header? >> >> Could you show me an example

A Call For Charity

My Name is Mrs Jessica Peterside from United Kingdom who is suffering from cancer of the lungs and I wish to use my fund to serve the poor in your country since I have limited time on earth Regards Mrs Jessica Peterside reply for more details on this Email:mrsjessicapetersid...@gmail.com --

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri 06-11-15 12:05:55, Vladimir Davydov wrote: [...] > If there are no objections, I'll prepare a patch switching to the > white-list approach. Let's start from obvious things like fs_struct, > mm_struct, task_struct, signal_struct, dentry, inode, which can be > easily allocated from user

Re: [GIT PULL] parisc architecture updates for v4.3

On Wed, Nov 4, 2015 at 12:03 AM, Helge Deller wrote: >> Also, just looking at other things, we currently do have openrisc that has >> >> #define L1_CACHE_BYTES 16 >> >> so presumably openrisc would have had an issue with that XPS thing, > > and mn10300. And several other

Re: GSO with udp_tunnel_xmit_skb

Hi Tom, On Fri, Nov 6, 2015 at 8:19 AM, Tom Herbert wrote: > Is this about UFO or GSO (in email subject)? UFO should operate > independently encapsulation or inner packet setting. I suppose this is about UFO. Specifically -- let's say I have a list of 500 skbs, which have

Re: [RFC PATCH 2/2] net: mvneta: Add naive RSS support

Hi Marcin, [...] >> +static int mvneta_config_rss(struct mvneta_port *pp) >> +{ >> + int cpu; >> + u32 val; >> + >> + netif_tx_stop_all_queues(pp->dev); >> + >> + /* Mask all ethernet port interrupts */ >> + mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); > > Shouldn't

[PATCH net 2/2] packet: fix tpacket_snd max frame and vlan handling

There seem to be a couple of issues in tpacket_snd() path. Since it's introduction in commit 69e3c75f4d54 ("net: TX_RING and packet mmap"), TX_RING could be used from SOCK_DGRAM and SOCK_RAW side. When used with SOCK_DGRAM only, the size_max > dev->mtu + reserve check should have reserve as 0, but

[PATCH net 0/2] packet fix

Hi Eric, does this resolve the issues you're having on the TX_RING when dealing with trafgen [1]? Thanks a lot, Daniel [1] http://thread.gmane.org/gmane.linux.network/385988 Daniel Borkmann (2): packet: do skb_probe_transport_header when we actually have data packet: fix tpacket_snd max

[PATCH net 1/2] packet: do skb_probe_transport_header when we actually have data

In tpacket_fill_skb() commit c1aad275b029 ("packet: set transport header before doing xmit") and later on 40893fd0fd4e ("net: switch to use skb_probe_transport_header()") was probing for a transport header on the skb from a ring buffer slot, but at a time, where the skb has _not even_ been filled

Re: linux-next network throughput performance regression

On 11/6/15 2:18 PM, Simon Xiao wrote: The .config file used to build linux-next kernel is attached to this mail. Thanks. Failed to notice this on the first response; my brain filled in. Why linux-next tree? Can you try net-next which is more relevant for this mailing list, post the top