Re: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name

On Sat, May 14, 2016 at 03:21:31PM -0700, Linus Torvalds wrote: > On Sat, May 14, 2016 at 2:33 PM, Willy Tarreau wrote: > > > > Why simply not cast the atomic to (unsigned long long) instead of (u64) > > so that %llu always matches ? > > Yes, that fixes the problem. It's just more

[net-next 11/13] i40e: don't add broadcast filter for VFs

From: Mitch Williams Now that all VSIs are configured to receive broadcasts as default, we don't need to add a filter. This eliminates an annoying but harmless error message each time VFs are created or reset. Change-ID: I4cd6339684df45b0d2722133eeb84c14fa93ea19

[net-next 01/13] i40e: Add support for disabling all link and change bits needed for PHY interactions

From: Kevin Scott Add flag to tell firmware to disable link on all ports. This patch changes the bits set for telling firmware the PHY needs to be modified by driver. Without this patch, the setting will only set that mode for the current port on the device. Because

[net-next 03/13] i40e: Implement the API function for aq_set_switch_config

From: Shannon Nelson Add the support code for calling the AdminQ API call aq_set_switch_config Signed-off-by: Shannon Nelson Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher ---

[net-next 13/13] i40e: fix an uninitialized variable bug

From: Dan Carpenter We removed this initialization but it is required. Let's put it back. Fixes: 895106a577c4 ('i40e: trivial fixes') Signed-off-by: Dan Carpenter Tested-by: Andrew Bowers Signed-off-by: Jeff

[net-next 09/13] i40e: set context to use VSI RSS LUT for SR-IOV

From: Ashish Shah For the SR-IOV VSIs, when the queue filtering section is valid, the RSS LUT needs to be set to use the VSI specific lookup table (otherwise it will use the PF RSS LUT table). Change-ID: Ia9377cc818078238a75c3bdeade1b593a91b3480 Signed-off-by: Ashish

[net-next 12/13] i40e: Bump version from 1.5.10 to 1.5.16

From: Bimmy Pujari Signed-off-by: Bimmy Pujari Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +- 1 file changed, 1 insertion(+), 1

[net-next 07/13] i40e: change Rx hang message into a WARN_ONCE

From: Jacob Keller Use WARN_ONCE in order to highlight the issue, but don't display a warning every time. The user should be able to see the ethtool counter we created if necessary to see how often it is occurring. Change-ID: I40c4ea159819b64a7d33b7f5716749089791533a

[net-next 10/13] i40e/i40evf: properly report Rx packet hash

From: Mitch Williams This logic is inverted. If the RXHASH flag is set, then we should go ahead and call skb_set_hash. Change-ID: Ib2e30356dced1d3e939c8061ab6ad5bd94197e7c Signed-off-by: Mitch Williams Tested-by: Andrew Bowers

[net-next 02/13] i40e: Add allmulti support for the VF

From: Anjali Singhai Jain This patch enables a feature to enable/disable all multicast for a trusted VF. Change-Id: I926eba7f8850c8d40f8ad7e08bbe4056bbd3985f Signed-off-by: Anjali Singhai Jain Tested-by: Andrew Bowers

[net-next 06/13] i40e: Refactor ethtool get_settings

From: Catherine Sullivan Previously we were only looking at the FW supported PHY types if link was down, because we want to be more specific when link is up. This refactor changes this. When link is down, we still rely on the FW supported PHY types, but when link is

[net-next 08/13] i40e: Correct UDP packet header for non_tunnel-ipv6

From: Akeem G Abodunrin This patch corrects Rx ptype payload layer for non_tunneled ipv6. It should be layer 4 for UDP, instead of layer 3. Change-ID: I9382e4458ab3c4e58f6d2e9f195d5d4ee513805e Signed-off-by: Akeem G Abodunrin Tested-by:

[net-next 05/13] i40e: lie to the VF

From: Mitch Williams If an untrusted VF attempts to configure promiscuous mode, log a message pointing out its naughty behavior. But then, instead of returning an error to the offender, just lie to it and say everything's OK. It will continue on its way, thinking it's

