Re: [PATCH 0/6 v3] kvmalloc

On Wed 25-01-17 21:16:42, Daniel Borkmann wrote: > On 01/25/2017 07:14 PM, Alexei Starovoitov wrote: > > On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote: > > > On Wed 25-01-17 14:10:06, Michal Hocko wrote: > > > > On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote: > [...]

Re: [PATCH v2 iproute2] f_flower: don't set TCA_FLOWER_KEY_ETH_TYPE for "protocol all"

On 20/01/2017 21:07, Benjamin LaHaise wrote: v2 - update to address changes in 00697ca19ae3e1118f2af82c3b41ac4335fe918b. When using the tc flower filter, rules marked with "protocol all" do not actually match all packets. This is due to a bug in f_flower.c that passes in ETH_P_ALL in the

[PATCH RFC ipsec-next] IPsec GRO

This introduces a device independent napi instance that handles GRO for IPsec. I was not able to use gro cells directly because I don't have a netdevice where I can hang off the napi instance. We now may have a secpath at a GRO merged skb, so we need to drop it. This is the only cange to the

[PATCH RFC ipsec-next 2/2] xfrm: Add a device independent napi instance

This patch adds a napi instance for IPsec GRO. With this, we handle IPsec GRO with no impact on the generic networking code. Signed-off-by: Steffen Klassert --- net/xfrm/xfrm_input.c | 87 ++- 1 file changed, 86

[PATCH RFC ipsec-next 1/2] net: Drop secpath on free after gro merge.

With a followup patch, a gro merged skb can have a secpath. So drop it before freeing or reusing the skb. Signed-off-by: Steffen Klassert --- net/core/dev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/core/dev.c b/net/core/dev.c index 56818f7..c9e541e

Re: [PATCH net] bpf: expose netns inode to bpf programs

On 1/25/17 9:46 PM, Eric W. Biederman wrote: Alexei Starovoitov writes: in cases where bpf programs are looking at sockets and packets that belong to different netns, it could be useful to read netns inode, so that programs can make intelligent decisions. For example to disallow

Re: [PATCH net] bpf: expose netns inode to bpf programs

tetst teste tetet tetest tetett On 01/26/2017 01:46 PM, Eric W. Biederman wrote: > Alexei Starovoitov writes: > >> in cases where bpf

Re: [PATCH net] bpf: expose netns inode to bpf programs

Alexei Starovoitov writes: > in cases where bpf programs are looking at sockets and packets > that belong to different netns, it could be useful to read netns inode, > so that programs can make intelligent decisions. > For example to disallow raw sockets in all non-init netns the

[net-next] openvswitch: Simplify do_execute_actions().

do_execute_actions() implements a worthwhile optimization: in case an output action is the last action in an action list, skb_clone() can be avoided by outputing the current skb. However, the implementation is more complicated than necessary. This patch simplify this logic. Signed-off-by: Andy

Re: [PATCH] [net-next] bridge: move maybe_deliver_addr() inside #ifdef

From: Arnd Bergmann Date: Wed, 25 Jan 2017 23:29:33 +0100 > The only caller of this new function is inside of an #ifdef checking > for CONFIG_BRIDGE_IGMP_SNOOPING, so we should move the implementation > there too, in order to avoid this harmless warning: > >

Re: [PATCH net-next] bpf: use prefix_len in test_tag when reading fdinfo

From: Daniel Borkmann Date: Thu, 26 Jan 2017 00:42:49 +0100 > We currently used len instead of prefix_len for the strncmp() in > fdinfo on the prog_tag. It still worked as we matched on the correct > output line also with first 8 instead of 10 chars, but lets fix it >

Re: [PATCH V2 0/3] net-next: Broadcom PHY driver cleanup

From: Rafał Miłecki Date: Wed, 25 Jan 2017 21:00:24 +0100 > I will probably need to use broadcom.ko for PHY connected to interface > of bgmac supported device so I started looking at it willing to > understand it better. > > I found AUXCTL part of the driver / lib a bit

Re: [PATCH 0/1] pull request for net: batman-adv 2017-01-25

