RE: [PATCH] ethtool: add one ethtool option to set relax ordering mode

> -Original Message- > From: Jeff Kirsher [mailto:jeffrey.t.kirs...@intel.com] > Sent: Friday, December 23, 2016 9:07 AM > To: maowenan; Alexander Duyck > Cc: Stephen Hemminger; netdev@vger.kernel.org; weiyongjun (A); > Dingtianhong > Subject: Re: [PATCH] ethtool: add one ethtool option

Re: [PATCH v2] stmmac: CSR clock configuration fix

G'day Joao, On 23/12/2016 01:06, Joao Pinto wrote: Às 4:57 PM de 12/22/2016, Phil Reid escreveu: On 22/12/2016 23:47, Joao Pinto wrote: Hello Phil, Às 3:42 PM de 12/22/2016, Phil Reid escreveu: G'day Joao, On 22/12/2016 20:38, Joao Pinto wrote: When testing stmmac with my QoS reference

Re: [PATCH] ethtool: add one ethtool option to set relax ordering mode

On Fri, 2016-12-23 at 00:40 +, maowenan wrote: > > -Original Message- > > From: Alexander Duyck [mailto:alexander.du...@gmail.com] > > Sent: Thursday, December 22, 2016 11:54 PM > > To: maowenan > > Cc: Stephen Hemminger; netdev@vger.kernel.org; jeffrey.t.kirsher@intel. > > com; > >

[PATCH] brcmfmac: fix spelling mistakes on "Ivalid"

From: Colin Ian King Trivial fixes to spelling mistake "Ivalid" to "Invalid" in brcmf_err error messages. Signed-off-by: Colin Ian King --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++-- 1 file changed, 2

RE: [PATCH] ethtool: add one ethtool option to set relax ordering mode

> -Original Message- > From: Alexander Duyck [mailto:alexander.du...@gmail.com] > Sent: Thursday, December 22, 2016 11:54 PM > To: maowenan > Cc: Stephen Hemminger; netdev@vger.kernel.org; jeffrey.t.kirs...@intel.com; > weiyongjun (A); Dingtianhong > Subject: Re: [PATCH] ethtool: add one

Re: [PATCH net] net, sched: fix soft lockup in tc_classify

On 12/22/2016 08:05 PM, Cong Wang wrote: On Wed, Dec 21, 2016 at 1:07 PM, Daniel Borkmann wrote: Ok, you mean for net. In that case I prefer the smaller sized fix to be honest. It also covers everything from the point where we fetch the chain via cops->tcf_chain() to the

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hannes Frederic Sowa wrote: > A lockdep test should still be done. ;) Adding might_lock() annotations will improve coverage a lot. > Yes, that does look nice indeed. Accounting for bits instead of bytes > shouldn't be a huge problem either. Maybe it gets a bit more verbose in > case you can't

Re: [PATCH net] net, sched: fix soft lockup in tc_classify

On 12/22/2016 06:50 PM, John Fastabend wrote: On 16-12-22 08:53 AM, David Miller wrote: From: Daniel Borkmann Date: Wed, 21 Dec 2016 22:07:48 +0100 Ok, you mean for net. In that case I prefer the smaller sized fix to be honest. It also covers everything from the point

Re: [PATCH net] net, sched: fix soft lockup in tc_classify

On 12/22/2016 02:16 PM, Shahar Klein wrote: On 12/21/2016 7:04 PM, Daniel Borkmann wrote: Shahar reported a soft lockup in tc_classify(), where we run into an endless loop when walking the classifier chain due to tp->next == tp which is a state we should never run into. The issue only seems to

[PATCH net] inet: fix IP(V6)_RECVORIGDSTADDR for udp sockets

