From: Sudip Mukherjee
len has been initialized with a value of 0 and buf_len with 4096. There
is no way that this condition (len > buf_len) can be true now.
Signed-off-by: Sudip Mukherjee
---
drivers/net/wireless/ath/ath10k/debug.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/
Congratulations!!! You have been selected to participate in a paid Customer
Research Program known as “Secret Shopping”. As one of the people selected to
represent our firm, you will be acting as a Customer Service Evaluator of
selected companies in your area. Get back with the requested data be
Chipsets with BCM4707 / BCM53018 ID require special handling at a few
places in the code. It's likely there will be more IDs to check in the
future. To simplify it add this trivial helper.
Signed-off-by: Rafał Miłecki
---
It's the same change as sent few days ago, just resending it in a proper ti
Signed-off-by: Alexei Starovoitov
---
samples/bpf/tracex2_kern.c | 2 +-
samples/bpf/tracex2_user.c | 7 ++-
samples/bpf/tracex3_kern.c | 8
samples/bpf/tracex3_user.c | 21 ++---
4 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/samples/bpf/tracex2_
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr
Primary use case is a histogram array of latency
where bpf program computes the latency of block requests or other
events and stores histogram of latency into array of 64 elements.
All cpus are constantly running, so normal increment is not accurate,
bpf_xadd causes cache ping-pong and this per-cpu
From: "tom.leim...@gmail.com"
A sanity test for BPF_MAP_TYPE_PERCPU_ARRAY
Signed-off-by: Ming Lei
Signed-off-by: Alexei Starovoitov
---
samples/bpf/test_maps.c | 92 +
1 file changed, 92 insertions(+)
diff --git a/samples/bpf/test_maps.c b/samp
From: Martin KaFai Lau
A sanity test for BPF_MAP_TYPE_PERCPU_HASH.
Signed-off-by: Martin KaFai Lau
Signed-off-by: Alexei Starovoitov
---
samples/bpf/test_maps.c | 96 +
1 file changed, 96 insertions(+)
diff --git a/samples/bpf/test_maps.c b/sam
We've started to use bpf to trace every packet and atomic add
instruction (event JITed) started to show up in perf profile.
The solution is to do per-cpu counters.
For PERCPU_(HASH|ARRAY) map the existing bpf_map_lookup() helper
returns per-cpu area which bpf programs can use to store and
increment
Introduce BPF_MAP_TYPE_PERCPU_HASH map type which is used to do
accurate counters without need to use BPF_XADD instruction which turned
out to be too costly for high-performance network monitoring.
In the typical use case the 'key' is the flow tuple or other long
living object that sees a lot of ev
I think hackers chould build a malicious h323 packet to overflow
the pointer p which will panic during the memcpy(addr, p, len)
For example, he may fabricate a very large taddr->ipAddress.ip.
In order to avoid this, I add a valid memory reference check in
get_h2x5_addr functions.
As suggested by
On Tue, 2 Feb 2016 01:12:25 +0100
Daniel Borkmann wrote:
> Couple of minor updates on tc frontend.
>
> Stephen, the patches are against iproute2 -master branch and *on top of*
> the two that are already lingering in patchwork:
>
> - http://patchwork.ozlabs.org/patch/569923/
Some cruft snuck
On Fri, 22 Jan 2016 00:46:28 +0100
Daniel Borkmann wrote:
> Add a test that symbol from relocation entry is actually related
> to map section and bail out with an error message if it's not the
> case; in relation to [1].
>
> [1] https://llvm.org/bugs/show_bug.cgi?id=26243
>
> Signed-off-by: D
If we remove the SYN flag from the skbs that tcp_fastopen_add_skb()
places in socket receive queue, then we can remove the test that
tcp_recvmsg() has to perform in fast path.
All we have to do is to adjust SEQ in the slow path.
For the moment, we place an unlikely() and output a message
if we fi
Implements RFC 7413 (TCP Fast Open) 4.2.2, accepting payload and/or FIN
in SYNACK messages, and prepare removal of SYN flag in tcp_recvmsg()
Eric Dumazet (2):
tcp: fastopen: accept data/FIN present in SYNACK message
tcp: do not enqueue skb with SYN flag
include/net/tcp.h | 1 +
net/ip
RFC 7413 (TCP Fast Open) 4.2.2 states that the SYNACK message
MAY include data and/or FIN
This patch adds support for the client side :
If we receive a SYNACK with payload or FIN, queue the skb instead
of ignoring it.
Since we already support the same for SYN, we refactor the existing
code and r
On Tue, 2 Feb 2016 01:12:27 +0100
Daniel Borkmann wrote:
> With a bit larger, branchy eBPF programs f.e. already ~BPF_MAXINSNS/7 in
> size, it happens rather quickly that bpf(2) rejects also valid programs
> when only the verifier log buffer size we have in tc is too small.
>
> Change that, so
On Thu, 21 Jan 2016 02:23:49 +
Zhang Shengju wrote:
> the warning was:
> iproute.c:301:12: warning: 'val' may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>features &= ~RTAX_FEATURE_ECN;
> ^
> iproute.c:575:10: note: 'val' was declared here
>__u32 val;
On 16-02-01 06:17 PM, David Miller wrote:
> From: John Fastabend
> Date: Sun, 31 Jan 2016 17:53:10 -0800
>
>> +ixgbe_jump_tables[uhtid] = nexthdr->jump;
>
> I can't figure out what protects concurrent accesses to this shared
> ixgbe_jump_table[]. Is RTNL held here? If so it
On Tue, 19 Jan 2016 11:01:45 +
Nicolas Dichtel wrote:
> diff --git a/tc/tc_bpf.c b/tc/tc_bpf.c
> index 42c8841869f5..219ffa582c1a 100644
> --- a/tc/tc_bpf.c
> +++ b/tc/tc_bpf.c
> @@ -49,6 +49,10 @@
> #include "tc_util.h"
> #include "tc_bpf.h"
>
> +#ifndef AF_ALG
> +#define AF_ALG 38
> +#e
Eric Biggers wrote:
> This eliminates an "unused function" compiler warning when
> CONFIG_NF_CONNTRACK_LABELS is not defined.
>
> Signed-off-by: Eric Biggers
The nft_ct_get_eval_counter call should've been unconditional.
The #endif placement is wrong:
https://git.kernel.org/cgit/linux/kernel/g
However, I'll be travelling most of the day tomorrow so please be gentle.
:-)
On Mon, Feb 1, 2016 at 4:31 PM, Sowmini Varadhan
wrote:
> On (01/31/16 13:37), Tom Herbert wrote:
>>
>> Call get_unaligned_be32 when we access 32-bit fields in
>> __skb_flow_dissect. At the beginning check for unlikely case of
>> 1-byte aligned packet.
>>
>> Note that flow_dissector may be asked t
I think hackers chould build a malicious h323 packet to overflow
the pointer p which will panic during the memcpy(addr, p, len)
For example, he may fabricate a very large taddr->ipAddress.ip.
As suggested by Eric, this module is protected by a lock (nf_h323_lock)
so adding a variable h323_buffer_v
This eliminates an "unused function" compiler warning when
CONFIG_NF_CONNTRACK_LABELS is not defined.
Signed-off-by: Eric Biggers
---
net/netfilter/nft_ct.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c
index a0eb216..3cd6b5b 100644
--- a/n
From: David Ahern
Date: Mon, 1 Feb 2016 19:06:15 -0700
> Can you queue these up for 4.4 stable? Fixes 'ping6 -I '
> for VRFs and 4.4 is the first release with VRF for IPv6.
Sure, done.
From: John Fastabend
Date: Sun, 31 Jan 2016 17:53:10 -0800
> + ixgbe_jump_tables[uhtid] = nexthdr->jump;
I can't figure out what protects concurrent accesses to this shared
ixgbe_jump_table[]. Is RTNL held here? If so it's likely that
GFP_ATOMIC can be changed to GFP_KERNEL
A rcu stall with the following backtrace was seen on a system with
forwarding, optimistic_dad and use_optimistic set. To reproduce,
set these flags and allow ipv6 autoconf.
This occurs because the device write_lock is acquired while already
holding the read_lock. Back trace below -
INFO: rcu_pree
On 1/31/16 7:23 PM, YOSHIFUJI Hideaki wrote:
Hannes Frederic Sowa wrote:
On 29.01.2016 12:30, Paolo Abeni wrote:
Currently, the egress interface index specified via IPV6_PKTINFO
is ignored by __ip6_datagram_connect(), so that RFC 3542 section 6.7
can be subverted when the user space applicati
On 16-02-01 04:12 PM, Daniel Borkmann wrote:
> With a bit larger, branchy eBPF programs f.e. already ~BPF_MAXINSNS/7 in
> size, it happens rather quickly that bpf(2) rejects also valid programs
> when only the verifier log buffer size we have in tc is too small.
>
> Change that, so by default we d
On Mon, Feb 1, 2016 at 4:31 PM, Sowmini Varadhan
wrote:
> On (01/31/16 13:37), Tom Herbert wrote:
>>
>> Call get_unaligned_be32 when we access 32-bit fields in
>> __skb_flow_dissect. At the beginning check for unlikely case of
>> 1-byte aligned packet.
>>
>> Note that flow_dissector may be asked t
Operations with the GENL_ADMIN_PERM flag fail permissions checks because
this flag means we call netlink_capable, which uses the init user ns.
Instead, let's introduce a new flag, GENL_UNS_ADMIN_PERM for operations
which should be allowed inside a user namespace.
The motivation for this is to be
On (01/31/16 13:37), Tom Herbert wrote:
>
> Call get_unaligned_be32 when we access 32-bit fields in
> __skb_flow_dissect. At the beginning check for unlikely case of
> 1-byte aligned packet.
>
> Note that flow_dissector may be asked to parse packet unaligned
> fields in two instances:
I tested t
Add a couple of improvements to tc's BPF api, that facilitate program
development.
Signed-off-by: Daniel Borkmann
---
examples/bpf/bpf_cyclic.c | 4 +---
examples/bpf/bpf_graft.c| 13 +++
examples/bpf/bpf_prog.c | 26 ++---
examples/bpf/bpf_shared.c | 3 +--
Don't reimplement them and rather use the macros from the gelf header,
that is, GELF_ST_BIND()/GELF_ST_TYPE().
Signed-off-by: Daniel Borkmann
---
tc/tc_bpf.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/tc/tc_bpf.c b/tc/tc_bpf.c
index 5e80d0f..6a94894 100644
--- a/t
Provide some more hints to the user/developer when relos have been found
that don't point to ld64 imm instruction. Ran couple of times into relos
generated by clang [1], where the compiler tried to uninline inlined
functions with eBPF and emitted BPF_JMP | BPF_CALL opcodes. If this seems
the case,
Couple of minor updates on tc frontend.
Stephen, the patches are against iproute2 -master branch and *on top of*
the two that are already lingering in patchwork:
- http://patchwork.ozlabs.org/patch/569923/
- http://patchwork.ozlabs.org/patch/571385/
Thanks!
Daniel Borkmann (4):
tc, bpf, e
With a bit larger, branchy eBPF programs f.e. already ~BPF_MAXINSNS/7 in
size, it happens rather quickly that bpf(2) rejects also valid programs
when only the verifier log buffer size we have in tc is too small.
Change that, so by default we don't do any logging, and only in error
case we retry wi
> On Mon, 2016-02-01 at 11:37 -0800, Eric Dumazet wrote:
>
>> I would rather try :
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 38eeddedfc21..d6b7ab07f914 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -3538,6 +3538,7 @@ static void addrconf_dad_begi
This adds an rx_nohandler stat counter, along with a sysfs statistics
node, and copies the counter out via netlink as well.
CC: "David S. Miller"
CC: Eric Dumazet
CC: Jiri Pirko
CC: Daniel Borkmann
CC: Tom Herbert
CC: Jay Vosburgh
CC: Veaceslav Falico
CC: Andy Gospodarek
CC: netdev@vger.ke
The network core tries to keep track of dropped packets, but some packets
you wouldn't really call dropped, so much as intentionally ignored, under
certain circumstances. One such case is that of bonding and team device
slaves that are currently inactive. Their respective rx_handler functions
retur
CC: Jiri Pirko
CC: netdev@vger.kernel.org
Signed-off-by: Jarod Wilson
---
drivers/net/team/team.c | 10 +++---
include/linux/if_team.h | 1 +
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 718ceea..00558e1 100644
--- a/
The netdev_stats_to_stats64 function copies the deprecated
net_device_stats format stats into rtnl_link_stats64 for legacy support
purposes, but with the BUILD_BUG_ON as it was, it wasn't possible to
extend rtnl_link_stats64 without also extending net_device_stats. Relax
the BUILD_BUG_ON to only re
Sample output with this set applied for an active-backup bond:
$ cat /sys/devices/virtual/net/bond0/lower_p7p1/statistics/rx_nohandler
16568
$ cat /sys/devices/virtual/net/bond0/lower_p5p2/statistics/rx_nohandler
16583
$ cat /sys/devices/virtual/net/bond0/statistics/rx_nohandler
33151
CC: Jay Vos
This cleans up neighbour entries for all interfaces in the down
state, avoiding walking the whole neighbour table for each interface
being brought down.
Signed-off-by: Salam Noureddine
---
include/net/arp.h | 1 +
include/net/neighbour.h | 1 +
net/core/neighbour.c| 38 ++
This can be used to optimize bringing down and unregsitering
net_devices by running certain cleanup operations only on the
net namespace instead of on each net_device.
Signed-off-by: Salam Noureddine
---
include/linux/netdevice.h | 2 ++
net/core/dev.c| 39 ++
Call fib_flush at the end when closing or unregistering multiple
devices. This can save walking the fib many times and greatly
reduce rtnl_lock hold time when unregistering many devices with
a fib having hundreds of thousands of routes.
Signed-off-by: Salam Noureddine
---
include/net/netns/ipv4.
Signed-off-by: Salam Noureddine
---
include/net/net_namespace.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 4089abc..4cf47de 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
fib_flush walks the whole fib in a net_namespace and is called for
each net_device being closed or unregistered. This can be very expensive
when dealing with 100k or more routes in the fib and removal of a lot
of interfaces. These four patches deal with this issue by calling fib_flush
just once for
It looks like a lot but it's a mixture of regression fixes as well as fixes
for longer standing issues.
1) Fix on-channel cancellation in mac80211, from Johannes Berg.
2) Handle CHECKSUM_COMPLETE properly in xt_TCPMSS netfilter xtables module,
from Eric Dumazet.
3) Avoid infinite loop in UDP
On Mon, Feb 1, 2016 at 8:52 PM, Saeed Mahameed
wrote:
[...]
> in case it is, please consider using the vport_manager capability or
> any other device capability meant for this,
> to initialize and activate mlx5e_switchdev.
>
> After all such offload might not be supported in some devices. e.g VF
On 16-02-01 02:43 AM, Amir Vadai wrote:
> On Mon, Feb 01, 2016 at 01:31:17AM -0800, John Fastabend wrote:
>> On 16-02-01 12:34 AM, Amir Vadai wrote:
>>> During initialization, tcf_exts_offload_init() is called to initialize
>>> the list of actions description. later on, the classifier description
>
Sergei Shtylyov writes:
> On 02/01/2016 11:41 PM, Robert Jarzmik wrote:
>
The smc91x driver doesn't honor the probe deferral mechanism when the
interrupt source is not yet available, such as one provided by a gpio
controller not probed.
>
>>> What if 'ndev->irq' does equal 0?
>
On 02/01/2016 11:41 PM, Robert Jarzmik wrote:
The smc91x driver doesn't honor the probe deferral mechanism when the
interrupt source is not yet available, such as one provided by a gpio
controller not probed.
What if 'ndev->irq' does equal 0?
That's not possible AFAIR.
Possible if
On Fri, Jan 29, 2016 at 8:37 AM, Tycho Andersen
wrote:
> Hi Eric,
>
> Thanks for the review.
>
> On Fri, Jan 29, 2016 at 08:29:55AM -0600, Eric W. Biederman wrote:
>> Tycho Andersen writes:
>>
>> > Operations with the GENL_ADMIN_PERM flag fail permissions checks because
>> > this flag means we ca
Sergei Shtylyov writes:
> Hello.
>
> On 2/1/2016 1:46 AM, Robert Jarzmik wrote:
>
>> The smc91x driver doesn't honor the probe deferral mechanism when the
>> interrupt source is not yet available, such as one provided by a gpio
>> controller not probed.
>What if 'ndev->irq' does equal 0?
That
On 16-02-01 06:37 AM, Amir Vadai wrote:
> On Mon, Feb 01, 2016 at 01:21:36AM -0800, John Fastabend wrote:
>> On 16-02-01 12:34 AM, Amir Vadai wrote:
>>> Hi,
>>>
>>> So... just before sending that, I noted Jonh's series that
>>> deals with tc and u32. One notable difference between the
>>> two appr
On Mon, Feb 1, 2016 at 11:41 AM, David Miller wrote:
> From: David Laight
> Date: Mon, 1 Feb 2016 16:37:41 +
>
>> From: Lucas Tanure
>>> Sent: 30 January 2016 13:18
>>> As suggested by checkpatch.pl:
>>> CHECK: Prefer kernel type 'uX' over 'uintX_t'
>>
>> One might ask why?
>
> We have consis
On Mon, Feb 1, 2016 at 6:37 AM, Amir Vadai wrote:
> On Mon, Feb 01, 2016 at 01:21:36AM -0800, John Fastabend wrote:
>> On 16-02-01 12:34 AM, Amir Vadai wrote:
>> > Hi,
>> >
>> > So... just before sending that, I noted Jonh's series that
>> > deals with tc and u32. One notable difference between th
On Mon, 2016-02-01 at 11:37 -0800, Eric Dumazet wrote:
> I would rather try :
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 38eeddedfc21..d6b7ab07f914 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3538,6 +3538,7 @@ static void addrconf_dad_begin(struct
From: David Laight
Date: Mon, 1 Feb 2016 16:37:41 +
> From: Lucas Tanure
>> Sent: 30 January 2016 13:18
>> As suggested by checkpatch.pl:
>> CHECK: Prefer kernel type 'uX' over 'uintX_t'
>
> One might ask why?
We have consistently done this, and consistency is enough of an
argument.
From: Corcodel Marian
Date: Mon, 1 Feb 2016 18:05:20 +0200
> On reset and power on need 2msecs delay to autoload complete data
> from eeprom to VPD.
>
> Signed-off-by: Corcodel Marian
Where is this needed delay documented?
Unless you are a Realtek engineer, or learned about the requirement
On Mon, 2016-02-01 at 19:13 +, subas...@codeaurora.org wrote:
> A rcu stall with the following backtrace was seen on a system with
> forwarding, optimistic_dad and use_optimistic set. To reproduce,
> set these flags and then start ipv6 autoconf.
>
> This occurs because the device write_lock is
From: Corcodel Marian
Date: Mon, 1 Feb 2016 15:38:16 +0200
> Do not need to force on bus mastering , if alls is ok this is
> enabled on BIOS.
>
> Signed-off-by: Corcodel Marian
The chip can be used on systems without a BIOS and that should still
work.
The driver must fully program the card.
A rcu stall with the following backtrace was seen on a system with
forwarding, optimistic_dad and use_optimistic set. To reproduce,
set these flags and then start ipv6 autoconf.
This occurs because the device write_lock is acquired while already
holding the read_lock. Back trace below -
INFO: rcu
On Mon, Feb 1, 2016 at 10:34 AM, Amir Vadai wrote:
> Parse switchdev flow object into device specific commands and program
> the hardware to classify and mark/drop the flow accordingly.
>
> A new Kconfig is introduced: MLX5_EN_SWITCHDEV. This config enables to
> compile the driver when switchdev i
On 01/29/2016 10:59 PM, David Miller wrote:
There should be a default speed/duplex setting for such devices as well.
We can pick one that will be use universally for these kinds of devices.
There is at least one monitoring tool - collectl - which gets a trifle
upset when the actual speed throu
On Mon, Feb 1, 2016 at 8:50 AM, David Laight wrote:
> From: David Miller
>> Sent: 31 January 2016 03:45
>> To: alexander.du...@gmail.com
> ...
>> > I would really prefer to keep the pages DMA aligned, and the skb->data
>> > IP aligned. If nothing else it has the advantage of actually having
>> >
On Tue, Feb 2, 2016 at 1:49 AM, Eric Dumazet wrote:
> On Tue, 2016-02-02 at 01:16 +0800, Xin Long wrote:
>
>> no, no stack dump was found.
>> by reviewing code, I found it when I cooked another patch.
>>
>> and the path that __ip_do_redirect() is called should be:
>>
>> icmp_rcv |-> icmp_unreach
On Mon, 2016-02-01 at 18:58 +0100, Pablo Neira Ayuso wrote:
> On Fri, Jan 29, 2016 at 11:25:35AM +0800, Zhouyi Zhou wrote:
> > I think hackers chould build a malicious h323 packet to overflow
> > the pointer p which will panic during the memcpy(addr, p, len)
> > For example, he may fabricate a very
On Fri, Jan 29, 2016 at 11:25:35AM +0800, Zhouyi Zhou wrote:
> I think hackers chould build a malicious h323 packet to overflow
> the pointer p which will panic during the memcpy(addr, p, len)
> For example, he may fabricate a very large taddr->ipAddress.ip;
> As suggested by Eric, this module is p
On Tue, 2016-02-02 at 01:16 +0800, Xin Long wrote:
> no, no stack dump was found.
> by reviewing code, I found it when I cooked another patch.
>
> and the path that __ip_do_redirect() is called should be:
>
> icmp_rcv |-> icmp_unreach -\
> |-> icmp_redirect -> icmp_socket_deliver
Em 01-02-2016 15:03, Alexander Duyck escreveu:
> On Mon, Feb 1, 2016 at 8:22 AM, Marcelo Ricardo Leitner
> wrote:
>> Em 30-01-2016 02:07, Alexander Duyck escreveu:
>>>
>>> On Fri, Jan 29, 2016 at 11:42 AM, Marcelo Ricardo Leitner
>>> wrote:
On Fri, Jan 29, 2016 at 11:15:54AM -0800, Ale
On Mon, 2016-02-01 at 16:55 +, David Laight wrote:
> From: Eric Dumazet
> > Sent: 29 January 2016 22:29
> ...
> > On modern intel cpus, this does not matter at all, sure. It took a while
> > before "rep movsb" finally did the right thing.
>
> Unfortunately memcpy_to_io() etc now map to 'rep mo
>
> But the whole __ip_do_redirect() needs to be called from rcu_read_lock()
> already.
>
> No need to add another rcu_read_lock() around fib_lookup()
>
> How did you come doing this patch ? Any particular stack dump or
> something ?
>
no, no stack dump was found.
by reviewing code, I found it when
On Mon, Feb 1, 2016 at 8:22 AM, Marcelo Ricardo Leitner
wrote:
> Em 30-01-2016 02:07, Alexander Duyck escreveu:
>>
>> On Fri, Jan 29, 2016 at 11:42 AM, Marcelo Ricardo Leitner
>> wrote:
>>>
>>> On Fri, Jan 29, 2016 at 11:15:54AM -0800, Alexander Duyck wrote:
On Wed, Jan 27, 2016 at 9:06
From: Eric Dumazet
> Sent: 29 January 2016 22:29
...
> On modern intel cpus, this does not matter at all, sure. It took a while
> before "rep movsb" finally did the right thing.
Unfortunately memcpy_to_io() etc now map to 'rep movsb', and that can
only be optimisied for cached addresses.
So copie
From: David Miller
> Sent: 31 January 2016 03:45
> To: alexander.du...@gmail.com
...
> > I would really prefer to keep the pages DMA aligned, and the skb->data
> > IP aligned. If nothing else it has the advantage of actually having
> > the proper alignment on all the headers if I only pull the out
From: Florian Westphal
> Sent: 30 January 2016 21:30
> Weidong Wang wrote:
> > In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size,
> > so remove the check
> > @@ -1383,14 +1383,12 @@ get_next_corpse(struct net *net, int (*iter)(struct
> > nf_conn *i, void *data),
> > lockp
From: Lucas Tanure
> Sent: 30 January 2016 13:18
> As suggested by checkpatch.pl:
> CHECK: Prefer kernel type 'uX' over 'uintX_t'
One might ask why?
The kernel types are older, but the uintX_t ones are now part
of the C standard.
Writing header files (eg for ioctl buffers) that have to be
parsed
Em 30-01-2016 02:07, Alexander Duyck escreveu:
On Fri, Jan 29, 2016 at 11:42 AM, Marcelo Ricardo Leitner
wrote:
On Fri, Jan 29, 2016 at 11:15:54AM -0800, Alexander Duyck wrote:
On Wed, Jan 27, 2016 at 9:06 AM, Marcelo Ricardo Leitner
...
diff --git a/net/core/dev.c b/net/core/dev.c
index
8c
Hi all,
I (still) have a problem with 4.4.0 having lookups and oopsing. This
happens not instantly: when I run some test program *) on 10 machines, at
the next morning 6-8 have this issue.
Via the serial port I catch the output of "journalctl -f" and get this:
...
06:35:01 CRON[27050]: pam_unix(
On reset and power on need 2msecs delay to autoload complete data from
eeprom to VPD.
Signed-off-by: Corcodel Marian
---
drivers/net/ethernet/realtek/r8169.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index
On (02/01/16 16:20), Nicolas Dichtel wrote:
> There is also the tile architecture, up to 76 cores on the board I've seen. It
> requires an alignment on 8!
> I wonder how this case may be properly handled. A simple ipip scenario fails.
Yes, I'm also observing the same thing. Simply setting up greta
>-Original Message-
>From: zyjzyj2...@gmail.com [mailto:zyjzyj2...@gmail.com]
>Sent: Sunday, January 31, 2016 11:28 PM
>To: zyjzyj2...@gmail.com; Tantilov, Emil S; Schmitt, Phillip J; Kirsher,
>Jeffrey T; netdev@vger.kernel.org; e1000-de...@lists.sourceforge.net;
>Shteinbock, Boris (Wind Ri
>-Original Message-
>From: zyjzyj2...@gmail.com [mailto:zyjzyj2...@gmail.com]
>Sent: Sunday, January 31, 2016 11:28 PM
>To: zyjzyj2...@gmail.com; Tantilov, Emil S; Schmitt, Phillip J; Kirsher,
>Jeffrey T; netdev@vger.kernel.org; e1000-de...@lists.sourceforge.net;
>Shteinbock, Boris (Wind Ri
On 1/5/2016 7:45 PM, David Miller wrote:
From: Giuseppe CAVALLARO
Date: Tue, 5 Jan 2016 10:03:28 +0100
On 1/5/2016 4:25 AM, David Miller wrote:
From: Giuseppe Cavallaro
Date: Mon, 4 Jan 2016 14:06:46 +0100
@@ -376,7 +376,8 @@ extern const struct stmmac_desc_ops ndesc_ops;
/* Specific DM
Le 01/02/2016 01:39, Florian Fainelli a écrit :
Le 31/01/2016 16:24, Eric Dumazet a écrit :
On Sun, 2016-01-31 at 13:37 -0800, Tom Herbert wrote:
Call get_unaligned_be32 when we access 32-bit fields in
__skb_flow_dissect. At the beginning check for unlikely case of
1-byte aligned packet.
Note
My recent patch to the Xen Project documents a protocol for 'dynamic
multicast control' in netif.h. This extends the previous multicast control
protocol to not require a shared ring reconnection to turn the feature off.
Instead the backend watches the "request-multicast-control" key in xenstore
and
On Mon, Feb 01, 2016 at 01:21:36AM -0800, John Fastabend wrote:
> On 16-02-01 12:34 AM, Amir Vadai wrote:
> > Hi,
> >
> > So... just before sending that, I noted Jonh's series that
> > deals with tc and u32. One notable difference between the
> > two approaches is that here we "normalize" the upp
On Thu, Jan 28, 2016 at 02:26:04PM -0700, Troy Kisky wrote:
> Signed-off-by: Troy Kisky
> ---
> arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> b/arch/arm/boot/dts/imx6qdl-nitrogen6_max
On Thu, Jan 28, 2016 at 02:26:03PM -0700, Troy Kisky wrote:
> Signed-off-by: Troy Kisky
> ---
> arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
On Mon, 2016-02-01 at 18:22 +0800, Xin Long wrote:
> But there may be an issue in __ip_do_redirect():
> } else {
> if (fib_lookup(net, fl4, &res, 0) == 0) {
> struct fib_nh *nh = &FIB_RES_NH(res);
>
> update_or_create_fnhe(nh, fl4->daddr, ne
Do not need to force on bus mastering , if alls is ok this is
enabled on BIOS.
Signed-off-by: Corcodel Marian
---
drivers/net/ethernet/realtek/r8169.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index a8fb86d..
Hi Sergei,
On lun., févr. 01 2016, Sergei Shtylyov
wrote:
> Hello.
>
> On 2/1/2016 4:07 PM, Gregory CLEMENT wrote:
>
>> Since the commit 2dcf75e2793c ("net: mvneta: Associate RX queues with
>> each CPU") all the percpu irq are used and unmask at initialization, so
>
>Unmasked, you mean?
On 2/1/2016 4:07 PM, Gregory CLEMENT wrote:
Electing a CPU must be done in an atomic way: it should be done after or
before the removal/insertion of a CPU and this function is not reentrant.
During the loop of mvneta_percpu_elect we associates the queues to the
CPUs, if there is a topology chan
Hello.
On 2/1/2016 4:07 PM, Gregory CLEMENT wrote:
Since the commit 2dcf75e2793c ("net: mvneta: Associate RX queues with
each CPU") all the percpu irq are used and unmask at initialization, so
Unmasked, you mean?
there is no point to unmask them first.
Mask, maybe (looking at the pa
Hello.
On 2/1/2016 12:44 PM, Parthasarathy Bhuvaragan wrote:
Until now, the subscribers endianness for a subscription
create/cancel request is determined as:
swap = !(s->filter & (TIPC_SUB_PORTS | TIPC_SUB_SERVICE))
The checks are performed only for port/service subscriptions.
The swap ca
On Thu, Jan 28, 2016 at 4:17 PM, Kees Cook wrote:
> Some callers of strtobool were passing a pointer to unterminated strings.
> This fixes the issue and consolidates some logic in cifs.
My comments below.
First of all I don't think currently there is an issue in cifs, since
strbool checks only f
On 01/27/2016 07:12 PM, Hannes Frederic Sowa wrote:
On 27.01.2016 16:15, Eric Dumazet wrote:
If it is a common one, it should be /proc/sys/net/core/... instead
of /proc/sys/net/ipv4/tcp_
>
Other providers include :
1) GRO stack
2) callers of sock_alloc_send_pskb(), alloc_skb_with_frags
1 - 100 of 147 matches
Mail list logo
