On Thu, Dec 15, 2016 at 09:24:20PM -0700, Jason Gunthorpe wrote:
>>+struct __hfi_vesw_info {
>>+ u16 fabric_id;
>>+ u16 vesw_id;
>>+
>>+ u8 rsvd0[6];
>>+ u16 def_port_mask;
>>+
>>+ u8 rsvd1[2];
>>+ u16 pkey;
>>+
>>+ u8 rsvd2[4];
>>+ u32 u
From: Peter Meerwald-Stadler Sent: Friday, December 16,
2016 9:24 PM
>To: netdev@vger.kernel.org
>Cc: Peter Meerwald-Stadler ; Andy Duan
>; triv...@kernel.org
>Subject: [PATCH 3/3] net: fec: Fix typo in error msg and comment
>
>Signed-off-by: Peter Meerwald-Stadler
>Cc: Fugang Duan
>Cc: triv...
On Thu, Dec 15, 2016 at 3:00 PM, Nogah Frankel wrote:
> +/* Note: if one xstat name in subset of another, it should be before it in
> this
> + * list.
> + * Name length must be under 64 chars.
> + */
nit "in subset" --> "is subset" ?
From: Gao Feng
There are some duplicated codes in ipvlan_add_addr6/4 and
ipvlan_del_addr6/4. Now define two common functions ipvlan_add_addr
and ipvlan_del_addr to decrease the duplicated codes.
It could be helful to maintain the codes.
Signed-off-by: Gao Feng
---
It is sent again because the
From: Gao Feng
There are three functions which would invoke the ipvlan_count_rx. They
are ipvlan_process_multicast, ipvlan_rcv_frame, and ipvlan_nf_input.
The former two functions already use the ipvlan directly before
ipvlan_count_rx, and ipvlan_nf_input gets the ipvlan from
ipvl_addr->master, i
On Thu, Dec 15, 2016 at 12:31:40PM +0800, Xin Long wrote:
> Now when adding an ipt_CLUSTERIP rule, it only checks duplicate config in
> clusterip_config_find_get(). But after that, there may be still another
> thread to insert a config with the same ip, then it leaves proc_create_data
> to do dupli
> -Original Message-
> From: Rami Rosen [mailto:roszenr...@gmail.com]
> Sent: Friday, December 16, 2016 5:21 PM
> To: Nogah Frankel
> Cc: Stephen Hemminger ; netdev@vger.kernel.org;
> ro...@cumulusnetworks.com; Jiri Pirko ; Elad Raz
> ; Yotam Gigi ; Ido Schimmel
> ; Or Gerlitz
> Subject:
Driver code never touches "rstn" signal in atomic context, so there's
no need to implicitly put such restriction on it by using gpio_set_value
to manipulate it. Replace gpio_set_value to gpio_set_value_cansleep to
fix that.
As a an example of where such restriction might be inconvenient,
consider
On 18.12.2016 21:14, Paul E. McKenney wrote:
On Sun, Dec 18, 2016 at 07:57:42PM +, Valo, Kalle wrote:
Tobias Klausmann writes:
A patch for this is already floating on the ML for a while now latest:
(ath9k: do not return early to fix rcu unlocking)
It's here:
https://patchwork.kernel.
On Wed, Dec 14, 2016 at 8:39 AM, Bartosz Folta wrote:
> There are hardware PCI implementations of Cadence GEM network
> controller. This patch will allow to use such hardware with reuse of
> existing Platform Driver.
Since it's already applied, perhaps you would consider addressing my
below comme
Add new sock flag to allow sockets to confirm neighbour.
When same struct dst_entry can be used for many different
neighbours we can not use it for pending confirmations.
As not all call paths lock the socket use full word for
the flag.
Add sk_dst_confirm as replacement for dst_confirm when
called
Add new transport flag to allow sockets to confirm neighbour.
When same struct dst_entry can be used for many different
neighbours we can not use it for pending confirmations.
The flag is propagated from transport to every packet.
It is reset when cached dst is reset.
Reported-by: YueHaibing
Fixe
When same struct dst_entry can be used for many different
neighbours we can not use it for pending confirmations.
Use the new sk_dst_confirm() helper to propagate the
indication from received packets to sock_confirm_neigh().
Reported-by: YueHaibing
Fixes: 5110effee8fd ("net: Do delayed neigh conf
This patchset addresses the problem of neighbour
confirmation where received replies from one nexthop
can cause confirmation of different nexthop when using
the same dst. Thanks to YueHaibing
for tracking the dst->pending_confirm problem.
Sockets can obtain cached output route. Su
When same struct dst_entry can be used for many different
neighbours we can not use it for pending confirmations.
The datagram protocols can use MSG_CONFIRM to confirm the
neighbour. When used with MSG_PROBE we do not reach the
code where neighbour is confirmed, so we have to do the
same slow look
Add confirm_neigh method to dst_ops and use it from IPv4 and IPv6
to lookup and confirm the neighbour. Its usage via the new helper
dst_confirm_neigh() should be restricted to MSG_PROBE users for
performance reasons.
Signed-off-by: Julian Anastasov
---
include/net/arp.h | 16 +++
When same struct dst_entry can be used for many different
neighbours we can not use it for pending confirmations.
As last step, we can remove the pending_confirm flag.
Reported-by: YueHaibing
Fixes: 5110effee8fd ("net: Do delayed neigh confirmation.")
Fixes: f2bb4bedf35d ("ipv4: Cache output rout
Add new skbuff flag to allow protocols to confirm neighbour.
When same struct dst_entry can be used for many different
neighbours we can not use it for pending confirmations.
Add sock_confirm_neigh() helper to confirm the neighbour and
use it for IPv4, IPv6 and VRF before dst_neigh_output.
Signed
Fix up memory barriers in stmmac driver. They are meant to protect
against DMA engine, so smp_ variants are certainly wrong, and dma_
variants are preferable.
Signed-off-by: Pavel Machek
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
b/drivers/net/ethernet/stmicro/stmmac/d
Hello.
On 12/12/2016 07:09 PM, Niklas Söderlund wrote:
Add generic functionality to support Wake-on-Lan using MagicPacket which
are supported by at least a few versions of sh_eth. Only add
functionality for WoL, no specific sh_eth version are marked to support
Versions.
WoL yet.
WoL is
Hi!
> > For the same reason it's broken if it races with the transmit path: it
> > can release driver resources while the transmit path uses these.
> >
> > Btw the points below may not matter/hurt much for a proof a concept
> > but they would need to be addressed as well:
> > 1) unchecked (and av
On Sun, Dec 18, 2016 at 07:57:42PM +, Valo, Kalle wrote:
> Tobias Klausmann writes:
>
> > A patch for this is already floating on the ML for a while now latest:
> > (ath9k: do not return early to fix rcu unlocking)
>
> It's here:
>
> https://patchwork.kernel.org/patch/9472709/
Feel free to
On 18-12-2016 13:09, Pali Rohár wrote:
> On Sunday 18 December 2016 12:54:00 Arend Van Spriel wrote:
>> On 18-12-2016 12:04, Pali Rohár wrote:
>>> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
On 16-12-2016 11:40, Pali Rohár wrote:
> On Friday 16 December 2016 08:25:44 Daniel
On 18.12.2016 20:57, Valo, Kalle wrote:
Tobias Klausmann writes:
A patch for this is already floating on the ML for a while now latest:
(ath9k: do not return early to fix rcu unlocking)
It's here:
https://patchwork.kernel.org/patch/9472709/
Good to know!
Hopefully Kalle will include it
Tobias Klausmann writes:
> A patch for this is already floating on the ML for a while now latest:
> (ath9k: do not return early to fix rcu unlocking)
It's here:
https://patchwork.kernel.org/patch/9472709/
> Hopefully Kalle will include it in one of his upcoming pull requests.
Yes, I'll try to
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 actually happens while processing mulitcast packets
but that's a result of unconditionally queueing packets without
en
Hi!
> > - e1efa87241272104d6a12c8b9fcdc4f62634d447
>
> Yep, a sync of the dma descriptors before the hardware gets ownership of the
> tx tail
> idx is missing in the stmmac, too.
I can reproduce failure with 4.4 fairly easily. I tried with dma_
variant of barriers, and it failed, too
[ 1018.41
On Sun, Dec 18, 2016 at 12:31:30PM +0200, Tariq Toukan wrote:
> Hi Martin,
>
>
> On 17/12/2016 12:18 PM, Martin KaFai Lau wrote:
> >Hi All,
> >
> >I have been debugging with XDP_TX and 16 rx-queues.
> >
> >1) When 16 rx-queues is used and an XDP prog is doing XDP_TX,
> >it seems that the packet can
On Sat, Dec 17, 2016 at 8:54 PM, David Miller wrote:
> From: Mahesh Bandewar
> Date: Sat, 17 Dec 2016 18:16:19 -0800
>
>> diff --git a/drivers/net/ipvlan/ipvlan_core.c
>> b/drivers/net/ipvlan/ipvlan_core.c
>> index b4e990743e1d..4294fc1f5564 100644
>> --- a/drivers/net/ipvlan/ipvlan_core.c
>> ++
Signed-off-by: Roman Mashak
---
man/man8/tc.8 | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index 583b72f..f96911a 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -32,7 +32,8 @@ tc \- show / manipulate traffic control settings
\fIDEV\fR
Signed-off-by: Roman Mashak
---
man/man8/tc.8 | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index 8a47a2b..583b72f 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -5,58 +5,58 @@ tc \- show / manipulate tr
Hi!
> > - e1efa87241272104d6a12c8b9fcdc4f62634d447
>
> Yep, a sync of the dma descriptors before the hardware gets ownership of the
> tx tail
> idx is missing in the stmmac, too.
Thanks for the hint. Actually, the driver uses smp_wmb() which is
completely crazy, and probably misses rmb() in cl
Hi,
A patch for this is already floating on the ML for a while now latest:
(ath9k: do not return early to fix rcu unlocking)
Hopefully Kalle will include it in one of his upcoming pull requests.
Greetings,
Tobias
On 18.12.2016 16:59, Paul E. McKenney wrote:
On Sun, Dec 18, 2016 at 02:52:4
Hi,
On 18.12.2016 01:15, Francois Romieu wrote:
> Pavel Machek :
> [...]
>> Won't this up/down the interface, in a way userspace can observe?
>
> It won't up/down the interface as it doesn't exactly mimic what the
> network code does (there's more than rtnl_lock).
>
Right. Userspace wont see l
On Sun, Dec 18, 2016 at 4:49 PM, David Miller wrote:
> From: Martin Blumenstingl
> Date: Sat, 17 Dec 2016 19:21:19 +0100
>
>> Prior to this patch we were using a hardcoded RGMII TX clock delay of
>> 2ns (= 1/4 cycle of the 125MHz RGMII TX clock). This value works for
>> many boards, but unfortuna
On Sun, Dec 18, 2016 at 02:52:48PM +0100, Gabriel C wrote:
> Hello,
>
> while testing kernel 4.9 I run into a weird issue with the ath9k driver.
>
> I can boot the box in console mode and it stay up sometime but is not usable.
Looks to me like someone forgot an rcu_read_unlock() somewhere. Give
From: Martin Blumenstingl
Date: Sat, 17 Dec 2016 19:21:19 +0100
> Prior to this patch we were using a hardcoded RGMII TX clock delay of
> 2ns (= 1/4 cycle of the 125MHz RGMII TX clock). This value works for
> many boards, but unfortunately not for all (due to the way the actual
> circuit is desig
From: "Mintz, Yuval"
Date: Sun, 18 Dec 2016 06:33:50 +
>> From: Colin Ian King
>>
>> A qed_spq_entry entry is allocated by qed_sp_init_request but is not kfree'd
>> if an error occurs, causing a memory leak. Fix this by kfree'ing it and also
>> setting *pp_ent to NULL to be safe.
>>
>> Fou
Hello,
while testing kernel 4.9 I run into a weird issue with the ath9k driver.
I can boot the box in console mode and it stay up sometime but is not usable.
from dmesg :
===
[ INFO: suspicious RCU usage. ]
4.9-fw1 #1 Tainted: G I
-
Hi Florian, Hi Jerome,
On Wed, Nov 30, 2016 at 2:15 AM, Florian Fainelli wrote:
> On 11/29/2016 05:13 PM, David Miller wrote:
>> From: Florian Fainelli
>> Date: Tue, 29 Nov 2016 16:43:20 -0800
>>
>>> On 11/29/2016 04:38 PM, David Miller wrote:
From: Jerome Brunet
Date: Mon, 28 Nov 201
On 12/15/2016 3:53 PM, Simon Horman wrote:
On Thu, Dec 15, 2016 at 02:03:36PM +0100, Simon Horman wrote:
On Tue, Dec 13, 2016 at 10:07:47AM +0200, Hadar Hen Zion wrote:
Enhance tunnel key action parameters by adding destination UDP port.
Signed-off-by: Hadar Hen Zion
Reviewed-by: Roi Dayan
On Sunday 18 December 2016 12:54:00 Arend Van Spriel wrote:
> On 18-12-2016 12:04, Pali Rohár wrote:
> > On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
> >> On 16-12-2016 11:40, Pali Rohár wrote:
> >>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
> On 12/16/2016 03:03
On 18-12-2016 12:04, Pali Rohár wrote:
> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
>> On 16-12-2016 11:40, Pali Rohár wrote:
>>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> For the new API a solution for "fal
On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
> On 16-12-2016 11:40, Pali Rohár wrote:
> > On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
> >> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> >>> For the new API a solution for "fallback mechanisms" should be
> >>> clean th
On 16-12-2016 11:40, Pali Rohár wrote:
> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>>> For the new API a solution for "fallback mechanisms" should be
>>> clean though and I am looking to stay as far as possible from the
>>> existing
Hi Martin,
On 17/12/2016 12:18 PM, Martin KaFai Lau wrote:
Hi All,
I have been debugging with XDP_TX and 16 rx-queues.
1) When 16 rx-queues is used and an XDP prog is doing XDP_TX,
it seems that the packet cannot be XDP_TX out if the pkt
is received from some particular CPUs (/rx-queues).
Do
46 matches
Mail list logo