[net-next 04/13] i40e: Add vf-true-promisc-support priv flag

From: Anjali Singhai Jain This patch adds priv-flag knob to configure global true promisc support. With this patch the user can decide the flavor of promiscuous that the VFs will see when promiscuous mode is enabled on the interface. Since this a global setting for the

[net-next 00/13][pull request] 40GbE Intel Wired LAN Driver Updates 2016-05-14

This series contains updates to i40e and i40evf. Kevin adds support to disable link on all ports and changes bits set for telling firmware the PHY needs to be modified by the driver. Anjali adds a feature to enable/disable all multicast for a trusted VF. Added priv-flag knob to configure global

Re: [patch net-next 1/4] netdevice: add SW statistics ndo

On 5/14/16, 11:46 AM, Jiri Pirko wrote: > Sat, May 14, 2016 at 05:47:41PM CEST, ro...@cumulusnetworks.com wrote: >> On 5/14/16, 5:49 AM, Jiri Pirko wrote: >>> Fri, May 13, 2016 at 08:47:48PM CEST, ro...@cumulusnetworks.com wrote: [snip] Jiri Pirko ---

Re: [PATCH nf V2] netfilter: fix oops in nfqueue during netns error unwinding

Florian Westphal writes: > Eric W. Biederman wrote: >> Florian Westphal writes: >> >> > Eric W. Biederman wrote: >> >> Florian could you test and verify this patch fixes your issues? >> > >> > Yes, this seems to

Re: BUG: net/tipc: NULL-ptr dereference in tipc_nl_publ_dump

On 2016/5/15 1:13, Eric Dumazet wrote: On Sat, 2016-05-14 at 23:22 +0800, Baozeng Ding wrote: Hello all, The following program triggers NULL-ptr dereference in tipc_nl_publ_dump. The kernel version is 4.6.0-rc7+ (on May 13 commit 1410b74e4061e05a5d2bffb1f99829efce27c8a9). Thanks.

Re: What ixgbe devices support HWTSTAMP_FILTER_ALL for hardware time stamping?

On May 14, 2016, at 1:26 PM, Richard Cochran wrote: > On Sat, May 14, 2016 at 11:47:22AM -0700, Guy Harris wrote: >> So if you have a GUI application for packet capture, with a combo box to >> select the type of time stamping, should it: >> >> 1) regardless of

Re: [PATCH net-next 2/9] bnxt_en: Add Support for ETHTOOL_GMODULEINFO and ETHTOOL_GMODULEEEPRO

On Sat, 2016-05-14 at 20:29 -0400, Michael Chan wrote: > From: Ajit Khaparde [...] > + /* Read A2 portion of the EEPROM */ > + if (length) { > + start -= ETH_MODULE_SFF_8436_LEN; > + bnxt_read_sfp_module_eeprom_info(bp, I2C_DEV_ADDR_A2,

[PATCH net-next 6/9] bnxt_en: Fix length value in dmesg log firmware error message.

The len value in the hwrm error message is wrong. Use the properly adjusted value in the variable len. Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH net-next 7/9] bnxt_en: Simplify and improve unsupported SFP+ module reporting.

The current code is more complicated than necessary and can only report unsupported SFP+ module if it is plugged in after the device is up. Rename bnxt_port_module_event() to bnxt_get_port_module_status(). We already have the current module_status in the link_info structure, so just check that

[PATCH net-next 3/9] bnxt_en: Report PCIe link speed and width during driver load

From: Ajit Khaparde Add code to log a message during driver load indicating PCIe link speed and width. The log message will look like this: bnxt_en :86:00.0 eth0: PCIe: Speed 8.0GT/s Width x8 Signed-off-by: Ajit Khaparde

[PATCH net-next 9/9] bnxt_en: Use dma_rmb() instead of rmb().

Use the weaker but more appropriate dma_rmb() to order the reading of the completion ring. Suggested-by: Ajit Khaparde Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH net-next 1/9] bnxt_en: Fix invalid max channel parameter in ethtool -l.

