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-to
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 thousand times, a
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 standard implementations aren't
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 directio
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-to
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 f
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 iterate 100K times, I timed the f
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
---
.../devicetree
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 reading (workqueue)
before
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 configurati
> 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 mov
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 fro
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 a/net/rds/rdma.c b/net/rds/rdma.c
> -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
> ; Ying Xue
> ; ma...@donjonn.com; tipc-
> discuss...@lists.sourc
From: Dave Jones
Date: Wed, 21 Dec 2016 20:40:19 -0500
> 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
> > > patc
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, was that batching
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 c
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
>
> The proposal made sense t
> 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 requ
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 += result + entropy;
>
> wou
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;
>>> - unsigned int ret;
>>> -
>>> - if (arch_
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.
> [ 1209.59707
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. Yes, we could just do
> sipha
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(&ret))
>> - return ret;
>> -
>> - ha
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 you
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 disastrous
> still. We're talking easily many hundreds of cyc
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 disappearing if some pa
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
693ec5b6622233cd3a28c64c11d6abb
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
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 and done, just waiting for th
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 PRF for short inpu
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 bug
> -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
>
>
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 looking at the mac-
ad
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 architecure.
Then it sho
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
pr
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
[ 1209.6
> 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 m
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
---
Compile
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 register
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 Message
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: Add tc-tunnel_key ma
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
> that can be used standalo
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 features.
>
> Based on net-next
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.
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 onl
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
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(&ret))
> - return ret;
> -
> - hash = get_cpu_var(get_random_int_hash);
> -
> - ha
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 strictly necessary
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 not into the Linux k
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
thi
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
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 usa
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 va
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.
The
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.
S
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 there
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 exposed
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 a/net/wireless/reg.c b/net/wire
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 core_request_world = {
I send to wro
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
CHK
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 --- and they're not
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, i
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
---
net/wireless/reg.c | 10 +-
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 ipvlan->dev is up before feeding packets
> to
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 a/net/wireless/chan.c b/net/wireless/
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 *sk,
> >> struct flowi6 *fl6
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 disappearing if some pa
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
wrote:
What happens is that in tc_ctl_tfilter(), t
Hello.
On 21/12/16 19:30, Chris Healy wrote:
On Dec 21, 2016 5:11 AM, "Stefan Schmidt" mailto:ste...@osg.samsung.com>> wrote:
Hello.
On 19/12/16 00:25, Andrey Smirnov wrote:
Driver code never touches "rstn" signal in atomic context, so
there's
no need to imp
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
>>> wrote:
What happens is that in tc_ctl_tfilter(), thread A allocat
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
Applied.
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
Re
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 changed, 9 insertions(+), 10 deletions(-)
diff --git
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 ho
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(&tp->tsq_node); are committed to memory, otherwise
> corru
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 backgro
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 y
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
> > driver implemen
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 tp_created to 1, and calls into tp->ops->change()
wit
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
existing set of
SO_REUSEPORT's. Howev
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 set
> > of
> > S
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 tp->ops->change()
>> with it. In that classifier callback
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 callback we had to unlock/lo
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;
>>
>> offset = rp->offset;
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
> mutex and returned with
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 register-starved 32-bit machines, it really
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() function only stores in the
> txq_cpu->tx_buf
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
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
> to do even wit
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 resubmit when net-next opens back up, thanks.
Please resubmit this patch series when net-next opens back up, thanks.
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 (smallest_size != -1)
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 ->bind_conflict and replace
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.
>
> Signed-off-by: Joao Pin
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 rk3399 however the GR
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':
cpsw.c:(.text
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 resulted in skb head reallocations.
>
> Increase the headroom to 2
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 the issue.
>
> Signed-of
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 thing
1 - 100 of 231 matches
Mail list logo
