On Sun, Jan 07, 2018 at 09:23:47PM -0500, David Miller wrote:
> From: Thomas Gleixner
> Date: Sun, 7 Jan 2018 21:56:39 +0100 (CET)
>
> > I surely agree, but we have gone the way of PTI without the ability of
> > exempting individual processes exactly for one reason:
> >
> > Lack of time
> >
>
On 05/01/18 18:47, Guillaume Nault wrote:
> The "offset" option has been removed by
> commit 900631ee6a26 ("l2tp: remove configurable payload offset").
>
> Signed-off-by: Guillaume Nault
> ---
> include/uapi/linux/l2tp.h | 2 +-
> net/l2tp/l2tp_core.c | 7 +++
> 2 files changed, 4 insert
>> @@ -708,11 +708,11 @@ static void svc_addr(struct seq_file *seq, struct
>> sockaddr_atmsvc *addr)
>> static int e164[] = { 1, 8, 4, 6, 1, 0 };
>>
>> if (*addr->sas_addr.pub) {
>> - seq_printf(seq, "%s", addr->sas_addr.pub);
>> + seq_puts(seq, addr->sa
Fix the following 'make htmldocs' complaint:
Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't included in
any toctree.
Signed-off-by: Mike Rapoport
---
Documentation/networking/index.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networ
From: Marco Franchi Sent: Friday, January 05, 2018 11:03 PM
>Hi,
>
>I am getting the following warning on a imx6ul-evk board running linux-next
>20180105:
>
>[9.233290] [ cut here ]
>[9.242068] WARNING: CPU: 0 PID: 0 at
>./include/linux/netfilter.h:233 arp_rcv+0x1f8
On Mon, Jan 08, 2018 at 11:35:26AM +1100, James Morris wrote:
> On Tue, 2 Jan 2018, Mahesh Bandewar (महेश बंडेवार) wrote:
>
> > On Sat, Dec 30, 2017 at 12:31 AM, James Morris
> > wrote:
> > > On Wed, 27 Dec 2017, Mahesh Bandewar (महेश बंडेवार) wrote:
> > >
> > >> Hello James,
> > >>
> > >> Seems
The patch (7235acdb1) changed the way of the work
flushing in which the queued seq, done seq, and the
flushing are not used anymore. Then remove them now.
Fixes: 7235acdb1 ("vhost: simplify work flushing")
Cc: Jason Wang
Signed-off-by: Tonghao Zhang
---
drivers/vhost/vhost.c | 1 -
drivers/vhos
On 1/7/18 7:03 PM, Chris Mi wrote:
>> Did you measure the effect of increasing batch sizes?
> Yes. Even if we enlarge the batch size bigger than 10, there is no big
> improvement.
That will change over time so the tc command should allow auto-batching
to work up to the message size limit.
> I
On 2018年01月06日 00:21, Willem de Bruijn wrote:
On Fri, Jan 5, 2018 at 4:54 AM, Jason Wang wrote:
This patch allows userspace to attach eBPF filter to tun. This will
allow to implement VM dataplane filtering in a more efficient way
compared to cBPF filter by allowing either qemu or libvirt to
a
On 2018/1/6 3:32, Al Viro wrote:
> Users of XLGMAC_SET_REG_BITS_LE() expect it to take le32 and return
> le32.
>
> Signed-off-by: Al Viro
> ---
> drivers/net/ethernet/synopsys/dwc-xlgmac.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/synopsy
The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.
A quote from goolge project zero blog:
"At this point, it would normally be necessary to locate gadgets in
the host kernel code that can be used to actually leak data by reading
from an attacker-controlled location, s
David Miller writes:
> From: Michael Ellerman
> Date: Fri, 22 Dec 2017 15:22:22 +1100
>
>>> On Tue, Dec 19 2017, Michael Ellerman
>>> wrote:
This revert seems to have broken networking on one of my powerpc
machines, according to git bisect.
The symptom is DHCP fails and I d
On 12/29/17 12:20 AM, Masami Hiramatsu wrote:
Please run Josef's test in the !ftrace setup.
Yes, I'll add the result of the test case.
if Josef's test is passing in !ftrace config,
please resend your patches.
I think 2 and 3 were nice simplifications.
and patch 1 is good too if it's passes the
On Sun, Jan 07, 2018 at 01:59:35PM +, Alan Cox wrote:
> > which means that POC is relying 64-bit address speculation.
> > In the places coverity found the user supplied value is 32-bit,
>
> People have 32bit computers as well as 64bit and in some cases 32bit is
> fine for an attack depending w
From: Ido Schimmel
Date: Sun, 7 Jan 2018 12:45:00 +0200
> This set tries to eliminate some differences between IPv4's and IPv6's
> treatment of nexthops. These differences are most likely a side effect
> of IPv6's data structures (specifically 'rt6_info') that incorporate
> both the route and th
On Sun, Jan 07, 2018 at 12:15:40PM -0800, Dan Williams wrote:
>
> I'm thinking we should provide the option to at least build the
> hot-path nospec_array_ptr() usages without an lfence.
>
> CONFIG_SPECTRE1_PARANOIA_SAFE
> CONFIG_SPECTRE1_PARANOIA_PERF
SAFE vs PERF naming is problematic a
From: Daniel Borkmann
Date: Mon, 8 Jan 2018 00:56:16 +0100
> The following pull-request contains BPF updates for your *net-next* tree.
>
> The main changes are:
...
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
>
> Thanks a
From: Thomas Gleixner
Date: Sun, 7 Jan 2018 21:56:39 +0100 (CET)
> I surely agree, but we have gone the way of PTI without the ability of
> exempting individual processes exactly for one reason:
>
> Lack of time
>
> It can be done on top of the PTI implementation and it won't take ages.
>
>
On Sun, Jan 07, 2018 at 11:08:24AM +0100, Thomas Gleixner wrote:
> On Sat, 6 Jan 2018, Alexei Starovoitov wrote:
> > which clearly states that bpf_tail_call() was used in the attack.
> > Yet none of the intel nor arm patches address speculation in
> > this bpf helper!
> > It means that:
> > - gpz d
From: Thomas Gleixner
Date: Sun, 7 Jan 2018 19:31:41 +0100 (CET)
> 2) Alexei's analyis is purely based on the public information of the google
>zero folks. If it would be complete and the only attack vector all fine.
>
>If not and I doubt it is, we're going to regret this decision faster
> -Original Message-
> From: n...@orbyte.nwl.cc [mailto:n...@orbyte.nwl.cc] On Behalf Of Phil
> Sutter
> Sent: Saturday, January 6, 2018 1:25 AM
> To: Chris Mi
> Cc: netdev@vger.kernel.org; gerlitz...@gmail.com;
> step...@networkplumber.org; dsah...@gmail.com;
> marcelo.leit...@gmail.com
>
On 01/05/2018 11:32 AM, Al Viro wrote:
>
> A few places got missed by "net: ethernet: stmmac: change dma descriptors
> to __le32" (having been introduced just before the merge of that patch,
> AFAICS). Fix them up...
I could not spot the commit id associated with that change, which one is it?
Under speculation, CPUs may mis-predict branches in bounds checks. Thus,
memory accesses under a bounds check may be speculated even if the
bounds check fails, providing a primitive for building a side channel.
To avoid leaking kernel data round up array-based maps and mask the index
after bounds
On 01/05/2018 11:32 AM, Al Viro wrote:
>
> Signed-off-by: Al Viro
> ---
> drivers/net/ethernet/broadcom/bcmsysport.c | 2 +-
> drivers/net/ethernet/broadcom/bgmac.h | 6 +++---
> drivers/net/ethernet/broadcom/bnx2.c | 6 +++---
> drivers/net/ethernet/broadcom/cnic_if.h
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
The main changes are:
1) Add a start of a framework for extending struct xdp_buff without
having the overhead of populating every data at runtime. Idea
is to have a new per-queue struct xdp_rxq_info that ho
From: Colin Ian King
Use the ARRAY_SIZE macro on array seg6_action_table to determine size of
the array. Improvement suggested by coccinelle.
Signed-off-by: Colin Ian King
---
net/ipv6/seg6_local.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_local.c b/net/
From: Colin Ian King
Use the ARRAY_SIZE macro on array cmd_priv_map to determine size of the
array. Improvement suggested by coccinelle.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ne
From: Colin Ian King
Use the ARRAY_SIZE macro on array buf to determine size of the array.
Improvement suggested by coccinelle.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethern
On Sat, Jan 6, 2018 at 11:44 PM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Sat, 6 Jan 2018 22:34:12 +0100
>
> Two strings should be quickly put into a sequence by two function calls.
> Thus use the function "seq_puts" instead of "seq_printf".
>
> This issue was detected by using the
On Sun, Jan 07, 2018 at 12:17:11PM -0800, Linus Torvalds wrote:
> We need to fix the security problem, but we need to do it *without*
> these braindead arguments that performance is somehow secondary.
OK OK. At least we should have security by default and let people trade
it against performance if
Hi Stephen,
> How is this binary compatiable with older versions.
I'm not sure what you mean. Kernel expects family attribute to be passed as u8
(and it always did). But current ip passes family attribute as u16. It works
now only on little endian systems because the relevant byte happens to be on
On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab
wrote:
>
> Em Sat, 6 Jan 2018 16:04:16 +0100
> "Josef Griebichler" escreveu:
>>
>> the causing commit has been identified.
>> After reverting commit
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b20
On Sun, 7 Jan 2018, Linus Torvalds wrote:
> We need to fix the security problem, but we need to do it *without*
> these braindead arguments that performance is somehow secondary.
I surely agree, but we have gone the way of PTI without the ability of
exempting individual processes exactly for one r
> On Jan 6, 2018, at 10:31 PM, Yafang Shao wrote:
>
> As of now, there're two sk_family are traced with sock:inet_sock_set_state,
> which are AF_INET and AF_INET6.
> So the sk_family are exposed as well.
> Then we can conveniently use it to do the filter.
>
> Both sk_family and sk_protocol are
On Sun, 7 Jan 2018 15:28:13 +0100
Filip Moc wrote:
> This fixes fou on big-endian systems.
>
> Signed-off-by: Filip Moc
> ---
> ip/ipfou.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ip/ipfou.c b/ip/ipfou.c
> index febc2c8c..1f392ade 100644
> --- a/ip/ipfou.c
On Sun, Jan 7, 2018 at 12:12 PM, Willy Tarreau wrote:
>
> Linus, no need to explain that to me, I'm precisely trying to see how
> to disable PTI for a specific process because I face up to 45% loss in
> certain circumstances, making it a no-go. But while a few of us have
> very specific workloads
On Sun, Jan 7, 2018 at 11:47 AM, Linus Torvalds
wrote:
> On Sat, Jan 6, 2018 at 10:33 PM, Willy Tarreau wrote:
>>
>> To be fair there's overreaction on both sides. The vast majority of
>> users need to get a 100% safe system and will never notice any
>> difference.
>
> There is no such thing as
On Sun, Jan 07, 2018 at 11:47:07AM -0800, Linus Torvalds wrote:
> And the whole "normal people won't even notice" is pure garbage too.
> Don't spread that bullshit when you see actual normal people
> complaining.
>
> Performance matters. A *LOT*.
Linus, no need to explain that to me, I'm precisel
From: Markus Elfring
Date: Sun, 7 Jan 2018 21:03:26 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/net/hyperv/netvsc.c | 5 -
1 file changed, 5 deletions(-)
di
On Sat, Jan 6, 2018 at 10:33 PM, Willy Tarreau wrote:
>
> To be fair there's overreaction on both sides. The vast majority of
> users need to get a 100% safe system and will never notice any
> difference.
There is no such thing as a "100% safe system". Never will be - unless
you make sure you ha
On Sun, Jan 7, 2018 at 1:09 AM, Greg KH wrote:
[..]
> Sorry for the confusion, no, I don't mean the "taint tracking", I mean
> the generic pattern of "speculative out of bounds access" that we are
> fixing here.
>
> Yes, as you mentioned before, there are tons of false-positives in the
> tree, as
> everyone. I'm not saying this always happens, but it is reasonable to
> let the iterative pushback see if we can get to better code in this
> case rather than trying to cut it of with the "because *security*"
> argument.
>
I'm not arguing otherwise - I'd just prefer most users machines are
sec
When using the MAPv4 packet format in conjunction with MAP commands,
a dummy DL checksum trailer will be appended to the packet. Before
this packet is sent out as an ACK, the DL checksum trailer needs to be
removed.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/
Real devices may support scatter gather(SG), so enable SG on rmnet
devices to use GSO. GSO reduces CPU cycles by 20% for a rate of
146Mpbs for a single stream TCP connection.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c | 1 +
1 file changed,
The real device over which the rmnet devices are installed also
aggregate multiple IP packets and sends them as a single large
aggregate frame to the hardware. This causes degraded throughput
for TCP TX due to bufferbloat.
To overcome this problem, pacing shift value of 8 is set using the
sk_pacin
TX checksum offload applies to TCP / UDP packets which are not
fragmented using the MAPv4 checksum trailer. The following needs to be
done to have checksum computed in hardware -
1. Set the checksum start offset and inset offset.
2. Set the csum_enabled bit
3. Compute and set 1's complement of par
This is done so that we can use this field for both ingress and
egress flags.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 10 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 2 +-
drivers/net/ethernet/qualcomm/rmnet/
The MAPv4 packet format adds support for RX / TX checksum offload.
For a bi-directional UDP stream at a rate of 570 / 146 Mbps, roughly
10% CPU cycles are saved.
For receive path, there is a checksum trailer appended to the end of
the MAP packet. The valid field indicates if hardware has computed
rmnet devices cannot have a mux id of 255. This is validated when
assigning the mux id to the rmnet devices. As a result, checking for
mux id 255 does not apply in egress path.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 5 +
1 fil
When using the MAPv4 packet format, receive checksum offload can be
enabled in hardware. The checksum computation over pseudo header is
not offloaded but the rest of the checksum computation over
the payload is offloaded. This applies only for TCP / UDP packets
which are not fragmented.
rmnet vali
rmnet_map_demultiplex() is only declared but not defined anywhere,
so remove it.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
b/drivers/net/eth
This series introduces the MAPv4 packet format for checksum
offload plus some other minor changes.
Patches 1-3 are cleanups.
Patch 4 renames the ingress format to data format so that all data
formats can be configured using this going forward.
Patch 5 uses the pacing helper to improve TCP transm
We already check the headroom once in rmnet_map_egress_handler(),
so this is not needed.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data
Sun, Jan 07, 2018 at 03:43:28PM CET, j...@mojatatu.com wrote:
>From: Jamal Hadi Salim
>
>Fixes: 249284ff5a44 ("tc: jsonify filter core")
>Signed-off-by: Jamal Hadi Salim
>---
> tc/tc_filter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/tc/tc_filter.c b/tc/tc_filter.c
>i
On Sun, 7 Jan 2018, James Bottomley wrote:
> On Sat, 2018-01-06 at 20:36 -0500, David Miller wrote:
> > From: Willy Tarreau
> > Date: Sat, 6 Jan 2018 21:42:29 +0100
> >
> > > On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
> > >> Normally people who propose security fixes don't have to
On Sat, Jan 6, 2018 at 10:16 PM, Martin KaFai Lau wrote:
> On Sat, Jan 06, 2018 at 05:41:28PM -0800, Wei Wang wrote:
>> On Fri, Jan 5, 2018 at 11:42 PM, Martin KaFai Lau wrote:
>> > On Fri, Jan 05, 2018 at 05:38:35PM -0800, Wei Wang wrote:
>> >> From: Wei Wang
>> >>
>> >> In the current code, wh
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> This set tries to eliminate some differences between IPv4's and IPv6's
> treatment of nexthops. These differences are most likely a side effect
> of IPv6's data structures (specifically 'rt6_info') that incorporate
> both the route and the nexthop and the la
On Sat, 2018-01-06 at 20:36 -0500, David Miller wrote:
> From: Willy Tarreau
> Date: Sat, 6 Jan 2018 21:42:29 +0100
>
> > On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
> >> Normally people who propose security fixes don't have to argue
> about the
> >> fact they added 30 clocks to avo
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> Check that IPv4 and IPv6 react the same when the carrier of a netdev is
> toggled. Local routes should not be affected by this, whereas unicast
> routes should.
>
> Signed-off-by: Ido Schimmel
> ---
> tools/testing/selftests/net/fib_tests.sh | 142
>
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> Check that IPv4 and IPv6 react the same when a netdev is being put
> administratively down.
>
> Signed-off-by: Ido Schimmel
> ---
> tools/testing/selftests/net/fib_tests.sh | 141
> +++
> 1 file changed, 141 insertions(+)
>
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> Add test cases to check that IPv4 and IPv6 react to a netdev being
> unregistered as expected.
>
> Signed-off-by: Ido Schimmel
> ---
> tools/testing/selftests/net/Makefile | 1 +
> tools/testing/selftests/net/fib_tests.sh | 146
> ++
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> By default, IPv6 deletes nexthops from a multipath route when the
> nexthop device is put administratively down. This differs from IPv4
> where the nexthops are kept, but marked with the RTNH_F_DEAD flag. A
> multipath route is flushed when all of its nextho
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> The next patch is going to allow dead routes to remain in the FIB tree
> in certain situations.
>
> When this happens we need to be sure to bump the sernum of the nodes
> where these are stored so that potential copies cached in sockets are
> invalidated.
>
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> We are going to allow dead routes to stay in the FIB tree (e.g., when
> they are part of a multipath route, directly connected route with no
> carrier) and revive them when their nexthop device gains carrier or when
> it is put administratively up.
>
> This
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> As explained in previous patch, fib6_ifdown() needs to consider the
> state of all the sibling routes when a multipath route is traversed.
>
> This is done by evaluating all the siblings when the first sibling in a
> multipath route is traversed. If the mul
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> When routes that are a part of a multipath route are evaluated by
> fib6_ifdown() in response to NETDEV_DOWN and NETDEV_UNREGISTER events
> the state of their sibling routes is not considered.
>
> This will change in subsequent patches in order to align IPv
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> Up until now the RTNH_F_DEAD flag was only reported in route dump when
> the 'ignore_routes_with_linkdown' sysctl was set. This is expected as
> dead routes were flushed otherwise.
>
> The reliance on this sysctl is going to be removed, so we need to report
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> Currently, dead routes are only present in the routing tables in case
> the 'ignore_routes_with_linkdown' sysctl is set. Otherwise, they are
> flushed.
>
> Subsequent patches are going to remove the reliance on this sysctl and
> make IPv6 more consistent wi
Hi,
here I provide lsusb from my affected hardware (technotrend s2-4600).
http://ix.io/DLY
With this hardware I had errors when recording with tvheadend. Livetv was ok,
only channel switching made some problems sometimes. Please see attached
tvheadend service logs.
I also provide dmesg (libree
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> Similar to previous patch, there is no need to check for the carrier of
> the nexthop device when dumping the route and we can instead check for
> the presence of the RTNH_F_LINKDOWN flag.
>
> Signed-off-by: Ido Schimmel
> ---
> net/ipv6/route.c | 2 +-
>
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> Now that the RTNH_F_LINKDOWN flag is set in nexthops, we can avoid the
> need to dereference the nexthop device and check its carrier and instead
> check for the presence of the flag.
>
> Signed-off-by: Ido Schimmel
> ---
> net/ipv6/route.c | 7 +++
>
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> It is valid to install routes with a nexthop device that does not have a
> carrier, so we need to make sure they're marked accordingly.
>
> As explained in the previous patch, host and anycast routes are never
> marked with the 'linkdown' flag.
>
> Note th
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> Similar to IPv4, when the carrier of a netdev changes we should toggle
> the 'linkdown' flag on all the nexthops using it as their nexthop
> device.
>
> This will later allow us to test for the presence of this flag during
> route lookup and dump.
>
> Up u
Just realized I messed up the justification about sr_has_hmac. The
branch will be taken, but its execution will not complete since the
TLV's len and type fields aren't copied, hence seg6_get_tlv_hmac will
fail, and the HMAC will not be computed.
2018-01-07 17:12 GMT+00:00 Mathieu Xhonneux :
> Func
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> To make IPv6 more in line with IPv4 we need to be able to respond
> differently to different netdev events. For example, when a netdev is
> unregistered all the routes using it as their nexthop device should be
> flushed, whereas when the netdev's carrier ch
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> Previous patch marked nexthops with the 'dead' and 'linkdown' flags.
> Clear these flags when the netdev comes back up.
>
> Signed-off-by: Ido Schimmel
> ---
> include/net/ip6_route.h | 1 +
> net/ipv6/addrconf.c | 3 +++
> net/ipv6/route.c|
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> When a netdev is put administratively down or unregistered all the
> nexthops using it as their nexthop device should be marked with the
> 'dead' and 'linkdown' flags.
>
> Currently, when a route is dumped its nexthop device is tested and the
> flags are se
On 1/7/18 3:45 AM, Ido Schimmel wrote:
> By the time fib6_net_exit() is executed all the netdevs in the namespace
> have been either unregistered or pushed back to the default namespace.
> That is because pernet subsys operations are always ordered before
> pernet device operations and therefore in
>> Is the function "seq_puts" a bit more efficient for the desired output
>> of a single string in comparison to calling the function "seq_printf"
>> for this purpose?
>
> Will you please be so kind and tell us?
How do you think about to get the run time characteristics for these
sequence output
On Sun, 7 Jan 2018 00:40:03 +0100
Pablo Neira Ayuso wrote:
> Hi Ahmed,
>
> On Fri, Dec 29, 2017 at 12:07:52PM +0100, Ahmed Abdelsalam wrote:
> > It allows matching packets based on Segment Routing Header
> > (SRH) information.
> > The implementation considers revision 7 of the SRH draft.
> > htt
Function ipv6_push_rthdr4 allows to add an IPv6 Segment Routing Header
to a socket through setsockopt, but the current implementation doesn't
copy possible TLVs at the end of the SRH (i.e., the following branch
if (sr_has_hmac(sr_phdr)) will never be taken as no HMAC TLV is copied).
This commit ad
On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote:
> > > It seems that the original patch were designed to solve some IRQ issues
> > > with network cards with causes data losses on high traffic. However,
> > > it is also causing bad effects on sustained high bandwidth demands
> > > required by DVB c
On Sun, 7 Jan 2018 09:19:17 +0100
SF Markus Elfring wrote:
> >> Two strings should be quickly put into a sequence by two function calls.
> >> Thus use the function "seq_puts" instead of "seq_printf".
> >>
> >> This issue was detected by using the Coccinelle software.
> >
> > Can you please exp
From: Subash Abhinov Kasiviswanathan
Date: Sat, 06 Jan 2018 19:19:00 -0700
> I still dont see the v3 submission in patchwork if I query it.
Please resubmit then.
From: Colin Ian King
Use the ARRAY_SIZE macro on various arrays to determine
size of the arrays. Improvement suggested by coccinelle.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/intel/ixgbevf/vf.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a
On 18-01-07 09:28 AM, Jamal Hadi Salim wrote:
On 18-01-07 08:46 AM, Jiri Pirko wrote:
Sun, Jan 07, 2018 at 02:11:19PM CET, j...@mojatatu.com wrote:
On 18-01-06 03:43 PM, Jiri Pirko wrote:
@@ -886,8 +887,13 @@ static int tcf_fill_node(struct net *net,
struct sk_buff *skb,
tcm->tcm_fami
From: Jamal Hadi Salim
Fixes: 249284ff5a44 ("tc: jsonify filter core")
Signed-off-by: Jamal Hadi Salim
---
tc/tc_filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tc/tc_filter.c b/tc/tc_filter.c
index 545cc3a..546311a 100644
--- a/tc/tc_filter.c
+++ b/tc/tc_filter.c
@
This fixes fou on big-endian systems.
Signed-off-by: Filip Moc
---
ip/ipfou.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ip/ipfou.c b/ip/ipfou.c
index febc2c8c..1f392ade 100644
--- a/ip/ipfou.c
+++ b/ip/ipfou.c
@@ -52,7 +52,7 @@ static int fou_parse_opt(int argc, cha
On 18-01-07 08:46 AM, Jiri Pirko wrote:
Sun, Jan 07, 2018 at 02:11:19PM CET, j...@mojatatu.com wrote:
On 18-01-06 03:43 PM, Jiri Pirko wrote:
@@ -886,8 +887,13 @@ static int tcf_fill_node(struct net *net, struct sk_buff
*skb,
tcm->tcm_family = AF_UNSPEC;
tcm->tcm__pad1 = 0;
> > 2. It is very very complicated to answer a question like "is
> > sequence x safe on all of vendor's microprocessors" even for the vendor
>
> so far "is sequence x safe" was viewed by cpu vendors as
> "is sequence x going to stop speculative execution".
Incorrect. Modern processors are very
Sun, Jan 07, 2018 at 02:11:19PM CET, j...@mojatatu.com wrote:
>On 18-01-06 03:43 PM, Jiri Pirko wrote:
>
>
>>
>> > @@ -886,8 +887,13 @@ static int tcf_fill_node(struct net *net, struct
>> > sk_buff *skb,
>> >tcm->tcm_family = AF_UNSPEC;
>> >tcm->tcm__pad1 = 0;
>> >tcm->tcm__pad2 = 0;
On 18-01-06 03:43 PM, Jiri Pirko wrote:
@@ -886,8 +887,13 @@ static int tcf_fill_node(struct net *net, struct sk_buff
*skb,
tcm->tcm_family = AF_UNSPEC;
tcm->tcm__pad1 = 0;
tcm->tcm__pad2 = 0;
- tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
- tcm->tcm_parent =
Em Sat, 6 Jan 2018 16:44:20 -0500 (EST)
Alan Stern escreveu:
> On Sat, 6 Jan 2018, Mauro Carvalho Chehab wrote:
>
> > Hi Josef,
> >
> > Em Sat, 6 Jan 2018 16:04:16 +0100
> > "Josef Griebichler" escreveu:
> >
> > > Hi,
> > >
> > > the causing commit has been identified.
> > > After revertin
Now that the RTNH_F_LINKDOWN flag is set in nexthops, we can avoid the
need to dereference the nexthop device and check its carrier and instead
check for the presence of the flag.
Signed-off-by: Ido Schimmel
---
net/ipv6/route.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff
When a netdev is put administratively down or unregistered all the
nexthops using it as their nexthop device should be marked with the
'dead' and 'linkdown' flags.
Currently, when a route is dumped its nexthop device is tested and the
flags are set accordingly. A similar check is performed during
Previous patch marked nexthops with the 'dead' and 'linkdown' flags.
Clear these flags when the netdev comes back up.
Signed-off-by: Ido Schimmel
---
include/net/ip6_route.h | 1 +
net/ipv6/addrconf.c | 3 +++
net/ipv6/route.c| 29 +
3 files changed, 33
Similar to IPv4, when the carrier of a netdev changes we should toggle
the 'linkdown' flag on all the nexthops using it as their nexthop
device.
This will later allow us to test for the presence of this flag during
route lookup and dump.
Up until commit 4832c30d5458 ("net: ipv6: put host and anyc
To make IPv6 more in line with IPv4 we need to be able to respond
differently to different netdev events. For example, when a netdev is
unregistered all the routes using it as their nexthop device should be
flushed, whereas when the netdev's carrier changes only the 'linkdown'
flag should be toggle
The next patch is going to allow dead routes to remain in the FIB tree
in certain situations.
When this happens we need to be sure to bump the sernum of the nodes
where these are stored so that potential copies cached in sockets are
invalidated.
The function that performs this update assumes the
We are going to allow dead routes to stay in the FIB tree (e.g., when
they are part of a multipath route, directly connected route with no
carrier) and revive them when their nexthop device gains carrier or when
it is put administratively up.
This is equivalent to the addition of the route to the
1 - 100 of 124 matches
Mail list logo