From: Satish Baddipadige When there is only 1 MSI-X vector or in INTA mode, tx and rx pre-set max channel parameters are shown incorrectly in ethtool -l. With only 1 vector, bnxt_get_max_rings() will return -ENOMEM. bnxt_get_channels should check this return value, and

[PATCH net-next 4/9] bnxt_en: Reduce maximum ring pages if page size is 64K.

The chip supports 4K/8K/64K page sizes for the rings and we try to match it to the CPU PAGE_SIZE. The current page size limits for the rings are based on 4K/8K page size. If the page size is 64K, these limits are too large. Reduce them appropriately. Signed-off-by: Michael Chan

[PATCH net-next 8/9] bnxt_en: Add BCM57314 device ID.

Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c index 6def145..f2ac7da 100644 ---

[PATCH net-next 5/9] bnxt_en: Improve the delay logic for firmware response.

The current code has 2 problems: 1. The maximum wait time is not long enough. It is about 60% of the duration specified by the firmware. It is calling usleep_range(600, 800) for every 1 msec we are supposed to wait. 2. The granularity of the delay is too coarse. Many simple firmware commands

[PATCH net-next 2/9] bnxt_en: Add Support for ETHTOOL_GMODULEINFO and ETHTOOL_GMODULEEEPRO

From: Ajit Khaparde Add support to fetch the SFP EEPROM settings from the firmware and display it via the ethtool -m command. We support SFP+ and QSFP modules. Signed-off-by: Ajit Khaparde Signed-off-by: Michael Chan

[PATCH net-next 0/9] bnxt_en: updates for net-next.

Non-critical bug fixes, improvements, a new ethtool feature, and a new device ID. Michael Chan (9): bnxt_en: Fix invalid max channel parameter in ethtool -l. bnxt_en: Add Support for ETHTOOL_GMODULEINFO and ETHTOOL_GMODULEEEPRO bnxt_en: Report PCIe link speed and width during driver load

Re: [PATCH] ethernet:arc: Fix racing of TX ring buffer

Sorry, the last two lines is wrong, ignore it. I mean I intended to ignore one or two packets. It's just a trade-off for performance, but it doesn't cause any memory leak.

Re: [PATCH] ethernet:arc: Fix racing of TX ring buffer

On Sat, May 14, 2016 at 10:03:56PM +0200, Francois Romieu wrote: > Shuyu Wei : > > The tail of the ring buffer(txbd_dirty) should never go ahead of the > > head(txbd_curr) or the ring buffer will corrupt. > > > > This is the root cause of racing. > > No (see below). > > It

Re: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name

On Sat, May 14, 2016 at 2:33 PM, Willy Tarreau wrote: > > Why simply not cast the atomic to (unsigned long long) instead of (u64) > so that %llu always matches ? Yes, that fixes the problem. It's just more typing, and annoying. The fact that MS got it right while posix and gcc

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/14/2016 10:50 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual

Re: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name

On Sat, May 14, 2016 at 02:31:04PM -0700, Linus Torvalds wrote: > On Sat, May 14, 2016 at 11:24 AM, Linus Torvalds > wrote: > > > > > > - net->ct.slabname = kasprintf(GFP_KERNEL, "nf_conntrack_%p", net); > > + net->ct.slabname = kasprintf(GFP_KERNEL,

Re: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name

On Sat, May 14, 2016 at 11:24 AM, Linus Torvalds wrote: > > > - net->ct.slabname = kasprintf(GFP_KERNEL, "nf_conntrack_%p", net); > + net->ct.slabname = kasprintf(GFP_KERNEL, "nf_conntrack_%llu", > +

Re: [PATCH net-next] net: switchdev: Drop EXPERIMENTAL from description

From: Florian Fainelli Date: Sat, 14 May 2016 12:49:54 -0700 > Switchdev has been around for quite a while now, putting "EXPERIMENTAL" > in the description is no longer accurate, drop it. > > Signed-off-by: Florian Fainelli Yeah this is long

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 10:18 PM, Sergei Shtylyov wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus

[PATCH v2] r8169: default to 64-bit DMA on recent PCIe chips

The current logic around the 'use_dac' module parameter prevents the r81969 driver from being loadable on 64-bit systems without any RAM below 4 GB when the parameter is left at its default value. So introduce a new default value -1 which indicates that 64-bit DMA should be enabled on

Re: What ixgbe devices support HWTSTAMP_FILTER_ALL for hardware time stamping?

On Sat, May 14, 2016 at 11:47:22AM -0700, Guy Harris wrote: > So if you have a GUI application for packet capture, with a combo box to > select the type of time stamping, should it: > > 1) regardless of whether ETHTOOL_GET_TS_INFO is available, open the > adapter, try each of the time

Re: [PATCH net-next] net: switchdev: Drop EXPERIMENTAL from description

Sat, May 14, 2016 at 09:49:54PM CEST, f.faine...@gmail.com wrote: >Switchdev has been around for quite a while now, putting "EXPERIMENTAL" >in the description is no longer accurate, drop it. > >Signed-off-by: Florian Fainelli Acked-by: Jiri Pirko

[GIT] Networking

1) Fix mvneta/bm dependencies, from Arnd Bergmann. 2) RX completion hw bug workaround in bnxt_en, from Michael Chan. 3) Kernel pointer leak in nf_conntrack, from Linus. 4) Hoplimit route attribute limits not enforced properly, from Paolo Abeni. 5) qlcnic driver NULL deref fix from Dan