From: Willem de Bruijn Socket cmsg IP(V6)_RECVORIGDSTADDR checks that port range lies within the packet. For sockets that have transport headers pulled, transport offset can be negative. Use signed comparison to avoid overflow. Fixes: e6afc8ace6dd ("udp: remove headers from

Re: [PATCH] Fixed status entry in m_can documentation

On Thu, Dec 22, 2016 at 11:45:21AM +0100, Vyacheslav V. Yurkov wrote: > Use valid value for 'enabled' in status field > > Signed-off-by: Vyacheslav V. Yurkov > --- > Documentation/devicetree/bindings/net/can/m_can.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

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

On Wed, Dec 21, 2016 at 11:18:33PM -0500, Geoff Lansberry wrote: > The TRF7970A has configuration options for supporting hardware designs > with 1.8 Volt or 3.3 Volt IO. This commit adds a device tree option, > using a fixed regulator binding, for setting the io voltage to match > the hardware

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

On Wed, Dec 21, 2016 at 11:18:32PM -0500, Geoff Lansberry wrote: > The TRF7970A has configuration options to support hardware designs > which use a 27.12MHz clock. This commit adds a device tree option > 'clock-frequency' to support configuring the this chip for default > 13.56MHz clock or the

Re: [PATCH 6/6 net-next] inet: reset tb->fastreuseport when adding a reuseport sk

On Thu, 2016-12-22 at 16:26 -0500, Josef Bacik wrote: > If we have non reuseport sockets on a tb we will set tb->fastreuseport to 0 > and > never set it again. Which means that in the future if we end up adding a > bunch > of reuseport sk's to that tb we'll have to do the expensive scan every

Re: [PATCH 3/6 net-next] inet: kill smallest_size and smallest_port

On Thu, 2016-12-22 at 16:26 -0500, Josef Bacik wrote: > In inet_csk_get_port we seem to be using smallest_port to figure out where the > best place to look for a SO_REUSEPORT sk that matches with an existing set of > SO_REUSEPORT's. However if we get to the logic > > if (smallest_size != -1) { >

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

On Wed, Dec 21, 2016 at 12:33:51PM -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 is not

Re: [PATCH net-next 02/10] net: netcp: ethss: add support of 10gbe pcsr link status

On Tue, Dec 20, 2016 at 05:09:45PM -0500, Murali Karicheri wrote: > From: WingMan Kwok > > The 10GBASE-R Physical Coding Sublayer (PCS-R) module provides > functionality of a physical coding sublayer (PCS) on data being > transferred between a demuxed XGMII and SerDes supporting

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On 22.12.2016 22:11, George Spelvin wrote: >> I do tend to like Ted's version in which we use batched >> get_random_bytes() output. If it's fast enough, it's simpler and lets >> us get the full strength of a CSPRNG. > > With the ChaCha20 generator, that's fine, although note that this abandons >

[PATCH 4/6 net-next] inet: don't check for bind conflicts twice when searching for a port

This is just wasted time, we've already found a tb that doesn't have a bind conflict, and we don't drop the head lock so scanning again isn't going to give us a different answer. Instead move the tb->reuse setting logic outside of the found_tb path and put it in the success: path. Then make it

[PATCH 6/6 net-next] inet: reset tb->fastreuseport when adding a reuseport sk

If we have non reuseport sockets on a tb we will set tb->fastreuseport to 0 and never set it again. Which means that in the future if we end up adding a bunch of reuseport sk's to that tb we'll have to do the expensive scan every time. Instead add a sock_common to the tb so we know what reuseport

[PATCH 3/6 net-next] inet: kill smallest_size and smallest_port

In inet_csk_get_port we seem to be using smallest_port to figure out where the best place to look for a SO_REUSEPORT sk that matches with an existing set of SO_REUSEPORT's. However if we get to the logic if (smallest_size != -1) { port = smallest_port; goto have_port; } we will

[PATCH 1/6 net-next] inet: collapse ipv4/v6 rcv_saddr_equal functions into one

We pass these per-protocol equal functions around in various places, but we can just have one function that checks the sk->sk_family and then do the right comparison function. I've also changed the ipv4 version to not cast to inet_sock since it is unneeded. Signed-off-by: Josef Bacik

[PATCH 2/6 net-next] inet: drop ->bind_conflict

The only difference between inet6_csk_bind_conflict and inet_csk_bind_conflict is how they check the rcv_saddr, so delete this call back and simply change inet_csk_bind_conflict to call inet_rcv_saddr_equal. Signed-off-by: Josef Bacik --- include/net/inet6_connection_sock.h | 5

[PATCH 5/6 net-next] inet: split inet_csk_get_port into two functions

inet_csk_get_port does two different things, it either scans for an open port, or it tries to see if the specified port is available for use. Since these two operations have different rules and are basically independent lets split them into two different functions to make them both more readable.

[PATCH 0/6 net-next][V2] Rework inet_csk_get_port

V1->V2: -Added a new patch 'inet: collapse ipv4/v6 rcv_saddr_equal functions into one' at Hannes' suggestion. -Dropped ->bind_conflict and just use the new helper. -Fixed a compile bug from the original ->bind_conflict patch. The original description of the series follows

Re: [PATCH net-next 01/10] net: netcp: ethss: add support of subsystem register region regmap

On Tue, Dec 20, 2016 at 05:09:44PM -0500, Murali Karicheri wrote: > From: WingMan Kwok > > 10gbe phy driver needs to access the 10gbe subsystem control > register during phy initialization. To facilitate the shared > access of the subsystem register region between the 10gbe

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

> I do tend to like Ted's version in which we use batched > get_random_bytes() output. If it's fast enough, it's simpler and lets > us get the full strength of a CSPRNG. With the ChaCha20 generator, that's fine, although note that this abandons anti-backtracking entirely. It also takes locks,

Re: [PATCH iproute2 v3 4/4] ifstat: Add "sw only" extended statistics to ifstat

On 12/22/16, 8:23 AM, Nogah Frankel wrote: > Add support for extended statistics of SW only type, for counting only the > packets that went via the cpu. (useful for systems with forward > offloading). It reads it from filter type IFLA_STATS_LINK_OFFLOAD_XSTATS > and sub type

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On 22.12.2016 20:56, Andy Lutomirski wrote: > It's also not quite clear to me why userspace needs to be able to > calculate the digest on its own. A bpf(BPF_CALC_PROGRAM_DIGEST) > command that takes a BPF program as input and hashes it would seem to > serve the same purpose, and that would allow

Re: [PATCH 1/5 net-next] inet: replace ->bind_conflict with ->rcv_saddr_equal

On 21.12.2016 16:16, Josef Bacik wrote: > On Wed, Dec 21, 2016 at 10:06 AM, Hannes Frederic Sowa > wrote: >> On Tue, 2016-12-20 at 15:07 -0500, Josef Bacik wrote: >>> The only difference between inet6_csk_bind_conflict and >>> inet_csk_bind_conflict >>> is how they

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 11:34 AM, Alexei Starovoitov wrote: > On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski wrote: >> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa >> wrote: >>> On Thu, 2016-12-22 at 08:07

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:08:37PM +0100, Hannes Frederic Sowa wrote: > I wasn't concerned about performance but more about DoS resilience. I > wonder how safe half md4 actually is in terms of allowing users to > generate long hash chains in the filesystem (in terms of length > extension attacks

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Thu, Dec 22, 2016 at 11:24 AM, George Spelvin wrote: >> Having slept on this, I like it less. The problem is that a >> backtracking attacker doesn't just learn H(random seed || entropy_0 || >> secret || ...) -- they learn the internal state of the hash function >>

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa > wrote: >> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: >> >> We don't prevent ebpf programs being loaded based on the

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

> Having slept on this, I like it less. The problem is that a > backtracking attacker doesn't just learn H(random seed || entropy_0 || > secret || ...) -- they learn the internal state of the hash function > that generates that value. This probably breaks any attempt to apply > security

Re: [PATCH iproute2 0/2] Fix the usage of TC tunnel key

On Thu, 22 Dec 2016 10:14:39 +0200 Hadar Hen Zion wrote: > Add dest UDP port parameter to the usage of tc tunnle key action and > classifcation. > > > Hadar Hen Zion (2): > tc/cls_flower: Add to the usage encapsulation dest UDP port > tc/m_tunnel_key: Add to the usage

Re: [PATCH net] net, sched: fix soft lockup in tc_classify

On Wed, Dec 21, 2016 at 1:07 PM, Daniel Borkmann wrote: > > Ok, you mean for net. In that case I prefer the smaller sized fix to be > honest. It also covers everything from the point where we fetch the chain > via cops->tcf_chain() to the end of the function, which is where

Re: [PATCH iproute2 v3 2/4] ifstat: Add extended statistics to ifstat

On Thu, 22 Dec 2016 18:23:13 +0200 Nogah Frankel wrote: On Thu, 22 Dec 2016 18:23:13 +0200 Nogah Frankel wrote: > } > @@ -691,18 +804,22 @@ static const struct option longopts[] = { > { "interval", 1, 0, 't' }, > { "version", 0, 0, 'V' }, >

[PATCH] tc: add missing limits.h header

This fixes under musl build issues like: f_matchall.c: In function ‘matchall_parse_opt’: f_matchall.c:48:12: error: ‘LONG_MIN’ undeclared (first use in this function) if (h == LONG_MIN || h == LONG_MAX) { ^ f_matchall.c:48:12: note: each undeclared identifier is reported only once

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

On Mon, Dec 19, 2016 at 5:23 PM, Geoff Lansberry wrote: > 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

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 5:59 PM, Hannes Frederic Sowa wrote: > We don't prevent ebpf programs being loaded based on the digest but > just to uniquely identify loaded programs from user space and match up > with their source. Okay, so in that case, a weak hashing

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 7:08 PM, Hannes Frederic Sowa wrote: > I wasn't concerned about performance but more about DoS resilience. I > wonder how safe half md4 actually is in terms of allowing users to > generate long hash chains in the filesystem (in terms of length >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 16:54, Theodore Ts'o wrote: > On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: >> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa >> wrote: >>> following up on what appears to be a random subject: ;) >>> >>> IIRC, ext4 code by

Re: [PATCH net-next] ixgbevf: fix 'Etherleak' in ixgbevf

Yes that is much more helpful. So looking at it things are being padded but the last 4 bytes always have this extra data in them. I've been trying to recreate the issue on an 82599 with an SR-IOV VF and I haven't been having much luck reproducing the problem. In your test environment is the

Re: [PATCH net] net, sched: fix soft lockup in tc_classify

On 16-12-22 08:53 AM, David Miller wrote: > From: Daniel Borkmann > Date: Wed, 21 Dec 2016 22:07:48 +0100 > >> Ok, you mean for net. In that case I prefer the smaller sized fix to >> be honest. It also covers everything from the point where we fetch >> the chain via

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, 2016-12-22 at 09:25 -0800, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa > wrote: > > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > > > > > > You mean: > > > > > > commit 7bd509e311f408f7a5132fcdde2069af65fa05ae

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa wrote: > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: >> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa >> wrote: >> > On Thu, 2016-12-22 at 16:41 +0100, Jason A.

Re: [PATCH v2] stmmac: CSR clock configuration fix

Às 4:57 PM de 12/22/2016, Phil Reid escreveu: > On 22/12/2016 23:47, Joao Pinto wrote: >> >> Hello Phil, >> >> Às 3:42 PM de 12/22/2016, Phil Reid escreveu: >>> G'day Joao, >>> >>> On 22/12/2016 20:38, Joao Pinto wrote: When testing stmmac with my QoS reference design I checked a problem in

Re: [PATCH net] net, sched: fix soft lockup in tc_classify

From: Daniel Borkmann Date: Wed, 21 Dec 2016 22:07:48 +0100 > Ok, you mean for net. In that case I prefer the smaller sized fix to > be honest. It also covers everything from the point where we fetch > the chain via cops->tcf_chain() to the end of the function, which is >

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa > wrote: > > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > > > Hi Hannes, > > > > > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic

Re: [PATCH v2] stmmac: CSR clock configuration fix

On 22/12/2016 23:47, Joao Pinto wrote: Hello Phil, Às 3:42 PM de 12/22/2016, Phil Reid escreveu: G'day Joao, On 22/12/2016 20:38, Joao Pinto wrote: When testing stmmac with my QoS reference design I checked a problem in the CSR clock configuration that was impossibilitating the phy

VERY IMPORTANT

We have an inheritance of a deceased client with your surname. Kindly contact me via email:( gertjan.vlie...@yandex.com ) with your full names for info Best Regards. Dr, Gertjan Vlieghe. -- Correo Corporativo Hospital Universitario del Valle E.S.E

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 8:28 AM, Jason A. Donenfeld wrote: > Hi all, > > I don't know what your design requirements are for this. It looks like > you're generating some kind of crypto digest of a program, and you > need to avoid collisions. If you'd like to go with a PRF (keyed

Re: [PATCH net] net, sched: fix soft lockup in tc_classify

On 12/21/2016 7:04 PM, Daniel Borkmann wrote: Shahar reported a soft lockup in tc_classify(), where we run into an endless loop when walking the classifier chain due to tp->next == tp which is a state we should never run into. The issue only seems to trigger under load in the tc control path.

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 5:30 PM, Theodore Ts'o wrote: > I'd do this first, as one set. Adding a new file to crypto is > unlikely to cause merge conflicts. Ack. > >> 2. convert char/random to use siphash. to: ted ts'o's random-next > > I'm confused, I thought you had agreed to

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 05:16:47PM +0100, Jason A. Donenfeld wrote: > Could you offer a bit of advice on how to manage dependencies between > patchsets during merge windows? I'm a bit new to the process. > > Specifically, we how have 4 parts: > 1. add siphash, and use it for some networking code.

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

Hi all, I don't know what your design requirements are for this. It looks like you're generating some kind of crypto digest of a program, and you need to avoid collisions. If you'd like to go with a PRF (keyed hash function) that uses some kernel secret key, then I'd strongly suggest using

[PATCH iproute2 v3 2/4] ifstat: Add extended statistics to ifstat

Extended stats are part of the RTM_GETSTATS method. This patch adds them to ifstat. While extended stats can come in many forms, we support only the rtnl_link_stats64 struct for them (which is the 64 bits version of struct rtnl_link_stats). We support stats in the main nesting level, or one lower.

Re: [PATCH net 1/1] tipc: don't send FIN message from connectionless socket

From: Jon Maloy Date: Thu, 22 Dec 2016 07:22:29 -0500 > In commit 6f00089c7372 ("tipc: remove SS_DISCONNECTING state") the > check for socket type is in the wrong place, causing a closing socket > to always send out a FIN message even when the socket was never >

[PATCH iproute2 v3 1/4] ifstat: Includes reorder

Reorder the includes order in misc/ifstat.c to match convention. Signed-off-by: Nogah Frankel Reviewed-by: Jiri Pirko --- misc/ifstat.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/misc/ifstat.c b/misc/ifstat.c index

[PATCH iproute2 v3 3/4] ifstat: Add 64 bits based stats to extended statistics

The default stats for ifstat are 32 bits based. The kernel supports 64 bits based stats. (They are returned in struct rtnl_link_stats64 which is an exact copy of struct rtnl_link_stats, in which the "normal" stats are returned, but with fields of u64 instead of u32). This patch adds them as an

Re: [PATCH net] ipvlan: fix multicast processing

From: Mahesh Bandewar Date: Wed, 21 Dec 2016 17:30:16 -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

[PATCH iproute2 v3 4/4] ifstat: Add "sw only" extended statistics to ifstat

Add support for extended statistics of SW only type, for counting only the packets that went via the cpu. (useful for systems with forward offloading). It reads it from filter type IFLA_STATS_LINK_OFFLOAD_XSTATS and sub type IFLA_OFFLOAD_XSTATS_CPU_HIT. It is under the name 'software' (or any

[PATCH iproute2 v3 0/4] update ifstat for new stats

Previously stats were gotten by RTM_GETLINK which returns 32 bits based statistics. It supports only one type of stats. Lately, a new method to get stats was added - RTM_GETSTATS. It supports ability to choose stats type. The basic stats were changed from 32 bits based to 64 bits based. This

Re: [PATCH v2] stmmac: CSR clock configuration fix

From: Joao Pinto Date: Thu, 22 Dec 2016 12:38:00 + > When testing stmmac with my QoS reference design I checked a problem in the > CSR clock configuration that was impossibilitating the phy discovery, since > every read operation returned 0x. This patch fixes

Re: [PATCH net] net/mlx4_en: Fix user prio field in XDP forward

From: Tariq Toukan Date: Thu, 22 Dec 2016 14:32:58 +0200 > The user prio field is wrong (and overflows) in the XDP forward > flow. > This is a result of a bad value for num_tx_rings_p_up, which should > account all XDP TX rings, as they operate for the same user prio. > >

Re: [PATCH v2 net] ipvlan: fix various issues in ipvlan_process_multicast()

From: Eric Dumazet Date: Wed, 21 Dec 2016 18:00:24 -0800 > From: Eric Dumazet > > 1) netif_rx() / dev_forward_skb() should not be called from process > context. > > 2) ipvlan_count_rx() should be called with preemption disabled. > > 3) We should

