This is one fix for problems with hot add of network device
on Windows Server.
Stephen Hemminger (1):
hv_netvsc: fix deadlock on hotplug
drivers/net/hyperv/hyperv_net.h | 1 +
drivers/net/hyperv/netvsc_drv.c | 8 +--
drivers/net/hyperv/rndis_filter.c | 106 ++---
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
On Wed, 2017-09-06 at 11:08 +0200, Thomas Meyer wrote:
> On Tue, Sep 05, 2017 at 02:22:05PM -0700, David Miller wrote:
> > nothing prevented you from CC:'ing the maintainer,
> > Jeff Kirscher.
[]
> That's the other condition in my script. I only send to the role
> "maintainer" from the output of ge
On Wed, 6 Sep 2017 13:59:27 +
David Laight wrote:
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: 04 September 2017 19:25
> > On Mon, 4 Sep 2017 17:00:15 +0200
> > Phil Sutter wrote:
> >
> > > On Mon, Sep 04, 2017 at 02:49:20PM +, David Laight 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
xdp_redirect_map sample in SKB-mode '-S', this resulted in trying
sending on ifindex 0 which
Hi Arnd,
It's probably a bug fix that unveils the link errors.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
master
head: 66bed8465a808400eb14562510e26c8818082cb8
commit: 2c08ab3f2504bc7ba816ce6fde051b8bd5f028e4 [491/511] soc: ti/knav_dma:
include dmaengine header
On Wed, 6 Sep 2017 02:47:03 +0200
Andrew Lunn wrote:
> > The third and last issue will be explained in a followup email.
>
> Hi DSA hackers
>
> So there is the third issue. It affects just DSA, but it possible
> affects all DSA drivers.
>
> This patchset broken broadcast with the Marvell dri
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. The existing
> SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific mult
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_raced statistics
counter did not count this event correctly.
This commit removes a small race in determining the
Begin forwarded message:
Date: Wed, 06 Sep 2017 10:18:33 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 196839] New: use_time of IPsec policy is updated even when
receiving error packets.
https://bugzilla.kernel.org/show_bug.cgi?id=196839
Hi Andrew,
Andrew Lunn writes:
> Add code to handle switchdev host mdb add/del. As with normal mdb
> add/del, send a notification to the switch layer.
>
> Signed-off-by: Andrew Lunn
> ---
> net/dsa/dsa_priv.h | 7 +++
> net/dsa/port.c | 26 ++
> net/dsa/slave.c
On Wed, Sep 6, 2017 at 11:26 AM, 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
> xdp_redirect_map sam
Hi Johannes and all,
> > In a way this feature seems mis-designed - you never have 802.1Q tags
> > over the air, but you're inserting them on RX and stripping them on
> > TX, probably in order to make bridging to ethernet easier and not
> > have to have 802.1Q acceleration on the ethernet port, o
i confirm this patch fixes the issue for me as well
Am 06.09.2017 um 17:04 schrieb Matteo Croce:
On Wed, Sep 6, 2017 at 2:58 PM, Johannes Berg wrote:
On Wed, 2017-09-06 at 13:57 +0200, Matteo Croce wrote:
I have an hung task on vanilla 4.13 kernel which I haven't on 4.12.
The problem is pres
Andrew,
> What i found is that the Marvell chips don't flood broadcast frames
> between bridged ports. What appears to happen is there is a fdb miss,
> so it gets forwarded to the CPU port for the host to deal with. The
> software bridge when floods it out all ports of the bridge.
Is this IGMP sno
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:
The original motivation for this change originated from Marc Gonzalez
i
On Tue, Sep 5, 2017 at 5:47 PM, Andrew Lunn wrote:
>> The third and last issue will be explained in a followup email.
>
> Hi DSA hackers
>
> So there is the third issue. It affects just DSA, but it possible
> affects all DSA drivers.
>
> This patchset broken broadcast with the Marvell drivers. It
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_raced statistics
counter did not count this event correctly.
This comm
On Wed, 6 Sep 2017 11:44:18 -0400
Andy Gospodarek wrote:
> On Wed, Sep 6, 2017 at 11:26 AM, 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
On September 6, 2017 8:54:33 AM PDT, Roopa Prabhu
wrote:
>On Tue, Sep 5, 2017 at 5:47 PM, Andrew Lunn wrote:
>>> The third and last issue will be explained in a followup email.
>>
>> Hi DSA hackers
>>
>> So there is the third issue. It affects just DSA, but it possible
>> affects all DSA drivers
On September 6, 2017 8:08:25 AM PDT, Andrew Lunn wrote:
>> > Use the MAC address of the master interface as the parent ID. This
>is
>> > the same for all switches in a cluster, and should be unique if
>there
>> > are multiple clusters.
>>
>> That is not correct. Support for multiple CPU ports is
> 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
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 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
> -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 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
> >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 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
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 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
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
> -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
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
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
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
> 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 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
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
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, 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
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
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, 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 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 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 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 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
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 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
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: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 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 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 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
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
> 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
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:
>
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 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
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 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
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
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
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':
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
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
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
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
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
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
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 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
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
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
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
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
> 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 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) |
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
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
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
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
> 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, 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(-)
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
LOAN AVAILABLE @3 % Rely mohammedanis...@gmail.com
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) |
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 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
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.
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: 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: 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
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
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
101 - 200 of 202 matches
Mail list logo