[PATCH net] tuntap: restore default qdisc

After commit f84bb1eac027 ("net: fix IFF_NO_QUEUE for drivers using alloc_netdev"), default qdisc was changed to noqueue because tuntap does not set tx_queue_len during .setup(). This patch restores default qdisc by setting tx_queue_len in tun_setup(). Fixes: f84bb1eac027 ("net: fix IFF_NO_QUEUE

[RFC PATCH v2 3/5] rtnl: add option for setting link bpf prog

Sets the bpf program represented by fd as an early filter in the rx path of the netdev. The fd must have been created as BPF_PROG_TYPE_PHYS_DEV. Providing a negative value as fd clears the program. Getting the fd back via rtnl is not possible, therefore reading of this value merely provides a bool

[RFC PATCH v2 4/5] mlx4: add support for fast rx drop bpf program

Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since bpf programs require a skb context to navigate the packet, build a percpu fake skb with the minimal fields. This avoids the costly allocation for packets that end up being dropped. Since mlx4 is so far the only user of

[RFC PATCH v2 2/5] net: add ndo to set bpf prog in adapter rx

Add two new set/get netdev ops for drivers implementing the BPF_PROG_TYPE_PHYS_DEV filter. Signed-off-by: Brenden Blanco --- include/linux/netdevice.h | 13 + net/core/dev.c| 38 ++ 2 files changed, 51

[RFC PATCH v2 1/5] bpf: add PHYS_DEV prog type for early driver filter

Add a new bpf prog type that is intended to run in early stages of the packet rx path. Only minimal packet metadata will be available, hence a new context type, struct bpf_phys_dev_md, is exposed to userspace. So far only expose the readable packet length, and only in read mode. The PHYS_DEV name

[RFC PATCH v2 5/5] Add sample for adding simple drop program to link

Add a sample program that only drops packets at the BPF_PROG_TYPE_PHYS_DEV hook of a link. With the drop-only program, observed single core rate is ~19.5Mpps. Other tests were run, for instance without the dropcnt increment or without reading from the packet header, the packet rate was mostly

[RFC PATCH v2 0/5] Add driver bpf hook for early packet drop

This patch set introduces new infrastructure for programmatically processing packets in the earliest stages of rx, as part of an effort others are calling Express Data Path (XDP) [1]. Start this effort by introducing a new bpf program type for early packet filtering, before even an skb has been

[PATCH net] mpls: find_outdev: check for err ptr in addition to NULL check

From: Roopa Prabhu find_outdev calls inet{,6}_fib_lookup_dev() or dev_get_by_index() to find the output device. In case of an error, inet{,6}_fib_lookup_dev() returns error pointer and dev_get_by_index() returns NULL. But the function only checks for NULL and thus can

[net-next 07/18] ixgbe: Add support for single-port X550 device

From: Mark Rustad Add support for a single-port X550 device. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher ---

[net-next 16/18] ixgbe: Add support for SGMII backplane interface

From: Mark Rustad Add support for an SGMII backplane interface. Signed-off-by: Mark Rustad Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +

[net-next 08/18] ixgbe: Add definitions for x550em_a 10G MAC

From: Mark Rustad Add definitions for a x550em_a 10G MAC device with a native SFP interface. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher ---

[net-next 17/18] ixgbe: Add KR backplane support for x550em_a

From: Mark Rustad Add support for x550em_a-based KR backplane devices. Signed-off-by: Mark Rustad Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 ++

[net-next 12/18] ixgbe: Read and set instance id

From: Mark Rustad Read the instance number from EEPROM and save it for later use. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher ---

[net-next 10/18] ixgbe: Add support for x550em_a 10G MAC type

From: Mark Rustad Add support for x550em_a 10G MAC type to the ixgbe driver. The new MAC includes new firmware commands that need to be used to control PHY and IOSF access, so that support is also added. The interface supported is a native SFP+ interface. Signed-off-by:

[net-next 13/18] ixgbe: Read and parse NW_MNG_IF_SEL register

From: Mark Rustad Read the IXGBE_NW_MNG_IF_SEL register and use it to set interface attributes. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher ---

[net-next 03/18] ixgbe: Correct length check for round up

From: Mark Rustad The function ixgbe_host_interface_command actually uses a multiple of word sized buffer to do its business, but only checks against the actual length passed in. This means that on read operations it could be possible to modify locations beyond the

[net-next 01/18] ixgbe: Delete some unused register definitions

From: Mark Rustad I noticed the SRAMREL registers are not referenced for any device, so delete the definitions. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher

[net-next 04/18] ixgbe: Clean up interface for firmware commands

From: Mark Rustad Clean up the interface for issuing firmware commands to use a void * instead of a u32 *. This eliminates a number of casts. Also clean up ixgbe_host_interface_command in a few other ways, eliminating comparisons with 0, redundant parens and minor

[net-next 14/18] ixgbe: Introduce function to control MDIO speed

From: Mark Rustad Move code that controls MDIO speed into a new function because there will be more MACs that need the control. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher

[net-next 15/18] ixgbe: Add support for SFPs with retimer

From: Mark Rustad Add support for SFPs with an external retimer. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher ---

[net-next 18/18] ixgbe: Bump version number

From: Mark Rustad Update ixgbe version number. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- 1

[net-next 05/18] ixgbe: Take manageability semaphore for firmware commands

From: Mark Rustad We need to take the manageability semaphore when issuing firmware commands to avoid problems. With this in place, the semaphore is no longer taken in the ixgbe_set_fw_drv_ver_generic function, since it will now always be taken by the

[net-next 06/18] ixgbe/ixgbevf: Add support for bulk free in Tx cleanup & cleanup boolean logic

From: Alexander Duyck This patch enables bulk free in Tx cleanup for ixgbevf and cleans up the boolean logic in the polling routines for ixgbe and ixgbevf in the hopes of avoiding any mix-ups similar to what occurred with i40e and i40evf. Signed-off-by: Alexander Duyck

[net-next 00/18][pull request] 10GbE Intel Wired LAN Driver Updates 2016-04-07

This series contains updates to ixgbe and ixgbevf. This entire series (except for one patch from Alex) comes from Mark and is mainly to add support for our new MAC (x550em_a). So let's get Alex's patch out of the way first before we cover Mark's many changes. Alex does his enable bulk free in

[net-next 11/18] ixgbe: Use new methods for PHY access

From: Mark Rustad Now x550em_a devices will use a new method for PHY access that will get the firmware token for each access. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher

[net-next 02/18] ixgbe: Change the lan_id and func fields to a u8 to avoid casts

From: Mark Rustad Since the lan_id and func fields only ever hold small values, make them u8 to avoid casts used to silence warnings. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher

[net-next 09/18] ixgbe: Use method pointer to access IOSF devices

From: Mark Rustad Provide method pointers and use them to access IOSF-attached devices. A new MAC will introduce a new access method. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher

Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption

On Thu, Apr 7, 2016 at 11:52 PM, Herbert Xu wrote: > On Wed, Apr 06, 2016 at 10:56:12AM -0700, Tadeusz Struk wrote: >> >> The intend is to enable HW acceleration of the TLS protocol. >> The way it will work is that the user space will send a packet of data >> via

Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption

On Wed, Apr 06, 2016 at 10:56:12AM -0700, Tadeusz Struk wrote: > > The intend is to enable HW acceleration of the TLS protocol. > The way it will work is that the user space will send a packet of data > via AF_ALG and HW will authenticate and encrypt it in one go. There have been suggestions to

Re: mpls's find_outdev()

On 4/7/16, 6:41 PM, David Miller wrote: > While auditing something unrelated, I noticed that this function seems > to potentially dev_put() on an error pointer. > > I guess the problem comes from the fact that there are two methods > by which the device pointer is obtained. > > First,

Re: [PATCH net] ipv6: Count in extension headers in skb->network_header

From: Jakub Sitnicki Date: Tue, 5 Apr 2016 18:41:08 +0200 > When sending a UDPv6 message longer than MTU, account for the length > of fragmentable IPv6 extension headers in skb->network_header offset. > Same as we do in alloc_new_skb path in __ip6_append_data(). > > This

RE: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: Joe Perches [mailto:j...@perches.com] > Sent: Friday, April 8, 2016 9:15 > On Thu, 2016-04-07 at 18:36 -0700, Dexuan Cui wrote: > > diff --git a/include/net/af_hvsock.h b/include/net/af_hvsock.h > [] > > +#define VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV (5 * PAGE_SIZE) > > +#define

Re: [PATCH V2 1/2] net: socket: return EADDRNOTAVAIL when source address becomes nonlocal

From: Liping Zhang Date: Tue, 5 Apr 2016 22:19:45 +0800 > From: Liping Zhang > > A socket can use bind(directly) or connect(indirectly) to bind to a local > ip address, and later if the network becomes down, that cause the source > address

mpls's find_outdev()

While auditing something unrelated, I noticed that this function seems to potentially dev_put() on an error pointer. I guess the problem comes from the fact that there are two methods by which the device pointer is obtained. First, inet{,6}_fib_lookup_dev() which uses error pointers. Second,

Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel()

Hi Kalle, On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 1 Jan 2016 19:09:32 +0100 > > Replace an explicit initialisation for one local variable at the beginning > by a conditional

Re: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

On Thu, 2016-04-07 at 18:36 -0700, Dexuan Cui wrote: > Hyper-V Sockets (hv_sock) supplies a byte-stream based communication > mechanism between the host and the guest. It's somewhat like TCP over > VMBus, but the transportation layer (VMBus) is much simpler than IP. [] > diff --git

[PATCH net-next] macvlan: Set nocarrier when lowerdev admin down

When the lowerdev is set administratively down disable carrier on the macvlan interface. This means operstate gets set properly instead of still being "up". Signed-off-by: Debabrata Banerjee --- drivers/net/macvlan.c | 6 +- 1 file changed, 5 insertions(+), 1

Re: [PATCH v2 net-next 00/10] allow bpf attach to tracepoints

Series applied, thanks Alexei.

Re: [PATCH net-next v2] macvlan: Support interface operstate properly

On 4/7/16, 7:05 AM, "Nikolay Aleksandrov" wrote: >On 04/07/2016 12:36 AM, Debabrata Banerjee wrote: >> Set appropriate macvlan interface status based on lower device and our >> status. Can be up, down, or lowerlayerdown. >What about dormant ? > >That being said I

Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

On Thu, Apr 07, 2016 at 04:43:47PM -0500, Timur Tabi wrote: > On my platform, firmware (UEFI) configures all of the GPIOs. I need > to get confirmation, but it appears that we don't actually make any > GPIO calls at all. I see code that looks like this: > > for (i = 0;

Re: [PATCH net-next v2] sock: make lockdep_sock_is_held inline and conditional on LOCKDEP

From: Hannes Frederic Sowa Date: Fri, 8 Apr 2016 01:35:18 +0200 > lockdep_is_held is only specified if CONFIG_LOCKDEP is defined, so make > it depending on it. > > Also add the missing inline keyword, so no warnings about unused functions > show up during

Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline

From: Hannes Frederic Sowa Date: Thu, 7 Apr 2016 23:53:35 +0200 > I forgot to add inline to lockdep_sock_is_held, so it generated all > kinds of build warnings if not build with lockdep support. > > Reported-by: kbuild test robot >

[PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

[PATCH v8 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

Re: [RFC PATCH 07/11] GENEVE: Add option to mangle IP IDs on inner headers when using TSO

On Thu, Apr 7, 2016 at 4:22 PM, Jesse Gross wrote: > On Thu, Apr 7, 2016 at 7:32 PM, Alexander Duyck wrote: >> This patch adds support for a feature I am calling IP ID mangling. It is >> basically just another way of saying the IP IDs that are transmitted

[PATCH net-next v2] sock: make lockdep_sock_is_held inline and conditional on LOCKDEP

lockdep_is_held is only specified if CONFIG_LOCKDEP is defined, so make it depending on it. Also add the missing inline keyword, so no warnings about unused functions show up during complilation. Cc: Eric Dumazet Cc: David Miller Signed-off-by:

Re: [RFC PATCH 07/11] GENEVE: Add option to mangle IP IDs on inner headers when using TSO

On Thu, Apr 7, 2016 at 7:32 PM, Alexander Duyck wrote: > This patch adds support for a feature I am calling IP ID mangling. It is > basically just another way of saying the IP IDs that are transmitted by the > tunnel may not match up with what would normally be expected.

Re: [PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled

On 08.04.2016 01:12, Hannes Frederic Sowa wrote: I need this to provide a generic lockdep_sock_is_held function which can be easily used in the kernel without using ifdef PROVEN macros. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Eric Dumazet

Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline

On 08.04.2016 01:08, Eric Dumazet wrote: On Fri, 2016-04-08 at 00:47 +0200, Hannes Frederic Sowa wrote: I see... hmpf. Wouldn't it be nicer if I include a helper a la: #define lockdep_is_held(lock) 1 in lockdep.h in case lockdep is globally not enabled? I do actually have already another

[PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled

I need this to provide a generic lockdep_sock_is_held function which can be easily used in the kernel without using ifdef PROVEN macros. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Eric Dumazet Cc: David Miller

[PATCH ipoute2] iplink: display number of rx/tx queues

From: Eric Dumazet We can set the attributes, so would be nice to display them when provided by the kernel. Signed-off-by: Eric Dumazet --- diff --git a/ip/ipaddress.c b/ip/ipaddress.c index 3998d8c..f7bd1c7 100644 --- a/ip/ipaddress.c +++

Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline

On Fri, 2016-04-08 at 00:47 +0200, Hannes Frederic Sowa wrote: > I see... hmpf. > > Wouldn't it be nicer if I include a helper a la: > > #define lockdep_is_held(lock) 1 > > in lockdep.h in case lockdep is globally not enabled? I do actually have > already another user for this outside of

Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline

On 08.04.2016 00:37, Eric Dumazet wrote: On Thu, 2016-04-07 at 15:30 -0700, Eric Dumazet wrote: But... this wont solve the compiler error ? include/net/sock.h: In function 'lockdep_sock_is_held': include/net/sock.h:1367:2: error: implicit declaration of function 'lockdep_is_held'

Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline

On Thu, 2016-04-07 at 15:30 -0700, Eric Dumazet wrote: > But... this wont solve the compiler error ? > > include/net/sock.h: In function 'lockdep_sock_is_held': > include/net/sock.h:1367:2: error: implicit declaration of function > 'lockdep_is_held' [-Werror=implicit-function-declaration] > In

[RFC PATCH 02/11] ethtool: Add support for toggling any of the GSO offloads

The strings were missing for several of the GSO offloads that are available. This patch provides the missing strings so that we can toggle or query any of them via the ethtool command. Signed-off-by: Alexander Duyck --- net/core/ethtool.c |2 ++ 1 file changed, 2

[RFC PATCH 07/11] GENEVE: Add option to mangle IP IDs on inner headers when using TSO

This patch adds support for a feature I am calling IP ID mangling. It is basically just another way of saying the IP IDs that are transmitted by the tunnel may not match up with what would normally be expected. Specifically what will happen is in the case of TSO the IP IDs on the headers will be

[RFC PATCH 11/11] igb/igbvf: Add support for GSO partial

This patch adds support for partial GSO segmentation in the case of encapsulated frames. Specifically with this change the driver can perform segmentation as long as the type is either SKB_GSO_TCP_FIXEDID or SKB_GSO_TCPV6. If neither of these gso types are specified then tunnel segmentation is

[RFC PATCH 01/11] GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU

This patch fixes an issue I found in which we were dropping frames if we had enabled checksums on GRE headers that were encapsulated by either FOU or GUE. Without this patch I was barely able to get 1 Gb/s of throughput. With this patch applied I am now at least getting around 6 Gb/s. The issue

[RFC PATCH 09/11] i40e/i40evf: Add support for GSO partial with UDP_TUNNEL_CSUM and GRE_CSUM

This patch makes it so that i40e and i40evf can use GSO_PARTIAL to support segmentation for frames with checksums enabled in outer headers. As a result we can now send data over these types of tunnels at over 20Gb/s versus the 12Gb/s that was previously possible on my system. The advantage with

[RFC PATCH 05/11] GSO: Support partial segmentation offload

This patch adds support for something I am referring to as GSO partial. The basic idea is that we can support a broader range of devices for segmentation if we use fixed outer headers and have the hardware only really deal with segmenting the inner header. The idea behind the naming is due to the

[RFC PATCH 04/11] GRO: Add support for TCP with fixed IPv4 ID field, limit tunnel IP ID values

This patch does two things. First it allows TCP to aggregate TCP frames with a fixed IPv4 ID field. As a result we should now be able to aggregate flows that were converted from IPv6 to IPv4. In addition this allows us more flexibility for future implementations of segmentation as we may be

[RFC PATCH 08/11] Documentation: Add documentation for TSO and GSO features

This document is a starting point for defining the TSO and GSO features. The whole thing is starting to get a bit messy so I wanted to make sure we have notes somwhere to start describing what does and doesn't work. Signed-off-by: Alexander Duyck ---

[RFC PATCH 10/11] ixgbe/ixgbevf: Add support for GSO partial

This patch adds support for partial GSO segmentation in the case of encapsulated frames. Specifically with this change the driver can perform segmentation as long as the type is either SKB_GSO_TCP_FIXEDID or SKB_GSO_TCPV6. If neither of these gso types are specified then tunnel segmentation is

[RFC PATCH 03/11] GSO: Add GSO type for fixed IPv4 ID

This patch adds support for TSO using IPv4 headers with a fixed IP ID field. This is meant to allow us to do a lossless GRO in the case of TCP flows that use a fixed IP ID such as those that convert IPv6 header to IPv4 headers. Signed-off-by: Alexander Duyck ---

[RFC PATCH 06/11] VXLAN: Add option to mangle IP IDs on inner headers when using TSO

This patch adds support for a feature I am calling IP ID mangling. It is basically just another way of saying the IP IDs that are transmitted by the tunnel may not match up with what would normally be expected. Specifically what will happen is in the case of TSO the IP IDs on the headers will be

[RFC PATCH 00/11] GSO partial and TSO FIXEDID support

This patch series represents my respun version of the GSO partial work. The major changes from the first version is that we are no longer making the decision to mangle IP IDs transparently at the device. Instead it is now pushed up to the tunnel layer itself so that the tunnel is not responsible

Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline

On Thu, 2016-04-07 at 23:53 +0200, Hannes Frederic Sowa wrote: > I forgot to add inline to lockdep_sock_is_held, so it generated all > kinds of build warnings if not build with lockdep support. > > Reported-by: kbuild test robot > Signed-off-by: Hannes Frederic Sowa

[PATCH net-next 0/2] fix two more udp pull header issues

From: Willem de Bruijn Follow up patches to the fixes to RxRPC and SunRPC. A scan of the code showed two other interfaces that expect UDP packets to have a udphdr when queued: read packet length with ioctl SIOCINQ and receive payload checksum with socket option IP_CHECKSUM.

[PATCH net-next 1/2] udp: do not expect udp headers on ioctl SIOCINQ

From: Willem de Bruijn On udp sockets, ioctl SIOCINQ returns the payload size of the first packet. Since commit e6afc8ace6dd pulled the headers, the result is incorrect when subtracting header length. Remove that operation. Fixes: e6afc8ace6dd ("udp: remove headers from UDP

[PATCH net-next 2/2] udp: do not expect udp headers in recv cmsg IP_CMSG_CHECKSUM

From: Willem de Bruijn On udp sockets, recv cmsg IP_CMSG_CHECKSUM returns a checksum over the packet payload. Since commit e6afc8ace6dd pulled the headers, taking skb->data as the start of transport header is incorrect. Use the transport header pointer. Also, when peeking at

Re: [net-next:master 194/196] include/net/sock.h:1367:9: error: implicit declaration of function 'lockdep_is_held'

On Thu, Apr 7, 2016, at 23:09, David Miller wrote: > From: kbuild test robot > Date: Fri, 8 Apr 2016 05:00:42 +0800 > > >include/net/sock.h: In function 'lockdep_sock_is_held': > >>> include/net/sock.h:1367:9: error: implicit declaration of function > >>>

[net-next:master 207/208] net/tipc/bearer.c:560:48: sparse: incompatible types in comparison expression (different base types)

tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master head: 889750bd2e08a94d52a116056d462b3a8e5616a7 commit: 5b7066c3dd24c7d538e5ee402eb24bb182c16dab [207/208] tipc: stricter filtering of packets in bearer layer reproduce: # apt-get install sparse

Re: [PATCH V2 5/8] net: mediatek: fix mtk_pending_work

Hi John, [auto build test ERROR on net-next/master] [also build test ERROR on v4.6-rc2 next-20160407] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/John-Crispin/net-mediatek-make-the-driver

[PATCH net-next] sock: make lockdep_sock_is_held static inline

I forgot to add inline to lockdep_sock_is_held, so it generated all kinds of build warnings if not build with lockdep support. Reported-by: kbuild test robot Signed-off-by: Hannes Frederic Sowa --- include/net/sock.h | 2 +- 1 file changed, 1

Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

Andrew Lunn wrote: I'm back to working on this driver, and I need some more help with how to handle the phy. mdio-gpio.txt doesn't really tell me much. I'm actually working on an ACPI system and not DT. I can help you with DT, but not ACPI. The MDIO bus can be a separate Linux device. Since

[net-next:master 194/208] include/net/sock.h:1363:13: error: 'lockdep_sock_is_held' defined but not used

tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master head: 889750bd2e08a94d52a116056d462b3a8e5616a7 commit: 1e1d04e678cf72442f57ce82803c7a407769135f [194/208] net: introduce lockdep_is_held and update various places to use it config: sparc64-allnoconfig (attached

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

David Miller wrote: > As you can with the function tracer and tracepoints. I've had experience with tracepoints before (i2c and smbus). It wasn't particularly fun. There's got to be some easier way to write them. Hmmm... Of the _enter() and _leave() macros in my tree at

Re: [RFC PATCH] possible bug in handling of ipv4 route caching

Hello, On Thu, 7 Apr 2016, Chris Friesen wrote: > Hi, > > We think we may have found a bug in the handling of ipv4 route caching, > and are curious what you think. > > For local routes that require a particular output interface we do not > want to cache the result. Caching the result

Re: [net-next:master 194/196] include/net/sock.h:1367:9: error: implicit declaration of function 'lockdep_is_held'

From: kbuild test robot Date: Fri, 8 Apr 2016 05:00:42 +0800 >include/net/sock.h: In function 'lockdep_sock_is_held': >>> include/net/sock.h:1367:9: error: implicit declaration of function >>> 'lockdep_is_held' [-Werror=implicit-function-declaration] > return

[net-next:master 194/196] include/net/sock.h:1367:9: error: implicit declaration of function 'lockdep_is_held'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master head: 1fbbe1a8a9b195c4ac856540dfaef49d663c2e91 commit: 1e1d04e678cf72442f57ce82803c7a407769135f [194/196] net: introduce lockdep_is_held and update various places to use it config: i386-tinyconfig (attached as

Re: [PATCH v2 net-next 04/10] perf, bpf: allow bpf programs attach to tracepoints

On Wed, Apr 06, 2016 at 06:43:25PM -0700, Alexei Starovoitov wrote: > introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be attached > to the perf tracepoint handler, which will copy the arguments into > the per-cpu buffer and pass it to the bpf program as its first argument. > The

Re: [PATCH net-next v3 0/2] tipc: some small fixes

From: Jon Maloy Date: Thu, 7 Apr 2016 10:09:12 -0400 > When fix a minor buffer leak, and ensure that bearers filter packets > correctly while they are being shut down. > > v2: Corrected typos in commit #3, as per feedback from S. Shtylyov > v3: Removed commit #3 from

Re: [PATCH v2 net-next 03/10] perf: split perf_trace_buf_prepare into alloc and update parts

On Wed, Apr 06, 2016 at 06:43:24PM -0700, Alexei Starovoitov wrote: > split allows to move expensive update of 'struct trace_entry' to later phase. > Repurpose unused 1st argument of perf_tp_event() to indicate event type. > > While splitting use temp variable 'rctx' instead of '*rctx' to avoid >

Re: [net PATCH v3] GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU

From: Alexander Duyck Date: Tue, 05 Apr 2016 09:13:39 -0700 > This patch fixes an issue I found in which we were dropping frames if we > had enabled checksums on GRE headers that were encapsulated by either FOU > or GUE. Without this patch I was barely able to get 1 Gb/s of

Re: [PATCH v2 net-next 02/10] perf: remove unused __addr variable

On Wed, Apr 06, 2016 at 06:43:23PM -0700, Alexei Starovoitov wrote: > now all calls to perf_trace_buf_submit() pass 0 as 4th > argument which will be repurposed in the next patch which will > change the meaning of 1st arg of perf_tp_event() to event_type > > Signed-off-by: Alexei Starovoitov

Re: [PATCH net-next 0/8] udp: GRO in UDP sockets

From: Tom Herbert Date: Tue, 5 Apr 2016 08:22:48 -0700 > This patch set adds GRO functions (gro_receive and gro_complete) to UDP > sockets and removes udp_offload infrastructure. > > Add GRO functions (gro_receive and gro_complete) to UDP sockets. In > udp_gro_receive and

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

From: David Howells Date: Thu, 07 Apr 2016 21:47:19 +0100 > David Miller wrote: > >> > Excellent only if I can get at it to find out why the something went wrong. >> > If it's lost because the machine panics, then it is worthless. >> >> If you're ok

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

David Miller wrote: > > Excellent only if I can get at it to find out why the something went wrong. > > If it's lost because the machine panics, then it is worthless. > > If you're ok with these kenter things spewing into the logs with the > current facility, you can run

Re: [PATCH v2 net-next 00/10] allow bpf attach to tracepoints

From: Alexei Starovoitov Date: Wed, 6 Apr 2016 18:43:21 -0700 > Hi Steven, Peter, Steven/Peter, can you give this series a review? Thanks!

Re: [PATCH net-next 0/3] sock: lockdep tightening

From: Hannes Frederic Sowa Date: Tue, 5 Apr 2016 17:10:13 +0200 > First patch is from Eric Dumazet and improves lockdep accuracy for > socket locks. After that, second patch introduces lockdep_sock_is_held > and uses it. Final patch reverts and reworks the lockdep

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

Joe Perches wrote: > > Let's see...  If the machine panics whilst I'm developing stuff (quite > > likely if something goes wrong in BH context), how do I get at the > > function tracing log to find out why it panicked if the log is then > > lost?  With the serial console, at

Re: [Lsf] [LSF/MM TOPIC] Generic page-pool recycle facility?

On Thu, 7 Apr 2016 19:48:50 + "Waskiewicz, PJ" wrote: > On Thu, 2016-04-07 at 16:17 +0200, Jesper Dangaard Brouer wrote: > > (Topic proposal for MM-summit) > > > > Network Interface Cards (NIC) drivers, and increasing speeds stress > > the page-allocator (and DMA

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

From: David Howells Date: Thu, 07 Apr 2016 20:45:08 +0100 > David Miller wrote: > >> Yeah this custom stuff is really inappropriate given the excellent >> infrastructure we have these days... > > Excellent only if I can get at it to find out why the

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

On Thu, 2016-04-07 at 20:43 +0100, David Howells wrote: > Joe Perches wrote: > > > Joe Perches wrote: > > > > It might be better to remove kenter and _enter > > > > altogether and use function tracing instead. > > > Possibly - but not at this time. > > Swell.

Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

> I'm back to working on this driver, and I need some more help with > how to handle the phy. mdio-gpio.txt doesn't really tell me much. > I'm actually working on an ACPI system and not DT. I can help you with DT, but not ACPI. The MDIO bus can be a separate Linux device. Since you have GPIO

Re: [Lsf] [LSF/MM TOPIC] Generic page-pool recycle facility?

On Thu, 2016-04-07 at 16:17 +0200, Jesper Dangaard Brouer wrote: > (Topic proposal for MM-summit) > > Network Interface Cards (NIC) drivers, and increasing speeds stress > the page-allocator (and DMA APIs).  A number of driver specific > open-coded approaches exists that work-around these

Re: [PATCH V2 6/8] net: mediatek: fix TX locking

Hello. On 04/07/2016 10:26 PM, John Crispin wrote: Inside the TX path there is a lock inside the tx_map function. This is however too late. The patch moves the lock to the start of the xmit function right before the free count check of the DMA ring happens. If we do not do this, the code

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

David Miller wrote: > Yeah this custom stuff is really inappropriate given the excellent > infrastructure we have these days... Excellent only if I can get at it to find out why the something went wrong. If it's lost because the machine panics, then it is worthless. David

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

Joe Perches wrote: > > Joe Perches wrote: > > > It might be better to remove kenter and _enter > > > altogether and use function tracing instead. > > Possibly - but not at this time. > > Swell. I didn't say I wouldn't do it - it's just that I'm trying to

Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?

On Thu, 07 Apr 2016 12:14:00 -0400 Rik van Riel wrote: > On Thu, 2016-04-07 at 08:48 -0700, Chuck Lever wrote: > > > > > > On Apr 7, 2016, at 7:38 AM, Christoph Hellwig > > > wrote: > > > > > > This is also very interesting for storage targets, which face

  1   2   3   >