Re: "rfkill: Add rfkill-any LED trigger" causes deadlock

> Just to ensure things get cleaned up properly, as of now it looks > like you only reverted patch 2/2 of my v2 and Arnd's fix to patch > 1/2, not patch 1/2 itself. Oops. I've fixed that up to only revert your patch - I wanted the revert in the tree to document the issue, rather than just

[PATCHv2 net 2/2] sctp: not copying duplicate addrs to the assoc's bind address list

sctp.local_addr_list is a global address list that is supposed to include all the local addresses. sctp updates this list according to NETDEV_UP/ NETDEV_DOWN notifications. However, if multiple NICs have the same address, the global list would have duplicate addresses. Even if for one NIC,

[PATCHv2 net 0/2] fix the issue that may copy duplicate addrs into assoc's bind address list

Patch 1/2 is to fix some indent level. Given that we have kernels out there with this issue, patch 2/2 also fix sctp_raw_to_bind_addrs. v1 -> v2: Explain why we didn't filter the duplicate addresses when global address list gets updated in patch 2/2 changelog. Xin Long (2): sctp: reduce

[PATCHv2 net 1/2] sctp: reduce indent level in sctp_copy_local_addr_list

This patch is to reduce indent level by using continue when the addr is not allowed, and also drop end_copy by using break. Signed-off-by: Xin Long --- net/sctp/protocol.c | 37 +++-- 1 file changed, 19 insertions(+), 18 deletions(-) diff

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 09:27:18PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 8:44 PM, Alexei Starovoitov > wrote: > > On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: > >> > >> struct cgroup_bpf { > >> /* > >> * Store

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 8:44 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: >> >> struct cgroup_bpf { >> /* >> * Store two sets of bpf_prog pointers, one for programs that are >> * pinned

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 8:51 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 05:40:53PM -0800, Andy Lutomirski wrote: >> >> By the way, even if Alexei is right, the BPF_PROG_DETACH API doesn't >> even take a reference to a BPF program as an argument. What is

Re: Soft lockup in inet_put_port on 4.6

> On Dec 19, 2016, at 11:52 PM, Eric Dumazet wrote: > > On Tue, 2016-12-20 at 03:40 +, Josef Bacik wrote: >>> On Dec 19, 2016, at 9:42 PM, Eric Dumazet wrote: >>> On Mon, 2016-12-19 at 18:07 -0800, Tom Herbert wrote: When

Re: Soft lockup in inet_put_port on 4.6

On Tue, 2016-12-20 at 03:40 +, Josef Bacik wrote: > > On Dec 19, 2016, at 9:42 PM, Eric Dumazet wrote: > > > >> On Mon, 2016-12-19 at 18:07 -0800, Tom Herbert wrote: > >> > >> When sockets created SO_REUSEPORT move to TW state they are placed > >> back on the the

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 05:40:53PM -0800, Andy Lutomirski wrote: > > By the way, even if Alexei is right, the BPF_PROG_DETACH API doesn't > even take a reference to a BPF program as an argument. What is it > supposed to do if this mechanism ever gets extended? we just add another field to that

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 07:50:01PM -0800, Andy Lutomirski wrote: > >> > >> net.socket_create_filter = "none": no filter > >> net.socket_create_filter = "bpf:baadf00d": bpf filter > > > > i'm assuming 'baadf00d' is bpf program fd expressed a text string? > > and kernel needs to parse above? will

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: > > struct cgroup_bpf { > /* > * Store two sets of bpf_prog pointers, one for programs that are > * pinned directly to this cgroup, and one for those that are > effective > * when this cgroup is

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 7:18 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 04:25:32PM -0800, Andy Lutomirski wrote: >> I think we're still talking past each other. A big part of the point >> of changing it is that none of this is specific to bpf. You

Re: [PATCH v2 2/3] Bluetooth: btusb: Add out-of-band wakeup support

On Mon, Dec 19, 2016 at 05:46:19PM -0800, Rajat Jain wrote: > On Mon, Dec 19, 2016 at 3:10 PM, Brian Norris > wrote: > > On Fri, Dec 16, 2016 at 11:30:03AM -0800, Rajat Jain wrote: > >> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c > >> index

Re: Soft lockup in inet_put_port on 4.6

> On Dec 19, 2016, at 9:42 PM, Eric Dumazet wrote: > >> On Mon, 2016-12-19 at 18:07 -0800, Tom Herbert wrote: >> >> When sockets created SO_REUSEPORT move to TW state they are placed >> back on the the tb->owners. fastreuse port is no longer set so we have >> to walk

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 04:25:32PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov > wrote: > > On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: > >> On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov > >>

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 6:52 PM, David Ahern wrote: > On 12/19/16 6:56 PM, Andy Lutomirski wrote: >> On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: >>> On 12/19/16 5:25 PM, Andy Lutomirski wrote: net.socket_create_filter = "none": no filter

[PATCH v3 1/3] Bluetooth: btusb: Use an error label for error paths

Use a label to remove the repetetive cleanup, for error cases. Signed-off-by: Rajat Jain Reviewed-by: Brian Norris --- v3: Added Brian's "Reviewed-by" v2: same as v1 drivers/bluetooth/btusb.c | 19 +-- 1 file changed, 9

[PATCH v3 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup

The Marvell devices may have many gpio pins, and hence for wakeup on these out-of-band pins, the chip needs to be told which pin is to be used for wakeup, using an hci command. Thus, we read the pin number etc from the device tree node and send a command to the chip. Signed-off-by: Rajat Jain

[PATCH v3 2/3] Bluetooth: btusb: Add out-of-band wakeup support

Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that can be connected to a gpio on the CPU side, and can be used to wakeup the host out-of-band. This can be useful in situations where the in-band wakeup is not possible or not preferable (e.g. the in-band wakeup may require the USB

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 12/19/16 6:56 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: >> On 12/19/16 5:25 PM, Andy Lutomirski wrote: >>> net.socket_create_filter = "none": no filter >>> net.socket_create_filter = "bpf:baadf00d": bpf filter >>>

Re: Soft lockup in inet_put_port on 4.6

On Mon, 2016-12-19 at 18:07 -0800, Tom Herbert wrote: > When sockets created SO_REUSEPORT move to TW state they are placed > back on the the tb->owners. fastreuse port is no longer set so we have > to walk potential long list of sockets in tb->owners to open a new > listener socket. I imagine

[PATCH 0/2] net: hix5hd2_gmac: keep the compatible string not changed

This patch series fix the patch: d0fb6ba75dc0 ("net: hix5hd2_gmac: add generic compatible string") The SoC hix5hd2 compatible string has the suffix "-gmac" and we should not change its compatible string. So we should name all the compatible string with the suffix "-gmac". Creating a new name

[PATCH 2/2] ARM: dts: hix5hd2: don't change the existing compatible string

The SoC hix5hd2 compatible string has the suffix "-gmac" and we should not change it. We should only add the generic compatible string "hisi-gmac-v1". Fixes: 0855950ba580 ("ARM: dts: hix5hd2: add gmac generic compatible and clock names") Signed-off-by: Dongpo Li ---

[PATCH 1/2] net: hix5hd2_gmac: fix compatible strings name

The SoC hix5hd2 compatible string has the suffix "-gmac" and we should not change its compatible string. So we should name all the compatible string with the suffix "-gmac". Creating a new name suffix "-gemac" is unnecessary. We also add another SoC compatible string in dt binding documentation

Re: Soft lockup in inet_put_port on 4.6

On Mon, Dec 19, 2016 at 5:56 PM, David Miller wrote: > From: Josef Bacik > Date: Sat, 17 Dec 2016 13:26:00 + > >> So take my current duct tape fix and augment it with more >> information in the bind bucket? I'm not sure how to make this work >> without at

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:44 PM, David Ahern wrote: > On 12/19/16 5:25 PM, Andy Lutomirski wrote: >> net.socket_create_filter = "none": no filter >> net.socket_create_filter = "bpf:baadf00d": bpf filter >> net.socket_create_filter = "disallow": no sockets created period >>

Re: Soft lockup in inet_put_port on 4.6

From: Josef Bacik Date: Sat, 17 Dec 2016 13:26:00 + > So take my current duct tape fix and augment it with more > information in the bind bucket? I'm not sure how to make this work > without at least having a list of the binded addrs as well to make > sure we are really ok.

Re: [PATCH v2 2/3] Bluetooth: btusb: Add out-of-band wakeup support

Hi Brian, On Mon, Dec 19, 2016 at 3:10 PM, Brian Norris wrote: > Hi Rajat, > > On Fri, Dec 16, 2016 at 11:30:03AM -0800, Rajat Jain wrote: >> Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that >> can be connected to a gpio on the CPU side, and can be

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On 12/19/16 5:25 PM, Andy Lutomirski wrote: > net.socket_create_filter = "none": no filter > net.socket_create_filter = "bpf:baadf00d": bpf filter > net.socket_create_filter = "disallow": no sockets created period > net.socket_create_filter = "iptables:foobar": some iptables thingy >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:25 PM, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov > wrote: >> you're ignoring use cases I described earlier. >> In vrf case there is only one ifindex it needs to bind to. > > I'm

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 5:34 PM, David Miller wrote: > From: Alexei Starovoitov > Date: Mon, 19 Dec 2016 16:02:56 -0800 > >> huh? 'not right api' because it's using bpf syscall instead >> of cgroup control-file? I think the opposite is the

Re: Which ethtool methods should I implement?

On 12/19/2016 05:29 PM, Timur Tabi wrote: > I'm adding support for ethtool to my driver > (drivers/net/ethernet/qualcomm/emac/), and I can't find any meaningful > HOWTO documentation, so I'm not sure which methods I need to implement. > > Is there some minimal set of must-have ethtool methods

Re: ipv6: handle -EFAULT from skb_copy_bits

From: Dave Jones Date: Mon, 19 Dec 2016 19:40:13 -0500 > On Mon, Dec 19, 2016 at 07:31:44PM -0500, Dave Jones wrote: > > > Unfortunately, this made no difference. I spent some time today trying > > to make a better reproducer, but failed. I'll revisit again tomorrow.

Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string

On 2016/12/20 0:04, Rob Herring wrote: > On Mon, Dec 19, 2016 at 2:14 AM, Dongpo Li wrote: >> Hi Rob and David, >> >> On 2016/12/12 22:21, Rob Herring wrote: >>> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li wrote: Hi Rob, On

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

From: Alexei Starovoitov Date: Mon, 19 Dec 2016 16:02:56 -0800 > huh? 'not right api' because it's using bpf syscall instead > of cgroup control-file? I think the opposite is the truth. I completely agree with Alexei on this.

Which ethtool methods should I implement?

I'm adding support for ethtool to my driver (drivers/net/ethernet/qualcomm/emac/), and I can't find any meaningful HOWTO documentation, so I'm not sure which methods I need to implement. Is there some minimal set of must-have ethtool methods that should be implemented? Since I support

Re: [PATCH net] openvswitch: Add a missing break statement.

> On Dec 19, 2016, at 5:06 PM, Jarno Rajahalme wrote: > > Add a break statement to prevent fall-through from > OVS_KEY_ATTR_ETHERNET to OVS_KEY_ATTR_TUNNEL. Without the break > actions setting ethernet addresses fail to validate with log messages > complaining about invalid

Re: [PATCH v3 net-next 1/3] openvswitch: Add a missing break statement.

> On Dec 13, 2016, at 9:07 PM, Pravin Shelar wrote: > > On Tue, Nov 29, 2016 at 3:30 PM, Jarno Rajahalme wrote: >> Add a break statement to prevent fall-through from >> OVS_KEY_ATTR_ETHERNET to OVS_KEY_ATTR_TUNNEL. Without the break >> actions setting ethernet

[PATCH net] openvswitch: Add a missing break statement.

Add a break statement to prevent fall-through from OVS_KEY_ATTR_ETHERNET to OVS_KEY_ATTR_TUNNEL. Without the break actions setting ethernet addresses fail to validate with log messages complaining about invalid tunnel attributes. Fixes: 0a6410fbde ("openvswitch: netlink: support L3 packets")

Re: [PATCH net] netfilter: check duplicate config when initializing in ipt_CLUSTERIP

On Thu, Dec 15, 2016 at 12:31:40PM +0800, Xin Long wrote: > @@ -185,6 +186,17 @@ clusterip_config_init(const struct > ipt_clusterip_tgt_info *i, __be32 ip, > atomic_set(>refcount, 1); > atomic_set(>entries, 1); > > + spin_lock_bh(>lock); > + if (__clusterip_config_find(net,

Re: ipv6: handle -EFAULT from skb_copy_bits

On Mon, Dec 19, 2016 at 07:31:44PM -0500, Dave Jones wrote: > Unfortunately, this made no difference. I spent some time today trying > to make a better reproducer, but failed. I'll revisit again tomorrow. > > Maybe I need >1 process/thread to trigger this. That would explain why > I can

Re: ipv6: handle -EFAULT from skb_copy_bits

On Mon, Dec 19, 2016 at 02:48:48PM -0500, David Miller wrote: > One thing that's interesting is that if the user picks "IPPROTO_RAW" > as the value of 'protocol' we set inet->hdrincl to 1. > > The user can also set inet->hdrincl to 1 or 0 via setsockopt(). > > I think this is part of the

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov wrote: > On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: >> On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov >> wrote: >> > On Sat, Dec 17, 2016 at 10:18:44AM

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

Pavel Machek : [...] > Considering the memory barriers... is something like this neccessary > in the via-rhine ? Yes. > AFAICT... we need a barrier after making sure that descriptor is no > longer owned by DMA (to make sure we don't get stale data in rest of > descriptor)... and

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 01:23:50PM -0800, Andy Lutomirski wrote: > On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov > wrote: > > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: > >> Hi all- > >> > >> I apologize for being rather late with this.

Re: mlx4: Bug in XDP_TX + 16 rx-queues

Hi Tariq, On Sat, Dec 17, 2016 at 02:18:03AM -0800, Martin KaFai Lau wrote: > Hi All, > > I have been debugging with XDP_TX and 16 rx-queues. > > 1) When 16 rx-queues is used and an XDP prog is doing XDP_TX, > it seems that the packet cannot be XDP_TX out if the pkt > is received from some

Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock

I can make that change, however, I worry that it may be a bit misleading, since there are only two supported clock frequencies, but a number like that to me implies that it could be set to any number you want. I'm new at this, and so I'll go ahead and change it as you request, but I'd like to

RE: [upstream-release] [PATCH net v3 2/4] powerpc: fsl/fman: remove fsl, fman from of_device_ids[]

> From: Scott Wood [mailto:o...@buserror.net] > Sent: Monday, December 19, 2016 9:46 PM > > On Mon, 2016-12-19 at 18:13 +0200, Madalin Bucur wrote: > > The fsl/fman drivers will use of_platform_populate() on all > > supported platforms. Call of_platform_populate() to probe the > > FMan sub-nodes.

Re: [PATCH v2 2/3] Bluetooth: btusb: Add out-of-band wakeup support

Hi Rajat, On Fri, Dec 16, 2016 at 11:30:03AM -0800, Rajat Jain wrote: > Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that > can be connected to a gpio on the CPU side, and can be used to wakeup > the host out-of-band. This can be useful in situations where the > in-band wakeup

[PATCH net 1/2] net: netcp: ethss: fix errors in ethtool ops

From: WingMan Kwok In ethtool ops, it needs to retrieve the corresponding ethss module (gbe or xgbe) from the net_device structure. Prior to this patch, the retrieving procedure only checks for the gbe module. This patch fixes the issue by checking the xgbe module if the

[PATCH net 2/2] net: netcp: ethss: fix 10gbe host port tx pri map configuration

From: WingMan Kwok This patch adds the missing 10gbe host port tx priority map configurations. Signed-off-by: WingMan Kwok Signed-off-by: Murali Karicheri Signed-off-by: Sekhar Nori ---

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

Hi, On 18.12.2016 19:30, Pavel Machek wrote: > Hi! > >> > - e1efa87241272104d6a12c8b9fcdc4f62634d447 >> >> Yep, a sync of the dma descriptors before the hardware gets ownership of the >> tx tail >> idx is missing in the stmmac, too. > > I can reproduce failure with 4.4 fairly easily. I tried

Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote: > From: Geoff Lansberry > > --- > Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++ > drivers/nfc/trf7970a.c | 13 - > 2 files changed, 14 insertions(+), 1

Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock

On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote: > From: Geoff Lansberry > > --- > .../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++ > drivers/nfc/trf7970a.c | 42 > -- > 2 files changed, 34

Re: [PATCH 3/3] Bluetooth: btusb: Configure Marvel to use one of the pins for oob wakeup

On Wed, Dec 14, 2016 at 11:12:59AM -0800, Rajat Jain wrote: > The Marvell devices may have many gpio pins, and hence for wakeup > on these out-of-band pins, the chip needs to be told which pin is > to be used for wakeup, using an hci command. > > Thus, we read the pin number etc from the device

Re: [v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/19/2016 08:04 AM, David Miller wrote: From: Arvind Yadav Date: Thu, 15 Dec 2016 00:33:30 +0530 Here, If devm_ioremap will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Dec 19, 2016 at 12:56 PM, Alexei Starovoitov wrote: > On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: >> Hi all- >> >> I apologize for being rather late with this. I didn't realize that >> cgroup-bpf was going to be submitted for Linux 4.10,

Re: HalfSipHash Acceptable Usage

Hi JP, On Mon, Dec 19, 2016 at 9:49 PM, Jean-Philippe Aumasson wrote: > > On Mon, Dec 19, 2016 at 6:32 PM Jason A. Donenfeld wrote: >> >> Hi JP, >> >> With the threads getting confusing, I've been urged to try and keep >> the topics and threads

[PATCH net v4 4/4] fsl/fman: enable compilation on ARM64

Signed-off-by: Madalin Bucur --- drivers/net/ethernet/freescale/fman/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig index 79b7c84..dc0850b 100644 ---

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sat, Dec 17, 2016 at 10:18:44AM -0800, Andy Lutomirski wrote: > Hi all- > > I apologize for being rather late with this. I didn't realize that > cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see > it on the linux-api list, so I missed the discussion. > > I think that the

[PATCH net v4 2/4] powerpc: fsl/fman: remove fsl,fman from of_device_ids[]

The fsl/fman drivers will use of_platform_populate() on all supported platforms. Call of_platform_populate() to probe the FMan sub-nodes. Signed-off-by: Igal Liberman Signed-off-by: Madalin Bucur Acked-by: Scott Wood ---

[PATCH net v4 0/4] fsl/fman: fixes for ARM

The patch set fixes advertised speeds for QSGMII interfaces, disables A007273 erratum workaround on non-PowerPC platforms where it does not apply, enables compilation on ARM64 and addresses a probing issue on non PPC platforms. Changes from v3: removed redundant comment, added ack by Scott

[PATCH net v4 1/4] fsl/fman: fix 1G support for QSGMII interfaces

QSGMII ports were not advertising 1G speed. Signed-off-by: Madalin Bucur Reviewed-by: Camelia Groza --- drivers/net/ethernet/freescale/fman/mac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/freescale/fman/mac.c

[PATCH net v4 3/4] fsl/fman: A007273 only applies to PPC SoCs

Signed-off-by: Madalin Bucur Reviewed-by: Camelia Groza --- drivers/net/ethernet/freescale/fman/fman.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/freescale/fman/fman.c

Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff

Hello, On Mon, 19 Dec 2016, Eric Dumazet wrote: > I am still digesting this awesome patch series ;) Thanks. I don't feel quite comfortable with some of the changes (mostly XFRM, dst_confirm usage in CXGB) and I hope the discussion can provide adequate solution. > Not sure why

Re: Soft lockup in tc_classify

On 12/13/2016 12:51 AM, Cong Wang wrote: On Mon, Dec 12, 2016 at 1:18 PM, Or Gerlitz wrote: On Mon, Dec 12, 2016 at 3:28 PM, Daniel Borkmann wrote: Note that there's still the RCU fix missing for the deletion race that Cong will still send out,

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

From: John Fastabend Date: Mon, 19 Dec 2016 09:50:57 -0800 > On 16-12-19 07:05 AM, 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

Re: [upstream-release] [PATCH net v3 2/4] powerpc: fsl/fman: remove fsl, fman from of_device_ids[]

On Mon, 2016-12-19 at 18:13 +0200, Madalin Bucur wrote: > The fsl/fman drivers will use of_platform_populate() on all > supported platforms. Call of_platform_populate() to probe the > FMan sub-nodes. > > Signed-off-by: Igal Liberman > Signed-off-by: Madalin Bucur

Re: ipv6: handle -EFAULT from skb_copy_bits

From: Dave Jones Date: Mon, 19 Dec 2016 12:03:20 -0500 > On Sat, Dec 17, 2016 at 10:41:20AM -0500, David Miller wrote: > > > > It seems to be possible to craft a packet for sendmsg that triggers > > > the -EFAULT path in skb_copy_bits resulting in a BUG_ON that looks

RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF

David Laight wrote: > From: George Spelvin ... >> uint32_t >> hsiphash24(char const *in, size_t len, uint32_t const key[2]) >> { >> uint32_t c = key[0]; >> uint32_t d = key[1]; >> uint32_t a = 0x6c796765 ^ 0x736f6d65; >> uint32_t b = d ^ 0x74656462 ^ 0x646f7261; > I've not

Re: ovs internal_dev mtu

On Mon, Dec 19, 2016 at 12:59 AM, nickcooper-zhangtonghao wrote: > The upstream net-next has removed the “internal_dev_change_mtu”. > It will be ok for ovs(e.g. mtu_request) ? I think that code should > be keep. Can you provide more information ？

Re: Soft lockup in tc_classify

Hello, On Mon, Dec 19, 2016 at 8:39 AM, Shahar Klein wrote: > > > On 12/13/2016 12:51 AM, Cong Wang wrote: >> >> On Mon, Dec 12, 2016 at 1:18 PM, Or Gerlitz wrote: >>> >>> On Mon, Dec 12, 2016 at 3:28 PM, Daniel Borkmann >>>

Re: Synopsys Ethernet QoS

On 12/14/2016 01:57 PM, Pavel Machek wrote: > Hi! > >> So if there is a long time before handling interrupts, >> I guess that it makes sense that one stream could >> get an advantage in the net scheduler. >> >> If I find the time, and if no one beats me to it, I will try to replace >> the normal

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

On 16-12-19 07:05 AM, 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

HalfSipHash Acceptable Usage

Hi JP, With the threads getting confusing, I've been urged to try and keep the topics and threads more closely constrained. Here's where we're at, and here's the current pressing security concern. It'd be helpful to have a definitive statement on what you think is best, so we can just build on

RE: [PATCH v8 3/8] thunderbolt: Communication with the ICM (firmware)

Dell - Internal Use - Confidential > > There is small problem, though. On non-Apple systems the host controller only > appears when something is connected to thunderbolt ports. So the char device > would not be there all the time. However, I think we can still notify the > userspace by sending

Re: [PATCH] stmmac: fix memory barriers

Às 5:19 PM de 12/19/2016, Niklas Cassel escreveu: > On 12/19/2016 06:10 PM, Joao Pinto wrote: >> Hi, >> >> I am trying to built net-next git tree and it is failing: >> >> CC drivers/pnp/card.o >> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function >> ‘stmmac_hw_fix_mac_speed’:

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi Ted, On Sat, Dec 17, 2016 at 4:41 PM, Theodore Ts'o wrote: > On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote: >> >> - Ted, Andy Lutorminski and I will try to figure out a construction of >> >> get_random_long() that we all like. > > We don't have to find the

Re: [PATCH] stmmac: fix memory barriers

On 12/19/2016 06:10 PM, Joao Pinto wrote: > Hi, > > I am trying to built net-next git tree and it is failing: > > CC drivers/pnp/card.o > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function > ‘stmmac_hw_fix_mac_speed’: > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:224:34:

Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet

Hi Niklas, On Mon, Dec 19, 2016 at 5:39 PM, Niklas Söderlund wrote: > On 2016-12-18 23:26:11 +0300, Sergei Shtylyov wrote: >> On 12/12/2016 07:09 PM, Niklas Söderlund wrote: >> > One quirk needed for WoL is that the module clock needs to be prevented >> > from

Re: [PATCH] stmmac: fix memory barriers

Hi, I am trying to built net-next git tree and it is failing: CC drivers/pnp/card.o drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_hw_fix_mac_speed’: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:224:34: error: ‘struct stmmac_priv’ has no member named ‘phydev’

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Sat, Dec 17, 2016 at 3:55 PM, Jeffrey Walton wrote: > It may be prudent to include the endian reversal in the test to ensure > big endian machines produce expected results. Some closely related > testing on an old Apple PowerMac G5 revealed that result needed to be >

Re: ipv6: handle -EFAULT from skb_copy_bits

On Sat, Dec 17, 2016 at 10:41:20AM -0500, David Miller wrote: > > It seems to be possible to craft a packet for sendmsg that triggers > > the -EFAULT path in skb_copy_bits resulting in a BUG_ON that looks like: > > > > RIP: 0010:[] [] > > rawv6_sendmsg+0xc30/0xc40 > > RSP:

Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet

Hello! On 12/19/2016 07:41 PM, Niklas Söderlund wrote: [...] diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c index 05b0dc5..87640b9 100644 --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c [...] index

Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff

On 19.12.2016 17:40, Eric Dumazet wrote: > On Mon, 2016-12-19 at 17:36 +0100, Hannes Frederic Sowa wrote: >> On 19.12.2016 17:17, Eric Dumazet wrote: >>> On Sun, 2016-12-18 at 22:56 +0200, Julian Anastasov wrote: >>> +static inline void sock_confirm_neigh(struct sk_buff *skb, struct

Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet

Hi Sergei, On 2016-12-18 00:50:59 +0300, Sergei Shtylyov wrote: > Hello! > > On 12/12/2016 07:09 PM, Niklas Söderlund wrote: > >Not the complete review yet, just some superficial comments. > > > Add generic functionality to support Wake-on-Lan using MagicPacket which > >LAN. > > >

Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff

On Mon, 2016-12-19 at 17:36 +0100, Hannes Frederic Sowa wrote: > On 19.12.2016 17:17, Eric Dumazet wrote: > > On Sun, 2016-12-18 at 22:56 +0200, Julian Anastasov wrote: > > > >> > >> +static inline void sock_confirm_neigh(struct sk_buff *skb, struct > >> neighbour *n) > >> +{ > >> + if

RE: [PATCH net v2 2/5] powerpc: remove fsl,fman from of_device_ids[]

> From: David Miller [mailto:da...@davemloft.net] > Sent: Monday, December 19, 2016 5:37 PM > > From: Madalin Bucur > Date: Mon, 19 Dec 2016 11:22:20 +0200 > > > The fsl/fman drivers will use of_platform_populate() on all > > supported platforms. > > > > Signed-off-by:

Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet

Hi Sergei, Thanks for the spelling feedback, will include your suggestions in v3. Which I hope to post once rc1 is released and netdev opens, as you suggested to me previously. On 2016-12-18 23:26:11 +0300, Sergei Shtylyov wrote: > Hello. > > On 12/12/2016 07:09 PM, Niklas Söderlund wrote: >

Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff

On 19.12.2016 17:17, Eric Dumazet wrote: > On Sun, 2016-12-18 at 22:56 +0200, Julian Anastasov wrote: > >> >> +static inline void sock_confirm_neigh(struct sk_buff *skb, struct neighbour >> *n) >> +{ >> +if (unlikely(skb->dst_pending_confirm)) { >> +struct sock *sk = skb->sk;

Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff

On Sun, 2016-12-18 at 22:56 +0200, Julian Anastasov wrote: > > +static inline void sock_confirm_neigh(struct sk_buff *skb, struct neighbour > *n) > +{ > + if (unlikely(skb->dst_pending_confirm)) { > + struct sock *sk = skb->sk; > + unsigned long now = jiffies; > + >

[PATCH net v3 4/4] fsl/fman: enable compilation on ARM64

Signed-off-by: Madalin Bucur --- drivers/net/ethernet/freescale/fman/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig index 79b7c84..dc0850b 100644 ---

[PATCH net v3 0/4] fsl/fman: fixes for ARM

The patch set fixes advertised speeds for QSGMII interfaces, disables A007273 erratum workaround on non-PowerPC platforms where it does not apply, enables compilation on ARM64 and addresses a probing issue on non PPC platforms. Changes from v2: merged fsl/fman changes to avoid a point of failure

[PATCH net v3 2/4] powerpc: fsl/fman: remove fsl,fman from of_device_ids[]

The fsl/fman drivers will use of_platform_populate() on all supported platforms. Call of_platform_populate() to probe the FMan sub-nodes. Signed-off-by: Igal Liberman Signed-off-by: Madalin Bucur ---

[PATCH net v3 3/4] fsl/fman: A007273 only applies to PPC SoCs

Signed-off-by: Madalin Bucur Reviewed-by: Camelia Groza --- drivers/net/ethernet/freescale/fman/fman.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/freescale/fman/fman.c

[PATCH net v3 1/4] fsl/fman: fix 1G support for QSGMII interfaces

QSGMII ports were not advertising 1G speed. Signed-off-by: Madalin Bucur Reviewed-by: Camelia Groza --- drivers/net/ethernet/freescale/fman/mac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/freescale/fman/mac.c

Re: [PATCH net v2] ipvlan: fix crash when master is set in loopback mode

From: Mahesh Bandewar Date: Sun, 18 Dec 2016 11:00:25 -0800 > From: Mahesh Bandewar > > In an IPvlan setup when master is set in loopback mode e.g. > > ethtool -K eth0 set loopback on > > where eth0 is master device for IPvlan setup. > > The

Re: [PATCH] stmmac: fix memory barriers

From: Pavel Machek Date: Sun, 18 Dec 2016 21:38:12 +0100 > Fix up memory barriers in stmmac driver. They are meant to protect > against DMA engine, so smp_ variants are certainly wrong, and dma_ > variants are preferable. > > Signed-off-by: Pavel Machek

Re: Synopsys Ethernet QoS

On 12/13/2016 01:56 PM, Joao Pinto wrote: > Às 12:50 PM de 12/13/2016, Lars Persson escreveu: >>> 13 dec. 2016 kl. 13:31 skrev Niklas Cassel : >>> >>> >>> On 12/13/2016 12:49 PM, Joao Pinto wrote: Hi Niklas, Às 4:25 PM de 12/12/2016, Niklas Cassel

  1   2   >