ipv6: handle -EFAULT from skb_copy_bits

By setting certain socket options on ipv6 raw sockets, we can confuse the length calculation in rawv6_push_pending_frames triggering a BUG_ON. RIP: 0010:[] [] rawv6_sendmsg+0xc30/0xc40 RSP: 0018:881f6c4a7c18 EFLAGS: 00010282 RAX: fff2 RBX: 881f6c681680 RCX: 0002

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Ted, On Thu, Dec 22, 2016 at 4:58 PM, Theodore Ts'o wrote: > Can we do this as a separate series, please? At this point, it's a > completely separate change from a logical perspective, and we can take > in the change through the random.git tree. > > Changes that touch files

Re: pull-request: wireless-drivers 2016-12-22

From: Kalle Valo Date: Thu, 22 Dec 2016 17:11:27 +0200 > before the holidays a really small pull request for 4.10. I just want to > have the regressions in rtlwifi and ath9k fixed quickly so I send this > earlier than I normally would. > > Please let me know if there are

Re: [PATCH net] net: ipv4: Don't crash if passing a null sk to ip_do_redirect.

From: Lorenzo Colitti Date: Fri, 23 Dec 2016 00:33:57 +0900 > Commit e2d118a1cb5e ("net: inet: Support UID-based routing in IP > protocols.") made ip_do_redirect call sock_net(sk) to determine > the network namespace of the passed-in socket. This crashes if sk > is NULL. > >

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 6:07 PM, Andy Lutomirski wrote: > On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin > wrote: >> As a separate message, to disentangle the threads, I'd like to >> talk about get_random_long(). >> >> After some thinking, I still

BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa wrote: > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: >> Hi Hannes, >> >> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa >> wrote: >> > IPv6 you cannot touch

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote: > I find this compelling. We'll have one csprng for both > get_random_int/long and for /dev/urandom, and we'll be able to update > that silly warning on the comment of get_random_int/long to read > "gives output of either rdrand

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: > > following up on what appears to be a random subject: ;) > > > > IIRC, ext4 code by default still uses half_md4 for hashing of

Re: [PATCH] ethtool: add one ethtool option to set relax ordering mode

On Wed, Dec 21, 2016 at 5:39 PM, maowenan wrote: > > >> -Original Message- >> From: Stephen Hemminger [mailto:step...@networkplumber.org] >> Sent: Thursday, December 22, 2016 9:28 AM >> To: maowenan >> Cc: netdev@vger.kernel.org; jeffrey.t.kirs...@intel.com >>

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:51 PM, Hannes Frederic Sowa wrote: > This algorithm should be a non-seeded algorithm, because the hashes > should be stable and verifiable by user space tooling. Thus this would > need a hashing algorithm that is hardened against pre-image >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > Hi Hannes, > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa > wrote: > > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > > You don't want to give people new IPv6 addresses

Re: [PATCH v2] stmmac: CSR clock configuration fix

G'day Joao, On 22/12/2016 20:38, Joao Pinto wrote: When testing stmmac with my QoS reference design I checked a problem in the CSR clock configuration that was impossibilitating the phy discovery, since every read operation returned 0x. This patch fixes the issue. Signed-off-by: Joao