Re: [PATCH] arm64: bpf: jit JMP_JSET_{X,K}

From: Will Deacon Date: Fri, 13 May 2016 11:03:07 +0100 > On Fri, May 13, 2016 at 10:57:18AM +0100, Will Deacon wrote: >> On Thu, May 12, 2016 at 11:37:58PM -0700, Zi Shen Lim wrote: >> > Original implementation commit e54bcde3d69d ("arm64: eBPF JIT compiler") >> > had the

Re: [PATCH] ethernet:arc: Fix racing of TX ring buffer

Shuyu Wei : > The tail of the ring buffer(txbd_dirty) should never go ahead of the > head(txbd_curr) or the ring buffer will corrupt. > > This is the root cause of racing. No (see below). It may suffer from some barrier illness though. > Besides, setting the FOR_EMAC flag

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Sat, May 14, 2016 at 10:36:38PM +0300, Sergei Shtylyov wrote: > Hello. > > On 05/14/2016 02:44 AM, Andrew Lunn wrote: > > >Another issue is that on some boards we have one reset line tied to > >multiple PHYs.How do we prevent multiple resets being taking place when > >each of >

[PATCH net-next] net: switchdev: Drop EXPERIMENTAL from description

Switchdev has been around for quite a while now, putting "EXPERIMENTAL" in the description is no longer accurate, drop it. Signed-off-by: Florian Fainelli --- net/switchdev/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/switchdev/Kconfig

Re: QRTR merge conflict resolution (was: Re: linux-next: build failure after merge of the net-next tree)

On Friday 13 May 2016 17:47:17 Andy Gross wrote: > On 13 May 2016 at 17:19, Bjorn Andersson wrote: > > On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote: > > > >> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote: > > [..] > >> > I assume we could have the QRTR go

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/14/2016 02:44 AM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the

Re: [PATCH net] net/route: enforce hoplimit max value

From: Paolo Abeni Date: Fri, 13 May 2016 18:33:41 +0200 > Currently, when creating or updating a route, no check is performed > in both ipv4 and ipv6 code to the hoplimit value. > > The caller can i.e. set hoplimit to 256, and when such route will > be used, packets will be

Re: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name

From: Linus Torvalds Date: Sat, 14 May 2016 11:24:08 -0700 (PDT) > > From: Linus Torvalds > Date: Sat, 14 May 2016 11:11:44 -0700 > Subject: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name > > The slab name ends

Re: [PATCH] r8169: default to 64-bit DMA on recent PCIe chips

From: Ard Biesheuvel Date: Sat, 14 May 2016 14:08:54 +0200 > The reordering above is actually unnecessary, it crept in inadvertently. Then post a new version of the patch without it.

Re: What ixgbe devices support HWTSTAMP_FILTER_ALL for hardware time stamping?