From: Simon Wunderlich Date: Wed, 25 Jan 2017 17:25:05 +0100 > here is a bugfix for net which we would like to have integrated. > > Please pull or let me know of any problem! Pulled, thanks.

Re: [PATCHv3 0/7] Refactor macvtap to re-use tap functionality by other virtual intefaces

From: Sainath Grandhi Date: Wed, 25 Jan 2017 13:25:32 -0800 > Tap character devices can be implemented on other virtual interfaces like > ipvlan, similar to macvtap. Source code for tap functionality in macvtap > can be re-used for this purpose. > > This patch series

Re: [PATCH net 2/5] ibmvnic: Fix MTU settings

From: Thomas Falcon Date: Wed, 25 Jan 2017 15:02:20 -0600 > In the current driver, the MTU is set to the maximum value > capable for the backing device. This patch sets the MTU to the > default value for a Linux net device. Why are you doing this? What happens to

Re: [PATCH net 1/5] ibmvnic: harden interrupt handler

From: Thomas Falcon Date: Wed, 25 Jan 2017 15:02:19 -0600 > Move most interrupt handler processing into a tasklet, and > introduce a delay after re-enabling interrupts to fix timing > issues encountered in hardware testing. > > Signed-off-by: Thomas Falcon

[PATCH v4 net-next 1/2] net/ipv6: allow sysctl to change link-local address generation mode

The address generation mode for IPv6 link-local can only be configured by netlink messages. This patch adds the ability to change the address generation mode via sysctl. v1 -> v2 Removed the rtnl lock and switch to use RCU lock to iterate through the netdev list. v2 -> v3 Removed the addrgenmode

[PATCH v4 net-next 2/2] net/ipv6: support more tunnel interfaces for EUI64 link-local generation

Signed-off-by: Felix Jia --- net/ipv6/addrconf.c | 5 + net/ipv6/ip6_gre.c | 3 +++ net/ipv6/ip6_vti.c | 4 3 files changed, 12 insertions(+) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index e35259dd17ba..4c47656b9f09 100644 ---

Re: [PATCH 2/7] batman-adv: Treat NET_XMIT_CN as transmit successfully

From: Simon Wunderlich Date: Wed, 25 Jan 2017 17:42:58 +0100 > From: Gao Feng > > The tc could return NET_XMIT_CN as one congestion notification, but > it does not mean the packet is lost. Other modules like ipvlan, > macvlan, and others treat

RE: [PATCH net v3 0/4] r8152: fix scheduling napi

David Miller [mailto:da...@davemloft.net] > Sent: Thursday, January 26, 2017 11:48 AM [...] > Series applied. Thank you very much. I would try to find better way, too. Best Regards, Hayes

Re: [net PATCH] virtio_net: use dev_kfree_skb for small buffer XDP receive

From: John Fastabend Date: Wed, 25 Jan 2017 18:22:48 -0800 > In the small buffer case during driver unload we currently use > put_page instead of dev_kfree_skb. Resolve this by adding a check > for virtnet mode when checking XDP queue type. Also name the > function so

Re: [PATCH net resend] virtio_net: reject XDP programs using header adjustment

From: Jakub Kicinski Date: Wed, 25 Jan 2017 14:56:36 -0800 > commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog") > added a new XDP helper to prepend and remove data from a frame. > Make virtio_net reject programs making use of this helper until >

Re: [PATCH net v3 0/4] r8152: fix scheduling napi

From: Hayes Wang Date: Thu, 26 Jan 2017 09:38:30 +0800 > v3: > simply the argument for patch #3. Replace >napi with napi. > > v2: > Add smp_mb__after_atomic() for patch #1. > > v1: > Scheduling the napi during the following periods would let it be ignored. > And the

Re: [PATCH net v2 0/4] r8152: fix scheduling napi

From: Hayes Wang Date: Thu, 26 Jan 2017 03:04:45 + > May you apply these patches first, until I find another way to replace > current one? Yes, I will.

Копия: Инновациoнная системa oтбeливaния зубoв в доmашних уcлoвиях

Копия: Это сообщение было отправлено через раздел Контакты сайта http://elondon.ru/: MeriGadabimb Огромный выбop вариaнтов oтбеливания зубов заведёт в тупик любого. Каждый метод уникалeн по-своеmу, нo не каждый полезен для зубов. Главнoе – не oшибиться при выбоpе, ведь