Re: [PATCH v2] stmmac: CSR clock configuration fix

Hello Phil, Às 3:42 PM de 12/22/2016, Phil Reid escreveu: > G'day Joao, > > On 22/12/2016 20:38, Joao Pinto wrote: >> When testing stmmac with my QoS reference design I checked a problem in the >> CSR clock configuration that was impossibilitating the phy discovery, since >> every read

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Hannes, On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa wrote: > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > You don't want to give people new IPv6 addresses with the same stable > secret (across reboots) after a kernel upgrade.

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:29 +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote: > > As a first step, I'm considering adding a patch to move halfmd4.c > > inside the ext4 domain, or at the very least, simply remove it from > >

[PATCH net] net: ipv4: Don't crash if passing a null sk to ip_do_redirect.

Commit e2d118a1cb5e ("net: inet: Support UID-based routing in IP protocols.") made ip_do_redirect call sock_net(sk) to determine the network namespace of the passed-in socket. This crashes if sk is NULL. Fix this by getting the network namespace from the skb instead. Fixes: e2d118a1cb5e ("net:

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote: > As a first step, I'm considering adding a patch to move halfmd4.c > inside the ext4 domain, or at the very least, simply remove it from > linux/cryptohash.h. That'll then leave the handful of bizarre sha1 > usages to

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:05 PM, Hannes Frederic Sowa wrote: > This change would need a new version of the ext4 super block, because > you should not change existing file systems. Right. As a first step, I'm considering adding a patch to move halfmd4.c inside the

pull-request: wireless-drivers 2016-12-22

Hi Dave, before the holidays a really small pull request for 4.10. I just want to have the regressions in rtlwifi and ath9k fixed quickly so I send this earlier than I normally would. Please let me know if there are any problems. Kalle The following changes since commit

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 14:10, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: >> following up on what appears to be a random subject: ;) >> >> IIRC, ext4 code by default still uses half_md4 for hashing of filenames >> in the htree.

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa wrote: > following up on what appears to be a random subject: ;) > > IIRC, ext4 code by default still uses half_md4 for hashing of filenames > in the htree. siphash seems to fit this use case pretty good. I saw