On May 14, 2016, at 12:41 AM, Jeff Kirsher wrote: > Are you planning to produce a patch or are you wanting us to do the work to > fix the issue? Just asking so that work is not duplicated. I'm willing to produce the patches, although 1) I don't currently have a

Re: What ixgbe devices support HWTSTAMP_FILTER_ALL for hardware time stamping?

On May 14, 2016, at 12:30 AM, Richard Cochran wrote: > On Fri, May 13, 2016 at 04:12:52PM -0700, Guy Harris wrote: >> The Linux implementation currently implements the inquiry by doing a >> ETHTOOL_GET_TS_INFO SIOETHTOOL ioctl and looking at the >> so_timestamping bits,

Re: [patch net-next 1/4] netdevice: add SW statistics ndo

Sat, May 14, 2016 at 05:47:41PM CEST, ro...@cumulusnetworks.com wrote: >On 5/14/16, 5:49 AM, Jiri Pirko wrote: >> Fri, May 13, 2016 at 08:47:48PM CEST, ro...@cumulusnetworks.com wrote: >>> On 5/12/16, 11:03 PM, Jiri Pirko wrote: Thu, May 12, 2016 at 11:10:08PM CEST, ro...@cumulusnetworks.com

Re: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name

On Sat, 2016-05-14 at 11:24 -0700, Linus Torvalds wrote: > From: Linus Torvalds > Date: Sat, 14 May 2016 11:11:44 -0700 > Subject: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name > > The slab name ends up being visible in the directory structure

[PATCH] nf_conntrack: avoid kernel pointer value leak in slab name

From: Linus Torvalds Date: Sat, 14 May 2016 11:11:44 -0700 Subject: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name The slab name ends up being visible in the directory structure under /sys, and even if you don't have access rights to the file

Re: BUG: net/tipc: NULL-ptr dereference in tipc_nl_publ_dump

On Sat, 2016-05-14 at 23:22 +0800, Baozeng Ding wrote: > Hello all, > The following program triggers NULL-ptr dereference in > tipc_nl_publ_dump. The kernel version is 4.6.0-rc7+ (on May 13 commit > 1410b74e4061e05a5d2bffb1f99829efce27c8a9). Thanks. >

Re: [v4.6-rc7-183-g1410b74e4061]

On Sat, May 14, 2016 at 2:22 AM, Sedat Dilek wrote: > Hi, > > as Linux v4.6 is very near, I decided to write this bug report (only > drunk one coffee). > > First, I am not absolutely sure if this is a real issue as... > #1: This is only a (lockdep) warning. > #2: I have not

[PATCH] ethernet:arc: Fix racing of TX ring buffer

The tail of the ring buffer(txbd_dirty) should never go ahead of the head(txbd_curr) or the ring buffer will corrupt. This is the root cause of racing. Besides, setting the FOR_EMAC flag should be the last step of modifying the buffer descriptor, or possible racing will occur. Signed-off-by:

Re: [patch net-next 1/4] netdevice: add SW statistics ndo

On 5/14/16, 5:49 AM, Jiri Pirko wrote: > Fri, May 13, 2016 at 08:47:48PM CEST, ro...@cumulusnetworks.com wrote: >> On 5/12/16, 11:03 PM, Jiri Pirko wrote: >>> Thu, May 12, 2016 at 11:10:08PM CEST, ro...@cumulusnetworks.com wrote: On 5/12/16, 4:48 AM, Jiri Pirko wrote: > From: Nogah

Re: [linux-next: May 13] intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage

On (05/15/16 01:31), Sergey Senozhatsky wrote: > [11455.550649] === > [11455.550652] [ INFO: suspicious RCU usage. ] > [11455.550657] 4.6.0-rc7-next-20160513-dbg-4-g8de8b92-dirty #655 Not > tainted > [11455.550660] --- > [11455.550664]

[linux-next: May 13] intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage

Hello, [11455.550649] === [11455.550652] [ INFO: suspicious RCU usage. ] [11455.550657] 4.6.0-rc7-next-20160513-dbg-4-g8de8b92-dirty #655 Not tainted [11455.550660] --- [11455.550664] drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:1069

