Re: [PATCH 2/2] net: wireless: fix to uses struct

Hi Ozgur, [auto build test ERROR on mac80211-next/master] [also build test ERROR on v4.9 next-20161221] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed

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

Hi Ted, On Thu, Dec 22, 2016 at 6:41 AM, Theodore Ts'o wrote: > The bottom line is that I think we're really "pixel peeping" at this > point --- which is what obsessed digital photographers will do when > debating the quality of a Canon vs Nikon DSLR by blowing up a photo by > a

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

On Wed, Dec 21, 2016 at 9:01 PM, George Spelvin wrote: > Andy Lutomirski wrote: >> I don't even think it needs that. This is just adding a >> non-destructive final operation, right? > > It is, but the problem is that SipHash is intended for *small* inputs, > so the

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

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 that we're all arriving to the same thing, and that Ted shot in > this

Re: [PATCH 2/2] net: wireless: fix to uses struct

Hi Ozgur, [auto build test ERROR on mac80211-next/master] [also build test ERROR on v4.9 next-20161221] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed

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

Andy Lutomirski wrote: > I don't even think it needs that. This is just adding a > non-destructive final operation, right? It is, but the problem is that SipHash is intended for *small* inputs, so the standard implementations aren't broken into init/update/final functions. There's just one big

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

Hi George, On Thu, Dec 22, 2016 at 4:55 AM, George Spelvin wrote: > Do we have to go through this? No, the benchmark was *not* bogus. > Then I replaced the kernel #includes with the necessary typedefs > and #defines to make it compile in user-space. > * I didn't

[PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

From: Jaret Cantu Repeated polling attempts cause a NULL dereference error to occur. This is because the state of the trf7970a is currently reading but another request has been made to send a command before it has finished. The solution is to properly kill the waiting

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

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 optional 27.12MHz clock. Signed-off-by: Geoff Lansberry

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

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 configuration. If no option is supplied it defaults to 3.3 volt

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

> Plus the benchmark was bogus anyway, and when I built a more specific > harness -- actually comparing the TCP sequence number functions -- > SipHash was faster than MD5, even on register starved x86. So I think > we're fine and this chapter of the discussion can come to a close, in > order to

[PATCH] fddi: skfp: Use more common logging styles

Several macros use non-standard styles where format and arguments are not verified. Convert these to a more typical fmt, ##__VA_ARGS__ use so format and arguments match as appropriate. Miscellanea: o Fix format and argument mismatches o Realign and reindent misindented block o Strip newlines

Re: [PATCH] RDS: use rb_entry()

On 12/20/2016 9:02 AM, Geliang Tang wrote: > To make the code clearer, use rb_entry() instead of container_of() to > deal with rbtree. > > Signed-off-by: Geliang Tang > --- > net/rds/rdma.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

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

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

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

On Thu, Dec 22, 2016 at 3:49 AM, Jason A. Donenfeld wrote: > I did have two objections to this. The first was that my SipHash > construction is faster. But in any case, they're both faster than the > current MD5, so it's just extra rice. The second, and the more > important one,

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

On Thu, Dec 22, 2016 at 02:47:09AM +, Jon Maloy wrote: > > OK, I see what's going on there - unlike iterate_and_advance(), which > > explicitly skips any work in case of empty iterator, iterate_all_kind() > > does not. Could you check if the following fixes your problem? > > Confirmed. The

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

Hi Andy & Hannes, On Thu, Dec 22, 2016 at 3:07 AM, Hannes Frederic Sowa wrote: > I wonder if Ted's proposal was analyzed further in terms of performance > if get_random_int should provide cprng alike properties? > > For reference: https://lkml.org/lkml/2016/12/14/351

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

> On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin >> After some thinking, I still like the "state-preserving" construct >> that's equivalent to the current MD5 code. Yes, we could just do >> siphash(current_cpu || per_cpu_counter, global_key), but it's nice to >> preserve a bit more. >> >> It

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

Hi Andy, On Thu, Dec 22, 2016 at 12:42 AM, Andy Lutomirski wrote: > So this is probably good enough, and making it better is hard. Changing it > to: > > u64 entropy = (u64)random_get_entropy() + current->pid; > result = siphash(..., entropy, ...); > secret->chaining +=

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

On Wed, Dec 21, 2016 at 6:07 PM, Hannes Frederic Sowa wrote: > On 22.12.2016 00:42, Andy Lutomirski wrote: >> On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote: >>> unsigned int get_random_int(void) >>> { >>> - __u32 *hash; >>> -

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

On Wed, Dec 21, 2016 at 08:01:37PM -0500, Jon Maloy wrote: > commit cbbd26b8b1a6 ("[iov_iter] new primitives - copy_from_iter_full() > and friends") replaced calls to copy_from_iter() in the function > tipc_msg_build(). This causes a an immediate crash as follows: Very interesting. > [

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

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 like the "state-preserving" construct > that's equivalent to the current MD5 code.

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

On 22.12.2016 00:42, Andy Lutomirski wrote: > On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote: >> unsigned int get_random_int(void) >> { >> - __u32 *hash; >> - unsigned int ret; >> - >> - if (arch_get_random_int()) >> - return ret; >> -

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

On 2016/12/21 10:20, Alexander Duyck wrote: > I find it curious that only the last 4 bytes have data in them. I'm > wondering if the NIC/driver in the Windows/Nessus system is > interpreting the 4 byte CRC on the end of the frame as padding instead > of stripping it. > > Is there any chance

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 9:25 AM, Linus Torvalds wrote: > On Wed, Dec 21, 2016 at 7:55 AM, George Spelvin > wrote: >> >> How much does kernel_fpu_begin()/kernel_fpu_end() cost? > > It's now better than it used to be, but it's absolutely

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

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 check if ipvlan->dev is up before feeding packets to netif_rx() 4) We need to prevent device from

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

On Wed, 2016-12-21 at 14:21 -0800, Mahesh Bandewar (महेश बंडेवार) wrote: > > > Thank you Eric for all these fixes. Thanks Mahesh. I will send a V2 to include this part as well : diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c index

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

On Thu, Dec 22, 2016 at 01:21:01AM +, Al Viro wrote: > On Wed, Dec 21, 2016 at 08:01:37PM -0500, Jon Maloy wrote: > > commit cbbd26b8b1a6 ("[iov_iter] new primitives - copy_from_iter_full() > > and friends") replaced calls to copy_from_iter() in the function > > tipc_msg_build(). This causes a

Re: [PATCH v7 1/6] siphash: add cryptographically secure PRF

On Thu, Dec 22, 2016 at 2:40 AM, Stephen Hemminger wrote: > The networking tree (net-next) which is where you are submitting to is > technically > closed right now. That's okay. At some point in the future it will be open. By then v83 of this patch set will be shiny

Re: [PATCH v7 1/6] siphash: add cryptographically secure PRF

On Thu, 22 Dec 2016 00:02:11 +0100 "Jason A. Donenfeld" wrote: > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function, or as a > general

Re: ipv6: handle -EFAULT from skb_copy_bits

On Wed, Dec 21, 2016 at 10:33:20PM +0100, Hannes Frederic Sowa wrote: > > Given all of this, I think the best thing to do is validate the offset > > after the queue walks, which is pretty much what Dave Jones's original > > patch was doing. > > I think both approaches protect against the

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

> -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 > Subject: Re: [PATCH] ethtool: add one ethtool option to set relax ordering > mode >

[PATCH net] ipvlan: fix multicast processing

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 failure is caused by the faulty logic that determines if the packet is from TX-path vs. RX-path by just

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

On Thu, 8 Dec 2016 14:51:38 +0800 Mao Wenan wrote: > This patch provides one way to set/unset IXGBE NIC TX and RX > relax ordering mode, which can be set by ethtool. > Relax ordering is one mode of 82599 NIC, to enable this mode > can enhance the performance for some cpu

Re: HalfSipHash Acceptable Usage

As a separate message, to disentangle the threads, I'd like to talk about get_random_long(). After some thinking, I still like the "state-preserving" construct that's equivalent to the current MD5 code. Yes, we could just do siphash(current_cpu || per_cpu_counter, global_key), but it's nice to

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

commit cbbd26b8b1a6 ("[iov_iter] new primitives - copy_from_iter_full() and friends") replaced calls to copy_from_iter() in the function tipc_msg_build(). This causes a an immediate crash as follows: [ 1209.597076] BUG: unable to handle kernel NULL pointer dereference at 0008 [

Re: [PATCH v7 6/6] siphash: implement HalfSipHash1-3 for hash tables

> 64-bit x86_64: > [0.509409] test_siphash: SipHash2-4 cycles: 4049181 > [0.510650] test_siphash: SipHash1-3 cycles: 2512884 > [0.512205] test_siphash: HalfSipHash1-3 cycles: 3429920 > [0.512904] test_siphash:JenkinsHash cycles: 978267 I'm not sure what these numbers

[PATCH] skfp: hwmtm: Use proper logging macros, correct mismatches

Logging macros should allow format and argument validation. The DB_TX, DB_RX, and DB_GEN macros did not. Update the macros and uses and add no_printk validation to the previously compiled away #ifndef DEBUG variants. Done with coccinelle and some typing. Signed-off-by: Joe Perches

Re: HalfSipHash Acceptable Usage

Theodore Ts'o wrote: > On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote: >> SipHash annihilates the competition on 64-bit superscalar hardware. >> SipHash dominates the field on 64-bit in-order hardware. >> SipHash wins easily on 32-bit hardware *with enough registers*. >> On

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

Hi, > -Original Message- > From: maowenan > Sent: Monday, December 12, 2016 4:29 PM > To: 'Andrew Lunn' > Cc: netdev@vger.kernel.org; jeffrey.t.kirs...@intel.com; weiyongjun (A) > Subject: RE: [PATCH] net: add one ethtool option to set relax ordering mode > > > > > -Original

Re: [PATCH iproute2 0/2] Man page fixes

On Tue, 13 Dec 2016 07:33:50 +0200 Roi Dayan wrote: > Hi, > > The 2 patches are man page related only. > First fixes a typo and second adding missing man page to the Makefile. > > Thanks > > Roi Dayan (2): > tc: flower: Fix typo in the flower man page > tc: tunnel_key:

Re: [PATCH iproute2 0/4] ip vrf fixups

On Thu, 15 Dec 2016 12:06:58 -0800 David Ahern wrote: > Some minor cleanups to the 'ip vrf' command. > > Patch 1 moves the CGROUP_BPF hint to the failure of prog_load since it > fails first. > > Patch 2 refactors ipvrf_identify. The action part is moved to a function

Re: [PATCH iproute2/net-next 0/2] tc: flower: enhance mask support

On Fri, 16 Dec 2016 14:54:35 +0100 Simon Horman wrote: > Hi, > > this short series enhances mask support for tc flower by: > * Documenting existing mask support for *_ip parameters > * Allowing *_mac options to accept a mask. > This makes use of existing kernel

Re: [PATCH] ip: vfinfo: remove code duplication for IFLA_VF_RSS_QUERY_EN

On Fri, 16 Dec 2016 17:36:05 +0100 Julien Fortin wrote: > From: Julien Fortin > > Fixes: 4fb4a10e120b1 ("ipaddress: Print IFLA_VF_QUERY_RSS_EN setting”) > > Signed-off-by: Julien Fortin Applied, thanks.

Food for thought: could cgroup+bpf live in a cgroup v1-compatible controller?

It seems to be that all of the new cgroup+bpf hooks and all of the proposed networking-related ones that I'm aware of look at sock_cgroup_ptr(). I'm wondering if this could me made cgroup v1 compatible? As far as I can tell, this could be done with no changes at all to the networking code and

Re: [PATCH net-next 00/10] netcp: enhancements and minor fixes

David, On 12/20/2016 07:03 PM, David Miller wrote: > > The net-next tree is not open, do not resubmit this series until it > is open again. > > Thanks. > Ok. Thanks -- Murali Karicheri Linux Kernel, Keystone

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

On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote: > unsigned int get_random_int(void) > { > - __u32 *hash; > - unsigned int ret; > - > - if (arch_get_random_int()) > - return ret; > - > - hash = get_cpu_var(get_random_int_hash); >

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

Hi Ted, On Thu, Dec 22, 2016 at 12:02 AM, Jason A. Donenfeld wrote: > This duplicates the current algorithm for get_random_int/long I should have mentioned this directly in the commit message, which I forgot to update: this v7 adds the time-based key rotation, which, while not

Re: [PATCH 2/2] net: wireless: fix to uses struct

22.12.2016, 01:06, "Paul Bolle" : > On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote: >>  I don't have a problem with C programming > > I'm sorry, but you do need to learn C, at a basic level, first. Hmm, I don't like to discussion but I'm an assertive on C/C++. So, I'm

Re: [PATCH 2/2] net: wireless: fix to uses struct

On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote: > I don't have a problem with C programming I'm sorry, but you do need to learn C, at a basic level, first. Paul Bolle

[PATCH v7 1/6] siphash: add cryptographically secure PRF

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function, or as a general PRF for short input use cases, such as sequence numbers or RNG chaining. For the first

[PATCH v7 0/6] The SipHash Patchset

Hey folks, Again we've made huge progress, with this latest version now shipping Jean-Phillipe Aumasson's HalfSipHash, which should be much more competitive with jhash (in addition to being more secure, of course). There are dozens of little cleanups and improvements right and left throughout

[PATCH v7 2/6] secure_seq: use SipHash in place of MD5

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, for IPv6, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. For IPv4, we pass the

[PATCH v7 5/6] syncookies: use SipHash in place of SHA1

SHA1 is slower and less secure than SipHash, and so replacing syncookie generation with SipHash makes natural sense. Some BSDs have been doing this for several years in fact. The speedup should be similar -- and even more impressive -- to the speedup from the sequence number fix in this series.

[PATCH v7 3/6] random: use SipHash in place of MD5

This duplicates the current algorithm for get_random_int/long, but uses siphash instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also separates hashed fields into three values instead of one, in order to increase diffusion.

[PATCH v7 4/6] md5: remove from lib and only live in crypto

The md5_transform function is no longer used any where in the tree, except for the crypto api's actual implementation of md5, so we can drop the function from lib and put it as a static function of the crypto file, where it belongs. There should be no new users of md5_transform, anyway, since

[PATCH v7 6/6] siphash: implement HalfSipHash1-3 for hash tables

HalfSipHash, or hsiphash, is a shortened version of SipHash, which generates 32-bit outputs using a weaker 64-bit key. It has *much* lower security margins, and shouldn't be used for anything too sensitive, but it could be used as a hashtable key function replacement, if the output is never

Re: [PATCH 2/2] net: wireless: fix to uses struct

My previous patch is invalid, I'm sorry. The last patc will be fellow because "regulatory_request" is defined as a "static struct". Signed-off-by: Ozgur Karatas --- net/wireless/reg.c | 10 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 2/2] net: wireless: fix to uses struct

22.12.2016, 00:34, "Paul Bolle" : > On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote: >>  I compiled and didn't to errors. > > Really? I'm very sorry. The "regulatory_request" is defined a static struct. I missed. line: static struct regulatory_request

Re: [PATCH 2/2] net: wireless: fix to uses struct

On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote: > I compiled and didn't to errors. Really? $ make net/wireless/reg.o CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 11:27 PM, Theodore Ts'o wrote: > And "with enough registers" includes ARM and MIPS, right? So the only > real problem is 32-bit x86, and you're right, at that point, only > people who might care are people who are using a space-radiation > hardened 386 ---

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote: > SipHash annihilates the competition on 64-bit superscalar hardware. > SipHash dominates the field on 64-bit in-order hardware. > SipHash wins easily on 32-bit hardware *with enough registers*. > On register-starved 32-bit machines,

[PATCH 2/2] net: wireless: fix to uses struct

The patch fixed to struct uses in reg.c, I think doesn't need to be use to "struct". There is dataype not have to logical link and each is different definitons. I'm undecided on this patch. I compiled and didn't to errors. Signed-off-by: Ozgur Karatas ---

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

On Wed, Dec 21, 2016 at 1:30 PM, Eric Dumazet wrote: > 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 check if

[PATCH 1/2] net: wireless: fixed to checkpatch errors

Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next line. The patch fix to readability and Coding Style. Sİgned-off-by: Ozgur Karatas --- net/wireless/chan.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git

Re: ipv6: handle -EFAULT from skb_copy_bits

On Wed, 2016-12-21 at 14:04 -0500, David Miller wrote: > From: Hannes Frederic Sowa > Date: Wed, 21 Dec 2016 13:41:13 +0100 > > > On Wed, 2016-12-21 at 13:27 +0100, Hannes Frederic Sowa wrote: > >> @@ -555,8 +566,8 @@ static int rawv6_push_pending_frames(struct sock

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

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 check if ipvlan->dev is up before feeding packets to netif_rx() 4) We need to prevent device from

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

On 12/21/2016 09:47 PM, Cong Wang wrote: On Wed, Dec 21, 2016 at 12:02 PM, Daniel Borkmann wrote: On 12/21/2016 08:10 PM, Cong Wang wrote: On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang wrote: On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann

Re: [PATCH] at86rf230: Allow slow GPIO pins for "rstn"

Hello. On 21/12/16 19:30, Chris Healy wrote: On Dec 21, 2016 5:11 AM, "Stefan Schmidt" > wrote: Hello. On 19/12/16 00:25, Andrey Smirnov wrote: Driver code never touches "rstn" signal in atomic context, so

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

On Wed, Dec 21, 2016 at 12:02 PM, Daniel Borkmann wrote: > On 12/21/2016 08:10 PM, Cong Wang wrote: >> >> On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang >> wrote: >>> >>> On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann >>>

Re: [PATCH] net: fddi: skfp: use %p format specifier for addresses rather than %x

From: Colin King Date: Wed, 21 Dec 2016 16:03:23 + > From: Colin Ian King > > Trivial fix: Addresses should be printed using the %p format specifier > rather than using %x. > > Signed-off-by: Colin Ian King

[PATCH v4 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 v4 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 --- v4: same as v3 v3: Added Brian's "Reviewed-by" v2: same as v1 drivers/bluetooth/btusb.c | 19 +-- 1 file

[PATCH v4 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: [PATCH net] tcp: add a missing barrier in tcp_tasklet_func()

From: Eric Dumazet Date: Wed, 21 Dec 2016 05:42:43 -0800 > From: Eric Dumazet > > Madalin reported crashes happening in tcp_tasklet_func() on powerpc64 > > Before TSQ_QUEUED bit is cleared, we must ensure the changes done > by list_del(>tsq_node);

BUG/panic in ctnetlink_conntrack_event in 4.8.11

Hi all, I've encountered this BUG three times in the last few days, though I must admit I've only captured the trace once so far so I can't be completely certain it was exactly this the last few times. I did not experience this with a 4.7 kernel; it only seemed to start with 4.8. For some

Re: [PATCH RFC net-next 3/7] sctp: add dst_pending_confirm flag

Hello, On Wed, 21 Dec 2016, Neil Horman wrote: > On Sun, Dec 18, 2016 at 10:56:32PM +0200, Julian Anastasov wrote: > > - tp->af_specific->sctp_xmit(head, tp); > > + confirm = tp->dst_pending_confirm; > > + if (confirm) > > + head->dst_pending_confirm = 1; > Why not use

Re: [PATCH v5] net: dummy: Introduce dummy virtual functions

On Wed, Dec 21, 2016 at 01:32:00PM -0500, David Miller wrote: > From: Phil Sutter > Date: Tue, 20 Dec 2016 23:26:21 +0100 > > > The idea for this was born when testing VF support in iproute2 which was > > impeded by hardware requirements. In fact, not every VF-capable hardware > >

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

On 12/21/2016 08:10 PM, Cong Wang wrote: On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang wrote: On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann wrote: What happens is that in tc_ctl_tfilter(), thread A allocates a new tp, initializes it, sets

Re: [PATCH 2/5 net-next] inet: kill smallest_size and smallest_port

On Wed, Dec 21, 2016 at 1:30 PM, David Miller wrote: From: Josef Bacik Date: Tue, 20 Dec 2016 15:07:01 -0500 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

Re: [PATCH 2/5 net-next] inet: kill smallest_size and smallest_port

On Wed, 2016-12-21 at 13:30 -0500, David Miller wrote: > From: Josef Bacik > Date: Tue, 20 Dec 2016 15:07:01 -0500 > > > 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

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

On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang wrote: > On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann wrote: >> What happens is that in tc_ctl_tfilter(), thread A allocates a new >> tp, initializes it, sets tp_created to 1, and calls into

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

On 12/21/2016 07:51 PM, Cong Wang wrote: On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann wrote: What happens is that in tc_ctl_tfilter(), thread A allocates a new tp, initializes it, sets tp_created to 1, and calls into tp->ops->change() with it. In that classifier

Re: ipv6: handle -EFAULT from skb_copy_bits

From: Hannes Frederic Sowa Date: Wed, 21 Dec 2016 13:41:13 +0100 > On Wed, 2016-12-21 at 13:27 +0100, Hannes Frederic Sowa wrote: >> @@ -555,8 +566,8 @@ static int rawv6_push_pending_frames(struct sock *sk, >> struct flowi6 *fl6, >> goto out; >> >>

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

On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann wrote: > What happens is that in tc_ctl_tfilter(), thread A allocates a new > tp, initializes it, sets tp_created to 1, and calls into tp->ops->change() > with it. In that classifier callback we had to unlock/lock the rtnl >

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 7:37 PM, George Spelvin wrote: > SipHash annihilates the competition on 64-bit superscalar hardware. > SipHash dominates the field on 64-bit in-order hardware. > SipHash wins easily on 32-bit hardware *with enough registers*. > On

Re: [PATCHv2] net: mvpp2: fix dma unmapping of TX buffers for fragments

From: Thomas Petazzoni Date: Wed, 21 Dec 2016 11:28:49 +0100 > Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX > buffers unmapping"), we are not correctly DMA unmapping TX buffers for > fragments. > > Indeed, the mvpp2_txq_inc_put()

Re: HalfSipHash Acceptable Usage

Eric Dumazet wrote: > Now I am quite confused. > > George said : >> Cycles per byte on 1024 bytes of data: >> Pentium Core 2 Ivy >> 4 Duo Bridge >> SipHash-2-4 38.9 8.3 5.8 >> HalfSipHash-2-4 12.7 4.5 3.2 >> MD5

Re: [PATCH v5] net: dummy: Introduce dummy virtual functions

From: Phil Sutter Date: Tue, 20 Dec 2016 23:26:21 +0100 > The idea for this was born when testing VF support in iproute2 which was > impeded by hardware requirements. In fact, not every VF-capable hardware > driver implements all netdev ops, so testing the interface is still hard >

Re: [PATCH] net: qcom/emac: add ethtool support

From: Timur Tabi Date: Tue, 20 Dec 2016 16:32:09 -0600 > Add support for some ethtool methods: get/set link settings, get/set > message level, get statistics, get link status, and restart > autonegotiation. > > Signed-off-by: Timur Tabi Please

Re: [PATCH 1/2] net: mdio: add mdio45_ethtool_ksettings_get

Please resubmit this patch series when net-next opens back up, thanks.

Re: [PATCH 2/5 net-next] inet: kill smallest_size and smallest_port

From: Josef Bacik Date: Tue, 20 Dec 2016 15:07:01 -0500 > 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

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

From: Josef Bacik Date: Tue, 20 Dec 2016 15:07:00 -0500 > The only difference between inet6_csk_bind_conflict and inet_csk_bind_conflict > is how they check the rcv_saddr. Since we want to be able to check the saddr > in > other places just drop the protocol specific

Re: [PATCH v3] stmmac: enable rx queues

From: Joao Pinto Date: Tue, 20 Dec 2016 17:09:28 + > When the hardware is synthesized with multiple queues, all queues are > disabled for default. This patch adds the rx queues configuration. > This patch was successfully tested in a Synopsys QoS Reference design. >

Re: [PATCH] net: ethernet: stmmac: dwmac-rk: make clk enablement first in powerup

From: Heiko Stuebner Date: Tue, 20 Dec 2016 17:17:06 +0100 > Right now the dwmac-rk tries to set up the GRF-specific speed and link > options before enabling clocks, phys etc and on previous socs this works > because the GRF is supplied on the whole by one clock. > > On the

Re: [PATCH net 3/3] cpsw/netcp: work around reverse cpts dependency

On 12/16/2016 03:19 AM, Arnd Bergmann wrote: The dependency is reversed: cpsw and netcp call into cpts, but cpts depends on the other two in Kconfig. This can lead to cpts being a loadable module and its callers built-in: drivers/net/ethernet/ti/cpsw.o: In function `cpsw_remove':

Re: [PATCH net] be2net: Increase skb headroom size to 256 bytes

From: Suresh Reddy Date: Tue, 20 Dec 2016 10:14:30 -0500 > From: Kalesh A P > > The driver currently allocates 128 bytes of skb headroom. > This was found to be insufficient with some configurations > like Geneve tunnels, which

Re: [PATCH] stmmac: CSR clock configuration fix

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 > every read operation returned 0x. This patch fixes

Re: HalfSipHash Acceptable Usage

Linus wrote: >> How much does kernel_fpu_begin()/kernel_fpu_end() cost? > > It's now better than it used to be, but it's absolutely disastrous > still. We're talking easily many hundreds of cycles. Under some loads, > thousands. I think I've been thoroughly dissuaded, but just to clarify one

[PATCH v3 net-next] bnx2x: ethtool -x support for rss_key

From: Eric Dumazet Implement ethtool -x full support, so that rss key can be fetched instead of assuming it matches /proc/sys/net/core/netdev_rss_key content. We might add "ethtool --rxfh" support later to set a different rss key. Tested: lpk51:~# ethtool --show-rxfh eth0

  1   2   3   >