[PATCH net] bpf: expose netns inode to bpf programs

in cases where bpf programs are looking at sockets and packets that belong to different netns, it could be useful to read netns inode, so that programs can make intelligent decisions. For example to disallow raw sockets in all non-init netns the program can do: if (sk->type == SOCK_RAW &&

RE: [PATCH net v2 0/4] r8152: fix scheduling napi

David Miller [mailto:da...@davemloft.net] > Sent: Thursday, January 26, 2017 3:31 AM [...] > I think the fundamental issue is that since you can't stop URBs from > queueing up, you cannot properly synchronize NAPI and schedule polling > properly. > > From my perspective what happened here is you

Re: [PATCH net resend] virtio_net: reject XDP programs using header adjustment

On Wed, Jan 25, 2017 at 02:56:36PM -0800, Jakub Kicinski wrote: > commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog") > added a new XDP helper to prepend and remove data from a frame. > Make virtio_net reject programs making use of this helper until > proper support is added. > >

Re: [PATCH net resend] virtio_net: reject XDP programs using header adjustment

On 2017年01月26日 06:56, Jakub Kicinski wrote: commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog") added a new XDP helper to prepend and remove data from a frame. Make virtio_net reject programs making use of this helper until proper support is added. Signed-off-by: Jakub

[net PATCH] virtio_net: use dev_kfree_skb for small buffer XDP receive

In the small buffer case during driver unload we currently use put_page instead of dev_kfree_skb. Resolve this by adding a check for virtnet mode when checking XDP queue type. Also name the function so that the code reads correctly to match the additional check. Fixes: bb91accf2733 ("virtio-net:

RE: NAPI on USB network drivers

Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Wednesday, January 25, 2017 10:13 PM [...] > You also could use napi_complete_done() instead of napi_complete(), as > it allows users to tune the performance vs latency for GRO. > > Looking at this driver, I do not see any limitation on the

[PATCH net v3 4/4] r8152: check rx after napi is enabled

Schedule the napi after napi_enable() for rx, if it is necessary. If the rx is completed when napi is disabled, the sheduling of napi would be lost. Then, no one handles the rx packet until next napi is scheduled. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 7

[PATCH net v3 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit() from calling napi_schedule() directly during runtime suspend. After calling napi_disable() or clearing the flag of WORK_ENABLE, scheduling the napi is useless. Signed-off-by: Hayes Wang ---

[PATCH net v3 0/4] r8152: fix scheduling napi

v3: simply the argument for patch #3. Replace >napi with napi. v2: Add smp_mb__after_atomic() for patch #1. v1: Scheduling the napi during the following periods would let it be ignored. And the events wouldn't be handled until next napi_schedule() is called. 1. after napi_disable and before

[PATCH net v3 2/4] r8152: avoid start_xmit to schedule napi when napi is disabled

Stop the tx when the napi is disabled to prevent napi_schedule() is called. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index

[PATCH net v3 3/4] r8152: re-schedule napi for tx

Re-schedule napi after napi_complete() for tx, if it is necessay. In r8152_poll(), if the tx is completed after tx_bottom() and before napi_complete(), the scheduling of napi would be lost. Then, no one handles the next tx until the next napi_schedule() is called. Signed-off-by: Hayes Wang

RE: [PATCH net v2 3/4] r8152: re-schedule napi for tx

Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Wednesday, January 25, 2017 9:57 PM [...] > > napi_complete(napi); > > if (!list_empty(>rx_done)) > > napi_schedule(napi); > > + else if (!skb_queue_empty(>tx_queue) && > > +

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

Andy Lutomirski writes: > On Tue, Jan 24, 2017 at 4:11 PM, Alexei Starovoitov > wrote: >> On Tue, Jan 24, 2017 at 01:24:54PM -0800, Andy Lutomirski wrote: >>> On Tue, Jan 24, 2017 at 12:29 PM, David Ahern >>> wrote:

Re: [PATCH] [net-next] bridge: move maybe_deliver_addr() inside #ifdef

On Wed, 25 Jan 2017 23:29:33 +0100 Arnd Bergmann wrote: > The only caller of this new function is inside of an #ifdef checking > for CONFIG_BRIDGE_IGMP_SNOOPING, so we should move the implementation > there too, in order to avoid this harmless warning: > >

[PATCH net-next] bpf: use prefix_len in test_tag when reading fdinfo

We currently used len instead of prefix_len for the strncmp() in fdinfo on the prog_tag. It still worked as we matched on the correct output line also with first 8 instead of 10 chars, but lets fix it properly to use the intended length. Fixes: 62b64660262a ("bpf: add prog tag test case to bpf

Re: [patch net-next v2 2/4] net/sched: Introduce sample tc action

On Mon, Jan 23, 2017 at 2:07 AM, Jiri Pirko wrote: > + > +static int tcf_sample_init(struct net *net, struct nlattr *nla, > + struct nlattr *est, struct tc_action **a, int ovr, > + int bind) > +{ > + struct tc_action_net

Re: [PATCH] cxgbit: use T6 specific macro to set force bit

On Tue, 2017-01-24 at 17:07 +0530, Varun Prakash wrote: > For T6 adapters use T6 specific macro to set force bit. Thanks, I have applied this patch. Bart.

[PATCH net resend] virtio_net: reject XDP programs using header adjustment

commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog") added a new XDP helper to prepend and remove data from a frame. Make virtio_net reject programs making use of this helper until proper support is added. Signed-off-by: Jakub Kicinski Acked-by: John

ip_rcv_finish() NULL pointer kernel panic

All, I am experiencing a kernel panic on different (but identical) hardware in ip_rcv_finish on Linux 4.4.39 (but I can see no changes that would improve the situation on 4.4.44, or master). Looking at the disassembly at the last stack frame it looks like we are calling a NULL function

ip_rcv_finish() NULL pointer kernel panic

All, I am experiencing a kernel panic on different (but identical) hardware in ip_rcv_finish on Linux 4.4.39 (but I can see no changes that would improve the situation on 4.4.44, or master). Looking at the disassembly at the last stack frame it looks like we are calling a NULL function

[PATCH] [net-next] bridge: move maybe_deliver_addr() inside #ifdef

The only caller of this new function is inside of an #ifdef checking for CONFIG_BRIDGE_IGMP_SNOOPING, so we should move the implementation there too, in order to avoid this harmless warning: net/bridge/br_forward.c:177:13: error: 'maybe_deliver_addr' defined but not used

[PATCH] [net-next] ISDN: eicon: reduce stack size of sig_ind function

I noticed that this function uses a lot of kernel stack when the "latent entropy" plugin is enabled: drivers/isdn/hardware/eicon/message.c: In function 'sig_ind': drivers/isdn/hardware/eicon/message.c:6113:1: error: the frame size of 1168 bytes is larger than 1152 bytes

Re: network status

On Tue, Jan 24, 2017 at 11:39 AM, Sriram V wrote: > Hello, > > Apologies in case, this is not the right list of this question. > > I wanted to check, How can i find out if a network status has changed > > 1. How can the user application find out if the link status has

Re: [PATCH V2 2/2] qedf: Add QLogic FastLinQ offload FCoE driver framework.

Hi Chad, [auto build test WARNING on net/master] [also build test WARNING on v4.10-rc5 next-20170125] [cannot apply to net-next/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dupuis

Re: [PATCH net-next] tcp: reduce skb overhead in selected places

On Wed, 2017-01-25 at 14:03 -0500, David Miller wrote: > From: Eric Dumazet > Date: Wed, 25 Jan 2017 10:38:52 -0800 > > > Do you think we could change __pskb_pull_tail() right away and fix the > > few places that would break, or should we add various helpers with extra >

Re: sk_buff and reference counting netdev pointers

> On Jan 23, 2017, at 5:45 PM, Cong Wang wrote: > > On Mon, Jan 23, 2017 at 2:37 PM, Joel Cunningham > wrote: >> Hi, >> >> I’m working on a research effort to understand the synchronization >> mechanisms for accessing and modifying a struct

[PATCHv3 1/7] TAP: Refactoring macvtap.c

macvtap module has code for tap/queue management and link management. This patch splits the code into macvtap_main.c for link management and tap.c for tap/queue management. Functionality in tap.c can be re-used for implementing tap on other virtual interfaces. Signed-off-by: Sainath Grandhi

[PATCHv3 4/7] TAP: Abstract type of virtual interface from tap implementation

macvlan object is re-structured to hold tap related elements in a separate entity, tap_dev. Upon NETDEV_REGISTER device_event, tap_dev is registered with idr and fetched again on tap_open. Few of the tap functions are modified to accepted tap_dev as argument. tap_dev object includes callbacks to

[PATCHv3 0/7] Refactor macvtap to re-use tap functionality by other virtual intefaces

Tap character devices can be implemented on other virtual interfaces like ipvlan, similar to macvtap. Source code for tap functionality in macvtap can be re-used for this purpose. This patch series splits macvtap source into two modules, macvtap and tap. This patch series also includes a patch

[PATCHv3 6/7] TAP: tap as an independent module

This patch makes tap a separate module for other types of virtual interfaces, for example, ipvlan to use. Signed-off-by: Sainath Grandhi --- drivers/net/Kconfig | 15 +++ drivers/net/Makefile | 3 +--

[PATCHv3 2/7] TAP: Renaming tap related APIs, data structures, macros

Renaming tap related APIs, data structures and macros in tap.c from macvtap_.* to tap_.* Signed-off-by: Sainath Grandhi --- drivers/net/macvtap_main.c | 18 +-- drivers/net/tap.c | 332 ++--- drivers/vhost/net.c

[PATCHv3 3/7] TAP: Tap character device creation/destroy API

This patch provides tap device create/destroy APIs in tap.c. Signed-off-by: Sainath Grandhi --- drivers/net/macvtap_main.c | 30 +++--- drivers/net/tap.c | 62 ++ include/linux/if_tap.h | 3 +++

[PATCHv3 7/7] IPVTAP: IP-VLAN based tap driver

This patch adds a tap character device driver that is based on the IP-VLAN network interface, called ipvtap. An ipvtap device can be created in the same way as an ipvlan device, using 'type ipvtap', and then accessed using the tap user space interface. Signed-off-by: Sainath Grandhi

[PATCHv3 5/7] TAP: Extending tap device create/destroy APIs

Extending tap APIs get/free_minor and create/destroy_cdev to handle more than one type of virtual interface. Signed-off-by: Sainath Grandhi --- drivers/net/macvtap_main.c | 6 +-- drivers/net/tap.c | 98 +++---

Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

On Tue, Jan 24, 2017 at 10:59:15AM -0800, Florian Fainelli wrote: > On 01/19/2017 10:12 AM, Florian Fainelli wrote: > > > > Back to the actual code that triggered this discussion, the whole > > purpose is just a safeguard. Given a device reference, we can assume > > that it is indeed the backing

Re: [PATCH v4] net: ethernet: faraday: To support device tree usage.

On Wed, Jan 25, 2017 at 6:34 PM, David Miller wrote: > From: Greentime Hu > Date: Tue, 24 Jan 2017 16:46:14 +0800 >> We also use the same binding document to describe the same faraday ethernet >> controller and add faraday to vendor-prefixes.txt. > > Why

[PATCH net 2/5] ibmvnic: Fix MTU settings

In the current driver, the MTU is set to the maximum value capable for the backing device. This patch sets the MTU to the default value for a Linux net device. It also corrects a discrepancy between MTU values received from firmware, which includes the ethernet header length, and net device MTU

[PATCH net 4/5] ibmvnic: Fix endian errors in error reporting output

Error reports received from firmware were not being converted from big endian values, leading to bogus error codes reported on little endian systems. Signed-off-by: Thomas Falcon --- drivers/net/ethernet/ibm/ibmvnic.c | 8 1 file changed, 4 insertions(+), 4

[PATCH net 1/5] ibmvnic: harden interrupt handler

Move most interrupt handler processing into a tasklet, and introduce a delay after re-enabling interrupts to fix timing issues encountered in hardware testing. Signed-off-by: Thomas Falcon --- drivers/net/ethernet/ibm/ibmvnic.c | 21 +++--

[PATCH net 3/5] ibmvnic: Fix endian error when requesting device capabilites

When a IBM VNIC client driver requests a faulty device setting, the server returns an acceptable value for the client to request. This 64 bit value was incorrectly being swapped as a 32 bit value, resulting in loss of data. This patch corrects that by using the 64 bit swap function.

[PATCH net 5/5] ibmvnic: init completion struct before requesting long term mapped buffers

Initialize this completion structure before requesting that a buffer be long-term mapped . This fix resolves a bug where firmware sends a response before the structure is initialized. Signed-off-by: John Allen Signed-off-by: Nathan Fontenot

Re: NAPI on USB network drivers

On Wed, Jan 25, 2017 at 5:33 AM, Oliver Hartkopp wrote: > On 01/25/2017 10:39 AM, Hayes Wang wrote: >> >> Oliver Neukum [mailto:oneu...@suse.com] >>> >>> Sent: Wednesday, January 25, 2017 5:35 PM >> >> [...] >>> >>> looking at r8152 I noticed that it uses NAPI. I never

Re: [PATCH V2 3/3] net: phy: bcm-phy-lib: clean up remaining AUXCTL register defines

On 01/25/2017 12:00 PM, Rafał Miłecki wrote: > From: Rafał Miłecki > > 1) Use 0x%02x format for register number. This follows some other >defines and makes it easier to distinct register from values. > 2) Put register define above values and sort the values. It makes >

[PATCH V2 0/2] Add QLogic FastLinQ FCoE (qedf) driver

From: "Dupuis, Chad" This series introduces the hardware offload FCoE initiator driver for the 41000 Series Converged Network Adapters (579xx chip) by Cavium. The overall driver design includes a common module ('qed') and protocol specific dependent modules ('qedf' for

[PATCH V2 net-next 1/2] qed: Add support for hardware offloaded FCoE.

From: Arun Easi This adds the backbone required for the various HW initalizations which are necessary for the FCoE driver (qedf) for QLogic FastLinQ 4 line of adapters - FW notification, resource initializations, etc. Signed-off-by: Arun Easi

Re: [PATCH V2 2/3] net: phy: broadcom: drop duplicated define for RGMII SKEW delay

On 01/25/2017 12:00 PM, Rafał Miłecki wrote: > From: Rafał Miłecki > > We had two defines for the same bit (both were used with the > MII_BCM54XX_AUXCTL_SHDWSEL_MISC register). > > Signed-off-by: Rafał Miłecki Reviewed-by: Florian Fainelli

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Tue, Jan 24, 2017 at 4:11 PM, Alexei Starovoitov wrote: > On Tue, Jan 24, 2017 at 01:24:54PM -0800, Andy Lutomirski wrote: >> On Tue, Jan 24, 2017 at 12:29 PM, David Ahern >> wrote: >> > >> > Users do not run around exec'ing commands in

Re: [PATCH net-next 5/5] bpf: enable verifier to better track const alu ops

On 01/25/2017 04:56 PM, William Tu wrote: Looks good to me, I tested with several complex program without any problem. Thanks for the patch. Thanks for re-testing, William!

Re: [PATCH 0/6 v3] kvmalloc

On 01/25/2017 07:14 PM, Alexei Starovoitov wrote: On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote: On Wed 25-01-17 14:10:06, Michal Hocko wrote: On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote: [...] Are there any more comments? I would really appreciate to hear

[PATCH V2 1/3] net: phy: broadcom: use auxctl reading helper in BCM54612E code

From: Rafał Miłecki Starting with commit 5b4e29005123 ("net: phy: broadcom: add bcm54xx_auxctl_read") we have a reading helper so use it and avoid code duplication. It also means we don't need MII_BCM54XX_AUXCTL_SHDWSEL_MISC define as it's the same as

[PATCH V2 3/3] net: phy: bcm-phy-lib: clean up remaining AUXCTL register defines

From: Rafał Miłecki 1) Use 0x%02x format for register number. This follows some other defines and makes it easier to distinct register from values. 2) Put register define above values and sort the values. It makes reading header code easier. 3) Use 0x%04x format for all

[PATCH V2 0/3] net-next: Broadcom PHY driver cleanup

From: Rafał Miłecki I will probably need to use broadcom.ko for PHY connected to interface of bgmac supported device so I started looking at it willing to understand it better. I found AUXCTL part of the driver / lib a bit confusing and hard to read so I'm trying to clean it

[PATCH V2 2/3] net: phy: broadcom: drop duplicated define for RGMII SKEW delay

From: Rafał Miłecki We had two defines for the same bit (both were used with the MII_BCM54XX_AUXCTL_SHDWSEL_MISC register). Signed-off-by: Rafał Miłecki --- V2: Drop the other define to match datasheet. Thanks Florian. --- drivers/net/phy/broadcom.c | 2 +-

Re: [PATCH net] net: dsa: Mop up remaining NET_DSA_HWMON references

From: Andrew Lunn Date: Wed, 25 Jan 2017 15:04:17 +0100 > Previous patches have moved the temperature sensor code into the > Marvell PHYs. A few now dead references to NET_DSA_HWMON were left > behind. Go reap them. > > Reported-by: Valentin Rothberg

Re: loopback device reference count leakage

Hello, On Mon, Jan 23, 2017 at 9:17 PM, Kaiwen Xu wrote: > Hi netdev folks, > > I am currently experiencing an issue related with the loopback during > network devices shutdown inside a network namespace, which mainfested as > > unregister_netdevice: waiting for lo to become

Re: [PATCH net] net: dsa: Bring back device detaching in dsa_slave_suspend()

From: Florian Fainelli Date: Wed, 25 Jan 2017 09:10:41 -0800 > Commit 448b4482c671 ("net: dsa: Add lockdep class to tx queues to avoid > lockdep splat") removed the netif_device_detach() call done in > dsa_slave_suspend() which is necessary, and paired with a corresponding

Re: [PATCH net-next] sfc: reduce severity of PIO buffer alloc failures

From: Bert Kenward Date: Wed, 25 Jan 2017 13:48:17 + > From: Tomáš Pilař > > PIO buffer allocation can fail for two valid reasons: > - we've run out of them (results in -ENOSPC) > - the NIC configuration doesn't support them (results in

Re: [PATCH 0/2] More ethtool support and BGX configuration changes

From: sunil.kovv...@gmail.com Date: Wed, 25 Jan 2017 17:36:22 +0530 > These patches adds support to set queue sizes from ethtool and changes > the way serdes lane configuration is done by BGX driver on 81/83xx > platforms. Series applied, thanks.

Re: [PATCH v2 0/3] net: phy: leds: Fix truncated LED trigger names and crashes

From: Geert Uytterhoeven Date: Wed, 25 Jan 2017 11:39:47 +0100 > I started seeing crashes during s2ram and poweroff on all my ARM boards, > like: > > Unable to handle kernel NULL pointer dereference at virtual address > > ... > []

Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390

Hi Andrew, Andrew Lunn writes: >> if (reg == MII_PHYSID2 && (*val & 0xfff0) == 0) > > This should be 0x3f0. There are 10 bits for the device model, of which > Marvell uses the lowest 4 for version. > >> *val |= chip->info->prod_num << 4; > > #define

Re: [PATCH 1/2] Documentation: devicetree: change the mediatek ethernet compatible string

From: John Crispin Date: Wed, 25 Jan 2017 09:20:54 +0100 > When the binding was defined, I was not aware that mt2701 was an earlier > version of the SoC. For sake of consistency, the ethernet driver should > use mt2701 inside the compat string as this is the earliest SoC with

Re: [PATCH 2/2] net-next: ethernet: mediatek: change the compatible string

From: John Crispin Date: Wed, 25 Jan 2017 09:20:55 +0100 > When the binding was defined, I was not aware that mt2701 was an earlier > version of the SoC. For sake of consistency, the ethernet driver should > use mt2701 inside the compat string as this is the earliest SoC with

Re: NAPI on USB network drivers

From: Oliver Neukum Date: Wed, 25 Jan 2017 10:34:41 +0100 > looking at r8152 I noticed that it uses NAPI. I never considered > this for the generic USB networking code as you cannot disable > interrupts for USB. Is it still worth it? What are the benefits? I think it's not a

Re: [PATCH net v2 0/4] r8152: fix scheduling napi

From: Hayes Wang Date: Wed, 25 Jan 2017 16:13:17 +0800 > v2: > Add smp_mb__after_atomic() for patch #1. > > v1: > Scheduling the napi during the following periods would let it be ignored. > And the events wouldn't be handled until next napi_schedule() is called. > > 1.

Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390

On Wed, Jan 25, 2017 at 01:03:43PM -0500, Vivien Didelot wrote: > Andrew, > > Vivien Didelot writes: > > > Since several chips have this issue, we can introduce a u16 physid2_mask > > member in the mv88e6xxx_info structure and move the check in > >

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

> Note that I am not sure we correctly test that a second connect() can be > done, and I am not sure kernel would check that the remote IP and > destination port is the same. > Ie what should happen for > setsockopt(fd, SOL_TCP, TCP_FASTOPEN_CONNECT, , 4) > connect(fd, "1.2.3.4:80") >

Re: [PATCH net-next] net/tcp-fastopen: make connect()'s return case more consistent with non-TFO

From: Willy Tarreau Date: Wed, 25 Jan 2017 14:42:46 +0100 > Without TFO, any subsequent connect() call after a successful one returns > -1 EISCONN. The last API update ensured that __inet_stream_connect() can > return -1 EINPROGRESS in response to sendmsg() when TFO is in use to >

Re: [PATCH net-next 0/3] net/tcp-fastopen: Add new userspace API support

From: Wei Wang Date: Mon, 23 Jan 2017 10:59:19 -0800 > The patch series is to add support for new userspace API for TCP fastopen > sockets. > In the current code, user has to call sendto()/sendmsg() with special flag > MSG_FASTOPEN for TCP fastopen sockets. This API is

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

From: Wei Wang Date: Wed, 25 Jan 2017 10:54:50 -0800 >> Yes sorry David, for me it's OK. If Wei runs his whole series of tests >> on it again, it should be perfect. > > I just ran all the TFO related tests with Willy's patch on top of this > patch series. > And everything

Re: [PATCH net-next] tcp: reduce skb overhead in selected places

From: Eric Dumazet Date: Wed, 25 Jan 2017 10:38:52 -0800 > Do you think we could change __pskb_pull_tail() right away and fix the > few places that would break, or should we add various helpers with extra > parameters to take a safe route ? It should always be safe as

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

On Wed, 2017-01-25 at 10:54 -0800, Wei Wang wrote: > > Yes sorry David, for me it's OK. If Wei runs his whole series of tests > > on it again, it should be perfect. > > I just ran all the TFO related tests with Willy's patch on top of this > patch series. > And everything passes. Note that I am

RE: [PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

Adding Bob Bernstein Jon Pannell -Original Message- From: Gregory CLEMENT [mailto:gregory.clem...@free-electrons.com] Sent: Tuesday, January 24, 2017 11:56 PM To: Andrew Lunn Cc: Vivien Didelot ; Florian Fainelli

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

> Yes sorry David, for me it's OK. If Wei runs his whole series of tests > on it again, it should be perfect. I just ran all the TFO related tests with Willy's patch on top of this patch series. And everything passes. On Wed, Jan 25, 2017 at 9:54 AM, Willy Tarreau wrote: > On Wed,

Re: stmmac: GMAC_RGSMIIIS reports bogus values

On 01/25/2017 10:39 AM, Alexey Brodkin wrote: >> Also I wonder if, other version of the stmmac worked on this platform >> before. > It did work and still works. The only problem is we're getting > a lot of noise now about bogus link status change. That's because > this info is now in pr_info()

Re: stmmac: GMAC_RGSMIIIS reports bogus values

Hi Giuseppe, On Mon, 2016-11-14 at 09:14 +0100, Giuseppe CAVALLARO wrote: > Hello Alexey > > Sorry for my late reply. In that case, I think that the stmmac > is using own RGMII/SGMII support (PCS) to dialog with the > transceiver. I think, from the HW capability register > this feature is

  1   2   3   >