BUG: net/tipc: NULL-ptr dereference in tipc_nl_publ_dump

Hello all, The following program triggers NULL-ptr dereference in tipc_nl_publ_dump. The kernel version is 4.6.0-rc7+ (on May 13 commit 1410b74e4061e05a5d2bffb1f99829efce27c8a9). Thanks. -- netlink: 1 bytes leftover

IT- Desk Service Desk

IT@MAIL Password will expire in 3 days To keep your password active. Click Here to update IT- Desk Service Desk "This message originates from Eastern Connecticut Health Network. The information contained in this message may be

[iproute2 net-next repost 2/2] devlink: implement shared buffer occupancy control

From: Jiri Pirko Use kernel shared buffer occupancy control commands to make snapshot and clear occupancy watermarks. Also, allow to show occupancy values in a nice way. Signed-off-by: Jiri Pirko --- devlink/devlink.c | 378

[iproute2 net-next repost 1/2] devlink: implement shared buffer support

From: Jiri Pirko Implement kernel devlink shared buffer interface. Introduce new object "sb" and allow to browse the shared buffer parameters and also change configuration. Signed-off-by: Jiri Pirko --- devlink/devlink.c | 653

Re: [patch net-next 1/4] netdevice: add SW statistics ndo

Fri, May 13, 2016 at 08:47:48PM CEST, ro...@cumulusnetworks.com wrote: >On 5/12/16, 11:03 PM, Jiri Pirko wrote: >> Thu, May 12, 2016 at 11:10:08PM CEST, ro...@cumulusnetworks.com wrote: >>> On 5/12/16, 4:48 AM, Jiri Pirko wrote: From: Nogah Frankel Till now we

Re: [PATCH] r8169: default to 64-bit DMA on recent PCIe chips

On 14 May 2016 at 12:41, Ard Biesheuvel wrote: > The current logic around the 'use_dac' module parameter prevents the > r81969 driver from being loadable on 64-bit systems without any RAM > below 4 GB when the parameter is left at its default value. > > So introduce a

pull request: bluetooth-next 2016-05-14

Hi Dave, Here are two more Bluetooth patches for the 4.7 kernel which we wanted to get into net-next before the merge window opens. Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit ed7cbbce544856b20e5811de373cf92e92499771: udp: Resolve

[PATCH] r8169: default to 64-bit DMA on recent PCIe chips

The current logic around the 'use_dac' module parameter prevents the r81969 driver from being loadable on 64-bit systems without any RAM below 4 GB when the parameter is left at its default value. So introduce a new default value -1 which indicates that 64-bit DMA should be enabled on

Re: [PATCH nf V2] netfilter: fix oops in nfqueue during netns error unwinding

Eric W. Biederman wrote: > Florian Westphal writes: > > > Eric W. Biederman wrote: > >> Florian could you test and verify this patch fixes your issues? > > > > Yes, this seems to work. > > > > Pablo, I'm fine with this patch going

[PATCH] mac80211_hwsim: Allow wmediumd to attach to radios created in its netns

Registering wmediumd is currently limited to the initial network namespace. This patch enables wmediumd to attach from non-initial network namespaces using a user namespace having CAP_NET_ADMIN. A registered wmediumd can forward frames on radios that have been created in the same network

Re: What ixgbe devices support HWTSTAMP_FILTER_ALL for hardware time stamping?

On Fri, 2016-05-13 at 16:12 -0700, Guy Harris wrote: > libpcap offers the ability to request hardware time stamping for packets > and to inquire which forms of hardware time stamping, if any, are > supported for an interface. > > The Linux implementation currently implements the inquiry by doing

Re: What ixgbe devices support HWTSTAMP_FILTER_ALL for hardware time stamping?

On Fri, May 13, 2016 at 04:12:52PM -0700, Guy Harris wrote: > The Linux implementation currently implements the inquiry by doing a > ETHTOOL_GET_TS_INFO SIOETHTOOL ioctl and looking at the > so_timestamping bits, if the linux/ethtool.h header defines > ETHTOOL_GET_TS_INFO and the ioctl succeeds on