From: Nisar Sayed
Configure pause time to 0x when tx flow control enabled
Signed-off-by: Nisar Sayed
---
drivers/net/usb/smsc95xx.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 340c134..309b88a
Hi,
> > To clarify, I think what you - conceptually - want is the following
> > topology:
> >
> > +--- eth0.1 --- br.1 --- wlan0.1
> > |
> > eth0 ---+--- eth0.2 --- br.2 --- wlan0.2
> > |
> > +--- eth0.3 --- br.3 --- wlan0.3
[...]
> That's right. In fac
Thu, Sep 07, 2017 at 06:26:07AM CEST, xiyou.wangc...@gmail.com wrote:
>This patch fixes the following madness of tc filter chain:
Could you avoid expressive words like "madness" and such?
Please be technical.
>
>1) tcf_chain_destroy() is called by both tcf_block_put() and
> tcf_chain_put(). t
ttl and tos variables are declared and assigned, but are not used in
iptunnel_xmit() function.
Fixes: cfc7381b3002 ("ip_tunnel: add collect_md mode to IPIP tunnel")
Cc: Alexei Starovoitov
Signed-off-by: Haishuang Yan
---
net/ipv4/ip_tunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
Similar to vxlan/geneve tunnel, if hop_limit is zero, it should fall
back to ip6_dst_hoplimt().
Signed-off-by: Haishuang Yan
---
net/ipv6/ip6_tunnel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 3a0ba2a..10a693a 100644
--- a/net/ipv6/ip
Thu, Sep 07, 2017 at 01:37:59AM CEST, xiyou.wangc...@gmail.com wrote:
>On Wed, Sep 6, 2017 at 1:33 PM, Jiri Pirko wrote:
>> Wed, Sep 06, 2017 at 07:40:02PM CEST, xiyou.wangc...@gmail.com wrote:
>>>On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko wrote:
From: Jiri Pirko
There's a memleak
On the latest Qualcomm platforms remote processors are sending packets with
version 2 of the message header. This series starts off with some fixes and
then refactors the qrtr code to support receiving messages of both version 1
and version 2.
As all remotes are backwards compatible transmitted pa
Rather than manually waking up any context sleeping on the sock to
signal an error we should call sk_error_report(). This has the added
benefit that in-kernel consumers can override this notificatino with
its own callback.
Signed-off-by: Bjorn Andersson
---
net/qrtr/qrtr.c | 2 +-
1 file changed
Defer writing the message header to the skb until its time to enqueue
the packet. As the receive path is reworked to decode the message header
as it's received from the transport and only pass around the payload in
the skb this change means that we do not have to fill out the full
message header ju
The QMUX protocol specification defines structure of the special control
packet messages being sent between handlers of the control port.
Add these to the uapi header, as this structure and the associated types
are shared between the kernel and all userspace handlers of control
messages.
Signed-o
Add the necessary logic for decoding incoming messages of version 2 as
well. Also make sure there's room for the bigger of version 1 and 2
headers in the code allocating skbs for outgoing messages.
Signed-off-by: Bjorn Andersson
---
net/qrtr/qrtr.c | 132 -
The constants are used by both the name server and clients, so clarify
their value and move them to the uapi header.
Signed-off-by: Bjorn Andersson
---
include/uapi/linux/qrtr.h | 3 +++
net/qrtr/qrtr.c | 2 --
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/uapi
Rather than parsing the header of incoming messages throughout the
implementation do it once when we retrieve the message and store the
relevant information in the "cb" member of the sk_buff.
This allows us to, in a later commit, decode version 2 messages into
this same structure.
Signed-off-by:
As the message header generation is deferred the internal functions for
generating control packets can be simplified.
This patch modifies qrtr_alloc_ctrl_packet() to, in addition to the
sk_buff, return a reference to a struct qrtr_ctrl_pkt, which clarifies
and simplifies the helpers to the point t
On Wed, Sep 6, 2017 at 10:40 PM, Luca Coelho wrote:
>
> This patch is not very important (unless you really like blinking lights
> -- maybe I'll change my mind when the holidays approach :P). so it is
> fine if you just want to revert it for now.
>
> In any case, I'll send a patch fixing this prob
On Thu, 2017-09-07 at 05:04 +, Coelho, Luciano wrote:
> On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote:
> > On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
> > wrote:
> > >
> > > This seems to be a problem with backwards-compatibility with FW version
> > > 27. We are now in version
On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote:
> Hi,
>
> This patchset is an RFC on a proposal of how the Traffic Control subsystem can
> be used to offload the configuration of traffic shapers into network devices
> that provide support for them in HW. Our goal here is to s
Hi,
We're happy to announce schedule of the 2nd RDMA mini-summit, which will be
held as part of coming Linux Plumbers Conference 2017.
During the conference, we will have two sessions: main track session and
round table session.
First session will be held on Thursday, September 14, 2017 from 9:3
What I observed is rehashing of set is not happening.
When I add multiple IPs to the ipset manually on ipset v6.32,
rehashing is not happening and my hashsize remains same as 1024
but when I add to ipset 4.5 (pretty old, I know!), rehashing is
happening and my hashsize changes from 1024 to 1536 t
[ 21.219604] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 21.433091] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[ 21.495849] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 22.404040] [ cut here ]
[ 22.404267] WARNING: CPU: 2 PID: 1379 at net/netfilt
On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote:
> On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
> wrote:
> >
> > This seems to be a problem with backwards-compatibility with FW version
> > 27. We are now in version 31[1] and upgrading will probably fix that.
>
> I can confirm that fw
On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
wrote:
>
> This seems to be a problem with backwards-compatibility with FW version
> 27. We are now in version 31[1] and upgrading will probably fix that.
I can confirm that fw version 31 works.
> But obviously the driver should not fail miserably
I understand that without reproducible scenarios, its hard to debug ...
But the point is, this issue is fully random and of very low frequency.
For the setup, it is CentOS 7.3 upgraded to kernel 4.4.
Whenever a system comes up on the network, he provides his credentials
and after successful authe
From: Kleber Sacilotto de Souza
Date: Wed, 6 Sep 2017 11:08:06 +0200
> The net device is already stored in the 'net' variable, so no need to call
> dev_net() again.
>
> Signed-off-by: Kleber Sacilotto de Souza
Applied, thanks.
This patch fixes the following madness of tc filter chain:
1) tcf_chain_destroy() is called by both tcf_block_put() and
tcf_chain_put(). tcf_chain_put() is correctly refcnt'ed and paired
with tcf_chain_get(), but tcf_block_put() is not, it should be paired
with tcf_block_get() which mean
gen estimator has been rewritten in commit 1c0d32fde5bd
("net_sched: gen_estimator: complete rewrite of rate estimators"),
the caller is no longer needed to wait for a grace period.
So this patch gets rid of it.
This also completely closes a race condition between action free
path and filter chain
From: Xin Long
Date: Wed, 6 Sep 2017 11:53:29 +0800
> Now there is no lock protecting nlk ngroups/groups' accessing in
> netlink bind and getname. It's safe from nlk groups' setting in
> netlink_release, but not from netlink_realloc_groups called by
> netlink_setsockopt.
>
> netlink_lock_table
From: Xin Long
Date: Wed, 6 Sep 2017 11:47:12 +0800
> ChunYu found a netlink use-after-free issue by syzkaller:
>
> [28448.842981] BUG: KASAN: use-after-free in __nla_put+0x37/0x40 at addr
> 8807185e2378
> [28448.969918] Call Trace:
> [...]
> [28449.117207] __nla_put+0x37/0x40
> [28449.13
From: Baruch Siach
Date: Sun, 3 Sep 2017 17:32:16 +0300
> The generic PHY 'phys' property sometime appears in the same node with
> the Ethernet PHY 'phy' or 'phy-handle' properties. Add a warning in
> phy-bindings.txt to reduce confusion.
>
> Signed-off-by: Baruch Siach
Applied.
On Wed, 2017-09-06 at 16:27 -0700, Linus Torvalds wrote:
> This pull request completely breaks Intel wireless for me.
>
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
>
> That remains a very standard Intel machine with absolutely zero odd
> things going on.
>
> The fi
Different namespace application might require different maximal number
of TCP sockets independently of the host.
Signed-off-by: Haishuang Yan
---
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 5 +++--
net/ipv4/sysctl_net_ipv4.c | 14 +++---
net/ipv4/tcp.c |
On 09/06/2017 05:10 PM, David Daney wrote:
> On 09/06/2017 04:14 PM, Florian Fainelli wrote:
>> On 09/06/2017 03:51 PM, David Daney wrote:
> [...]
>>>
>>> Consider instead the case of a Marvell phy with no interrupts connected
>>> on a v4.9.43 kernel, single CPU:
>>>
>>>
>>>0) |
LOAN AVAILABLE @3 % Rely mohammedanis...@gmail.com
On Wed, 2017-09-06 at 10:11 +0200, Stefano Brivio wrote:
> Caller needs to acquire the lock. Called functions will not.
>
> Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM
> update")
> Signed-off-by: Stefano Brivio
> ---
> drivers/net/ethernet/intel/i40e/i40e_nvm.c | 2 +-
> 1
On Wed, 2017-09-06 at 10:11 +0200, Stefano Brivio wrote:
> Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM
> update")
> Signed-off-by: Stefano Brivio
> ---
> drivers/net/ethernet/intel/i40e/i40e_nvm.c | 20 +++-
> 1 file changed, 7 insertions(+), 13 deletions(-)
> At the very least we should probably move the skb->offload_fwd_mark
> setting down into the individual taggers since they should be in a
> better position to set it or not based on the switch device they are
> driving, this should address, on a per-switch basis whether 2) or 3)
> applies to a giv
On Wed, Sep 06, 2017 at 11:44:47PM +, woojung@microchip.com wrote:
> > That being said, I have a feeling that the Marvell switches behave a
> > tiny bit differently than others in that they do not flood broadcast by
> > default in a given L2 domain.
> Florian,
>
> Because some DSA switches
From: Sainath Grandhi
Abstracting out common routines for link operations in veth implementation
for use by vethtap interfaces
Signed-off-by: Sainath Grandhi
---
drivers/net/veth.c | 47 +--
include/linux/if_veth.h | 9 +
2 files change
From: Sainath Grandhi
This patch adds a tap character device driver that is based on the
veth network interface, called vethtap. This patchset allows vethtap device
to be created ONLY as a peer interface to a veth network interface. It can
be created in the following way,
ip link add veth1 type v
From: Sainath Grandhi
Adding rtnl_nla_parse_ifla_info as an exported symbol in rtnetlink.c helps
other modules to parse IFLA_LINKINFO attribute
Signed-off-by: Sainath Grandhi
---
include/net/rtnetlink.h | 3 +++
net/core/rtnetlink.c| 8
2 files changed, 11 insertions(+)
diff --gi
From: Sainath Grandhi
This patchset adds a tap device driver for veth virtual network interface.
With this implementation, tap character interface can be added only to the
peer veth interface. Adding tap interface to veth is for usecases that forwards
packets between host and VMs. This eliminate
On 09/06/2017 04:14 PM, Florian Fainelli wrote:
On 09/06/2017 03:51 PM, David Daney wrote:
[...]
Consider instead the case of a Marvell phy with no interrupts connected
on a v4.9.43 kernel, single CPU:
0) | phy_disconnect() {
0) |
> That being said, I have a feeling that the Marvell switches behave a
> tiny bit differently than others in that they do not flood broadcast by
> default in a given L2 domain.
Florian,
Because some DSA switches from Marvell & Microchip can do IGMP snooping,
can we propose switch layer another fl
On Wed, Sep 6, 2017 at 1:33 PM, Jiri Pirko wrote:
> Wed, Sep 06, 2017 at 07:40:02PM CEST, xiyou.wangc...@gmail.com wrote:
>>On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko wrote:
>>> From: Jiri Pirko
>>>
>>> There's a memleak happening for chain 0. The thing is, chain 0 needs to
>>> be always present
On Wed, Sep 6, 2017 at 4:27 PM, Linus Torvalds
wrote:
>
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
>
> iwlwifi :3a:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm
And when I said "iwlwifi-8000C-28.ucode" I obvi
From: Linus Torvalds
Date: Wed, 6 Sep 2017 16:27:15 -0700
> This pull request completely breaks Intel wireless for me.
>
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
>
> That remains a very standard Intel machine with absolutely zero odd
> things going on.
>
> The
This pull request completely breaks Intel wireless for me.
This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
That remains a very standard Intel machine with absolutely zero odd
things going on.
The firmware is iwlwifi-8000C-28.ucode from
iwl7260-firmware-25.30.13.0-75.fc26
On 09/06/2017 03:51 PM, David Daney wrote:
> On 09/06/2017 01:49 PM, David Daney wrote:
>> On 09/06/2017 11:59 AM, Florian Fainelli wrote:
>>> On 09/06/2017 11:00 AM, David Daney wrote:
On 08/31/2017 11:29 AM, Florian Fainelli wrote:
> On 08/31/2017 11:12 AM, Mason wrote:
>> On 31/08/2
Commit cbf5ecb30560 ("net: bonding: Fix transmit load balancing in
balance-alb mode") tried to fix transmit dynamic load balancing in
balance-alb mode, which wasn't working after commit 8b426dc54cf4
("bonding: remove hardcoded value").
It turned out that my previous patch only fixed the case when
Reinis Rozitis reported that tlb_dynamic_lb was still 0 in balance-alb
mode even when using linux-4.12.10 kernels, which includes this patch.
It turned out that my previous patch only fixed the case when
balance-alb mode was specified as bonding module parameter, and not when
balance-alb mode was
On 09/06/2017 01:49 PM, David Daney wrote:
On 09/06/2017 11:59 AM, Florian Fainelli wrote:
On 09/06/2017 11:00 AM, David Daney wrote:
On 08/31/2017 11:29 AM, Florian Fainelli wrote:
On 08/31/2017 11:12 AM, Mason wrote:
On 31/08/2017 19:53, Florian Fainelli wrote:
On 08/31/2017 10:49 AM, Maso
On Mon, Sep 4, 2017 at 11:42 PM, Sekhar Nori wrote:
> Hi Adam,
>
> On Wednesday 30 August 2017 11:08 AM, Sekhar Nori wrote:
>>> I wonder if U-Boot isn't pushing something to Linux because it doesn't
>>> appear to be running some of the da850 specific code even when I run
>>> linux-next. Can you t
When a virtual device is added dynamically (via host console), then
the vmbus sends an offer message for the primary channel. The processing
of this message for networking causes the network device to then
initialize the sub channels.
The problem is that setting up the sub channels needs to wait u
When a virtual device is added dynamically (via host console), then
the vmbus sends an offer message for the primary channel. The processing
of this message for networking causes the network device to then
initialize the sub channels.
The problem is that setting up the sub channels needs to wait u
One serious deadlock, and one minor optimization.
Stephen Hemminger (2):
hv_netvsc: fix deadlock on hotplug
hv_netvsc: avoid unnecessary wakeups on subchannel creation
drivers/net/hyperv/hyperv_net.h | 3 +
drivers/net/hyperv/netvsc.c | 3 +
drivers/net/hyperv/netvsc_drv.c | 1
Only need to wakeup the initiator after all sub-channels
are opened.
Signed-off-by: Stephen Hemminger
---
drivers/net/hyperv/rndis_filter.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 731bc7c
On 09/06/2017 11:59 AM, Florian Fainelli wrote:
On 09/06/2017 11:00 AM, David Daney wrote:
On 08/31/2017 11:29 AM, Florian Fainelli wrote:
On 08/31/2017 11:12 AM, Mason wrote:
On 31/08/2017 19:53, Florian Fainelli wrote:
On 08/31/2017 10:49 AM, Mason wrote:
On 31/08/2017 18:57, Florian Faine
On Wed, Sep 6, 2017 at 10:22 PM, Vishwanath Pai wrote:
> On 09/06/2017 03:57 PM, Arnd Bergmann wrote:
>> 64-bit division is expensive on 32-bit architectures, and
>> requires a special function call to avoid a link error like:
>>
>> net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common':
Wed, Sep 06, 2017 at 07:40:02PM CEST, xiyou.wangc...@gmail.com wrote:
>On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> There's a memleak happening for chain 0. The thing is, chain 0 needs to
>> be always present, not created on demand. Therefore tcf_block_get upon
>> c
The debug and error printk functions in ipvs uses wrongly the %pF instead of
the %pS printk format specifier for printing symbols for the address returned
by _builtin_return_address(0). Fix it for the ia64, ppc64 and parisc64
architectures.
Signed-off-by: Helge Deller
Cc: Wensong Zhang
Cc: netde
On 09/06/2017 03:57 PM, Arnd Bergmann wrote:
> 64-bit division is expensive on 32-bit architectures, and
> requires a special function call to avoid a link error like:
>
> net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common':
> xt_hashlimit.c:(.text+0x1328): undefined reference to `__ae
64-bit division is expensive on 32-bit architectures, and
requires a special function call to avoid a link error like:
net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common':
xt_hashlimit.c:(.text+0x1328): undefined reference to `__aeabi_uldivmod'
In the case of hashlimit_mt_common, we d
On Wed, Sep 6, 2017 at 5:27 PM, kbuild test robot
wrote:
> Hi Arnd,
>
> It's probably a bug fix that unveils the link errors.
Correct.
>net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common':
>>> xt_hashlimit.c:(.text+0x1f68): undefined reference to `__aeabi_uldivmod'
I actually wr
On 09/06/2017 09:42 AM, Andrew Lunn wrote:
>>> On the switch asics we work with, the driver has information if the
>>> packet was
>>> forwarded in hardware. This is per packet reason code telling why the
>>> CPU is seeing the packet.
>>> The driver can use this information to reset skb->offload_fwd
On 09/06/2017 08:51 AM, Mason wrote:
> On 31/08/2017 21:18, Florian Fainelli wrote:
>
>> On 08/31/2017 12:09 PM, Mason wrote:
>>
>>> On 31/08/2017 19:03, Florian Fainelli wrote:
>>>
On 08/31/2017 05:29 AM, Marc Gonzalez wrote:
> On 31/08/2017 02:49, Florian Fainelli wrote:
>
> From: Jorgen S. Hansen [mailto:jhan...@vmware.com]
> Sent: Wednesday, September 6, 2017 7:11 AM
>> ...
> > I'm currently working on NFS over AF_VSOCK and sock_diag support (for
> > ss(8) and netstat-like tools).
> >
> > Multi-transport support is lower priority for me at the moment. I'm
> > happ
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git
master
head: d17be7f7503bf9492198a242779a68af93fd92de
commit: 96c03618031bae5e9068b16f9e437b79f98f6482 [4/5] Merge remote-tracking
branch 'mac80211-next/master'
config: xtensa-allyesconfig (attached as .confi
On 09/06/2017 07:55 AM, Mason wrote:
> On 31/08/2017 21:18, Florian Fainelli wrote:
>
>> On 08/31/2017 12:09 PM, Mason wrote:
>>
>>> 1) nb8800_link_reconfigure() calls phy_print_status()
>>> which prints the "Link down" and "Link up" messages
>>> to the console. With the patch reverted, nothing is
On 06/09/2017 20:00, David Daney wrote:
> On 08/31/2017 11:29 AM, Florian Fainelli wrote:
>> On 08/31/2017 11:12 AM, Mason wrote:
>>> On 31/08/2017 19:53, Florian Fainelli wrote:
On 08/31/2017 10:49 AM, Mason wrote:
> On 31/08/2017 18:57, Florian Fainelli wrote:
>> And the race is betw
On Wed, Sep 6, 2017 at 10:43 AM, Alexander Duyck
wrote:
> On Wed, Sep 6, 2017 at 9:17 AM, Tom Herbert wrote:
>> On Tue, Sep 5, 2017 at 8:06 PM, Alexander Duyck
>> wrote:
>>> On Tue, Sep 5, 2017 at 2:13 PM, Tom Herbert wrote:
> The situation with encapsulation is even more complicated:
>
On 09/06/2017 11:00 AM, David Daney wrote:
> On 08/31/2017 11:29 AM, Florian Fainelli wrote:
>> On 08/31/2017 11:12 AM, Mason wrote:
>>> On 31/08/2017 19:53, Florian Fainelli wrote:
On 08/31/2017 10:49 AM, Mason wrote:
> On 31/08/2017 18:57, Florian Fainelli wrote:
>> And the race is b
On 09/06/2017 08:42 PM, John Fastabend wrote:
On 09/06/2017 11:18 AM, Jesper Dangaard Brouer wrote:
On Wed, 06 Sep 2017 18:24:07 +0200
Daniel Borkmann wrote:
On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote:
Using bpf_redirect_map is allowed for generic XDP programs, but the
appropriate m
On 09/06/2017 11:18 AM, Jesper Dangaard Brouer wrote:
> On Wed, 06 Sep 2017 18:24:07 +0200
> Daniel Borkmann wrote:
>
>> On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote:
>>> Using bpf_redirect_map is allowed for generic XDP programs, but the
>>> appropriate map lookup was never performed in
Hi Andrew,
Andrew Lunn writes:
>> I don't understand why SWITCHDEV_OBJ_ID_PORT_MDB cannot be used. Isn't
>> setting the obj->orig_dev to the bridge device itself enough to
>> distinguish br0 from a switch port?
>
> I did consider this. But conceptually, it seems wrong.
> SWITCHDEV_OBJ_ID_PORT_MD
On Wed, 06 Sep 2017 18:24:07 +0200
Daniel Borkmann wrote:
> On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote:
> > Using bpf_redirect_map is allowed for generic XDP programs, but the
> > appropriate map lookup was never performed in xdp_do_generic_redirect().
> >
> > Instead the map-index is d
On Tue, 2017-09-05 at 15:35 -0700, Petar Penkov wrote:
> Add a TUN/TAP receive mode that exercises the napi_gro_frags()
> interface. This mode is available only in TAP mode, as the interface
> expects packets with Ethernet headers.
>
Hi Petar, thanks a lot for this work.
I must confess I have t
On 08/31/2017 11:29 AM, Florian Fainelli wrote:
On 08/31/2017 11:12 AM, Mason wrote:
On 31/08/2017 19:53, Florian Fainelli wrote:
On 08/31/2017 10:49 AM, Mason wrote:
On 31/08/2017 18:57, Florian Fainelli wrote:
And the race is between phy_detach() setting phydev->attached_dev = NULL
and phy_
On 09/06/2017 07:33 AM, Mason wrote:
On 31/08/2017 20:29, Florian Fainelli wrote:
On 08/31/2017 11:12 AM, Mason wrote:
On 31/08/2017 19:53, Florian Fainelli wrote:
On 08/31/2017 10:49 AM, Mason wrote:
On 31/08/2017 18:57, Florian Fainelli wrote:
And the race is between phy_detach() setting ph
On Wed, Sep 6, 2017 at 9:17 AM, Tom Herbert wrote:
> On Tue, Sep 5, 2017 at 8:06 PM, Alexander Duyck
> wrote:
>> On Tue, Sep 5, 2017 at 2:13 PM, Tom Herbert wrote:
The situation with encapsulation is even more complicated:
We are basically only interested in the UDP/vxlan/Ethernet
On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko wrote:
> From: Jiri Pirko
>
> There's a memleak happening for chain 0. The thing is, chain 0 needs to
> be always present, not created on demand. Therefore tcf_block_get upon
> creation of block calls the tcf_chain_create function directly. The
> chain i
On Wed, 6 Sep 2017 13:14:19 +0200, Jiri Pirko wrote:
> From: Jiri Pirko
>
> There's a memleak happening for chain 0. The thing is, chain 0 needs to
> be always present, not created on demand. Therefore tcf_block_get upon
> creation of block calls the tcf_chain_create function directly. The
> cha
Thanks, will make separate patch.
> Hi Nisar
>
> > + else if ((ee->magic == LAN78XX_EEPROM_MAGIC) &&
> > +(ee->offset >= 0 && ee->offset < MAX_EEPROM_SIZE) &&
> > +(ee->len > 0 && (ee->offset + ee->len) <=
> MAX_EEPROM_SIZE))
> > + ret = lan78xx_write_raw_eepro
Thanks Andrew, will try to change as suggested.
> On Wed, Sep 06, 2017 at 10:51:44AM +, nisar.sa...@microchip.com
> wrote:
> > From: Nisar Sayed
> >
> > Add fixed_phy device support for LAN7801 device
> >
> > When LAN7801 device connected to PHY Device which does not have
> > MDIO/MDC access,
Thanks Andrew inputs.
> On Wed, Sep 06, 2017 at 10:51:31AM +, nisar.sa...@microchip.com
> wrote:
> > From: Nisar Sayed
> >
> > Fix for crash associated with System suspend
> >
> > Since ndo_stop removes phydev which makes phydev NULL.
> > Whenever system suspend is initiated or after "ifconf
On Wed, Sep 6, 2017 at 12:38 AM, Jiri Pirko wrote:
> Wed, Sep 06, 2017 at 07:03:10AM CEST, xiyou.wangc...@gmail.com wrote:
>>tcf_chain_destroy() is called by tcf_block_put() and tcf_chain_put().
>>tcf_chain_put() is refcn'ed and paired with tcf_chain_get(),
>>but tcf_block_put() is not, it should
> The patches are under review internally and will need to be updated
> and approved by Woojung before formal submission. Problem is
> although KSZ8795 and KSZ8895 drivers are new code and will be
> submitted as RFC, they depend on the change of KSZ9477 driver
> currently in the kernel, which requ
On 09/06/2017 06:24 PM, Daniel Borkmann wrote:
[...]
Otherwise it looks good, but note that it also doesn't really
resolve the issue you mention wrt stale map pointers by the
way. This would need a different way to clear out the pointers
from redirect_info, I'm thinking when we have devmap disman
On Wed, Sep 06, 2017 at 11:25:26AM -0400, Vivien Didelot wrote:
> Hi Andrew, Nikolay,
>
> Andrew Lunn writes:
>
> > Then starts the work passing down to the hardware that the host has
> > joined/left a group. The existing switchdev mdb object cannot be used,
> > since the semantics are different
As David Laight correctly pointed out, the first version of strlcpy()
modified dst buffer behind the string copied into it. Fix this by
writing NUL to the byte immediately following src string instead of to
the last byte in dst. Doing so also allows to reduce overhead by using
memcpy().
Improve st
> -Original Message-
> From: Maxim Uvarov [mailto:muva...@gmail.com]
> Sent: Wednesday, September 06, 2017 2:15 AM
> To: Tristram Ha - C24268
> Cc: Pavel Machek; Woojung Huh - C21699; Nathan Conrad; Vivien Didelot;
> Florian Fainelli; netdev; linux-ker...@vger.kernel.org; Andrew Lunn
> Subj
On 9/6/2017 9:35 AM, Håkon Bugge wrote:
In rds_send_xmit() there is logic to batch the sends. However, if
another thread has acquired the lock and has incremented the send_gen,
it is considered a race and we yield. The code incrementing the
s_send_lock_queue_raced statistics counter did not count
> >On the switch asics we work with, the driver has information if the
> >packet was
> >forwarded in hardware. This is per packet reason code telling why the
> >CPU is seeing the packet.
> >The driver can use this information to reset skb->offload_fwd_mark to
> >allow software forward.
> I am not
In rds_send_xmit() there is logic to batch the sends. However, if
another thread has acquired the lock and has incremented the send_gen,
it is considered a race and we yield. The code incrementing the
s_send_lock_queue_raced statistics counter did not count this event
correctly.
This commit counts
On Wed, 6 Sep 2017 16:23:45 +
Haiyang Zhang wrote:
> > -Original Message-
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Wednesday, September 6, 2017 11:19 AM
> > To: KY Srinivasan ; Haiyang Zhang
> > ; Stephen Hemminger
> > Cc: de...@linuxdriverproject.org
> >Yes, you are correct. I will change this.
>
> A switch cluster should be tied to the same dsa_switch_tree though,
> can we use dst->tree as an unique identifier?
Yes, that is what Vivien was suggesting.
Andrew
On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote:
Using bpf_redirect_map is allowed for generic XDP programs, but the
appropriate map lookup was never performed in xdp_do_generic_redirect().
Instead the map-index is directly used as the ifindex. For the
Good point, but ...
[...]
net/c
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Wednesday, September 6, 2017 11:19 AM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> Cc: de...@linuxdriverproject.org; netdev@vger.kernel.org
> Subject: [PATCH net-next 1/1] hv_netvsc:
On 9/6/2017 9:12 AM, Håkon Bugge wrote:
[...]
Hi Santosh,
Yes, I agree with accuracy of s_send_lock_queue_raced. But the main point is
that the existing code counts some partial share of when it is _not_ raced.
So, in the critical path, my patch adds one test_bit(), which hits the local
On Tue, Sep 5, 2017 at 8:06 PM, Alexander Duyck
wrote:
> On Tue, Sep 5, 2017 at 2:13 PM, Tom Herbert wrote:
>>> The situation with encapsulation is even more complicated:
>>>
>>> We are basically only interested in the UDP/vxlan/Ethernet/IP/UDP
>>> constellation. If we do the fragmentation inside
> On 6 Sep 2017, at 17:58, Santosh Shilimkar
> wrote:
>
> On 9/6/2017 8:29 AM, Håkon Bugge wrote:
>> In rds_send_xmit() there is logic to batch the sends. However, if
>> another thread has acquired the lock, it is considered a race and we
>> yield. The code incrementing the s_send_lock_queue_ra
1 - 100 of 202 matches
Mail list logo