RE: [PATCH net 1/1] tipc: revert use of copy_from_iter_full()

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Al Viro > Sent: Wednesday, 21 December, 2016 22:08 > To: Jon Maloy > Cc: da...@davemloft.net; netdev@vger.kernel.org; Parthasarathy Bhuvaragan >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Ted, On Thu, 2016-12-22 at 00:41 -0500, Theodore Ts'o wrote: > On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote: > > > > Funny -- while you guys were sending this back & forth, I was writing > > my reply to Andy which essentially arrives at the same conclusion. > > Given

[PATCH v2] stmmac: CSR clock configuration fix

When testing stmmac with my QoS reference design I checked a problem in the CSR clock configuration that was impossibilitating the phy discovery, since every read operation returned 0x. This patch fixes the issue. Signed-off-by: Joao Pinto --- changes v1->v2 (David

[PATCH net] net/mlx4_en: Fix user prio field in XDP forward

The user prio field is wrong (and overflows) in the XDP forward flow. This is a result of a bad value for num_tx_rings_p_up, which should account all XDP TX rings, as they operate for the same user prio. Signed-off-by: Tariq Toukan Reported-by: Martin KaFai Lau

Re: [PATCH] stmmac: CSR clock configuration fix

Hi David, Às 10:15 AM de 12/22/2016, Joao Pinto escreveu: > Às 6:21 PM de 12/21/2016, David Miller escreveu: >> From: Joao Pinto >> Date: Tue, 20 Dec 2016 11:21:47 + >> >>> When testing stmmac with my QoS reference design I checked a problem in the >>> CSR clock

Re: [PATCH] stmmac: CSR clock configuration fix

Às 12:23 PM de 12/22/2016, Joao Pinto escreveu: > > Hi David, > > Às 10:15 AM de 12/22/2016, Joao Pinto escreveu: >> Às 6:21 PM de 12/21/2016, David Miller escreveu: >>> From: Joao Pinto >>> Date: Tue, 20 Dec 2016 11:21:47 + >>> When testing stmmac with my QoS

[PATCH net 0/2] net/sched fixes for cls_flower and act_tunnel_key

Hi Dave, This small series contain a fix to the matching flags support in flower and to the tunnel key action MD prep for IPv6. On a non related note, wishing everyone around here a happy new year, celebrate and take a rest so we can do lots of good patch work(s) next. Or. Or Gerlitz (2):

[PATCH net 2/2] net/sched: cls_flower: Mandate mask when matching on flags

When matching on flags, we should require the user to provide the mask and avoid using an all-ones mask. Not doing so causes matching on flags provided w.o mask to hit on the value being unset for all flags, which may not what the user wanted to happen. Fixes: faa3ffce7829 ('net/sched:

[PATCH net 1/2] net/sched: act_tunnel_key: Fix setting UDP dst port in metadata under IPv6

The UDP dst port was provided to the helper function which sets the IPv6 IP tunnel meta-data under a wrong param order, fix that. Fixes: 75bfbca01e48 ('net/sched: act_tunnel_key: Add UDP dst port option') Signed-off-by: Or Gerlitz Reviewed-by: Hadar Hen Zion

[PATCH net 1/1] tipc: don't send FIN message from connectionless socket

In commit 6f00089c7372 ("tipc: remove SS_DISCONNECTING state") the check for socket type is in the wrong place, causing a closing socket to always send out a FIN message even when the socket was never connected. This is normally harmless, since the destination node for such messages most often is

[PATCH] Fixed status entry in m_can documentation

Use valid value for 'enabled' in status field Signed-off-by: Vyacheslav V. Yurkov --- Documentation/devicetree/bindings/net/can/m_can.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt

Re: [PATCH] stmmac: CSR clock configuration fix

Às 6:21 PM de 12/21/2016, David Miller escreveu: > From: Joao Pinto > Date: Tue, 20 Dec 2016 11:21:47 + > >> When testing stmmac with my QoS reference design I checked a problem in the >> CSR clock configuration that was impossibilitating the phy discovery, since >>

  1   2   >