On Thu, Apr 5, 2018 at 11:46 PM, Andrew Lunn wrote:
>> > Hi Ran
>> >
>> > The Marvell driver makes each port act like a normal Linux network
>> > interface. So if you want to enable a port, do
>> >
>> > ip link set lan0 up
>> >
>> > Want to add an ip address to a port
>> >
>> > ip addr add 10.42.4
syzbot has found reproducer for the following crash on upstream commit
3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 (Sat Mar 31 01:52:36 2018 +)
kernel.h: Retain constant expression output for max()/min()
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=777bf170a89e7b326405
So fa
handle_tx will delay rx for tens or even hundreds of milliseconds when tx busy
polling udp packets with small length(e.g. 1byte udp payload), because setting
VHOST_NET_WEIGHT takes into account only sent-bytes but no single packet length.
Ping-Latencies shown below were tested between two Virtual
On Thu, 5 Apr 2018 14:47:16 -0700
Jakub Kicinski wrote:
> On Thu, 5 Apr 2018 22:51:33 +0200, Jesper Dangaard Brouer wrote:
> > > What about nfp in terms of XDP
> > > offload capabilities, should they be included as well or is probing to
> > > load
> > > the program and see if it loads/JITs as we
On Thu, Apr 05, 2018 at 08:50:49AM -0700, Florian Fainelli wrote:
> On 04/05/2018 03:47 AM, Jose Abreu wrote:
> > Background: Synopsys Ethernet IP's have a certain number of
> > features which can be reconfigured at runtime. Giving you two
> > examples: One of the most recent one is the safety feat
(current kernel: vanilla 4.14.29)
I've been running into troubles recently where a sockets "fills up" (as
in, select() will no longer return it in its outfd / attempting to write
to it after setting it to NONBLOCK will return -EWOULDBLOCK) and it
doesn't seem to ever "unfill" until the tcp connexi
Hello,
I encountered a strange behaviour of some (non-linux) TCP stack which
I believe is incorrect but support engineers from the company producing
it claim is OK.
Assume a client (sender, Linux 4.4 kernel) sends a stream of MSS sized
segments but segments 2, 4 and 6 do not reach the server (rec
On 04/05/2018 10:51 PM, Jesper Dangaard Brouer wrote:
> On Thu, 5 Apr 2018 12:37:19 +0200
> Daniel Borkmann wrote:
>
>> On 04/04/2018 02:28 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
>>> Hi Suricata people,
>>>
>>> When Eric Leblond (and I helped) integrated XDP in Suricata, we ran
>>> int
> Il 19 marzo 2018 alle 11.07 Jamal Hadi Salim ha scritto:
>
> On 18-03-15 08:48 PM, Cong Wang wrote:
>
> > On Wed, Mar 14, 2018 at 1:10 AM, Marco Berizzi wrote:
> >
> > > > Il 9 marzo 2018 alle 0.14 Cong Wang ha
> > > > scritto:
> >
> > It has been reported here:
> > https://bugzilla.kerne
David Miller writes:
> From: Andrew Lunn
> Date: Thu, 5 Apr 2018 22:40:49 +0200
>
>> Or could it still contain whatever state the last boot of Linux, or
>> maybe the bootloader, left the PHY in?
>
> Right, this is my concern as well.
I don't think that should happen.
With config_init() being ca
eBPF helper functions can be called from within eBPF programs to perform
a variety of tasks that would be otherwise hard or impossible to do with
eBPF itself. There is a growing number of such helper functions in the
kernel, but documentation is scarce. The main user space header file
does contain
From: Vadim Lomovtsev
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put single null check on kmalloc
return value in
No 'g' to hairpin.
Signed-off-by: Guillaume Nault
---
bridge/link.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bridge/link.c b/bridge/link.c
index 579d57e7..8d89aca2 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -312,7 +312,7 @@ static int brlink_modify(int argc, cha
Hi Vadim,
On 04/06/2018 06:14 AM, Vadim Lomovtsev wrote:
From: Vadim Lomovtsev
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation a
Hi Gustavo,
On Fri, Apr 06, 2018 at 06:36:28AM -0500, Gustavo A. R. Silva wrote:
> Hi Vadim,
>
> On 04/06/2018 06:14 AM, Vadim Lomovtsev wrote:
> > From: Vadim Lomovtsev
> >
> > It is too expensive to pass u64 values via linked list, instead
> > allocate array for them by overall number of mac
On 04/06/2018 06:43 AM, Vadim Lomovtsev wrote:
Hi Gustavo,
On Fri, Apr 06, 2018 at 06:36:28AM -0500, Gustavo A. R. Silva wrote:
Hi Vadim,
On 04/06/2018 06:14 AM, Vadim Lomovtsev wrote:
From: Vadim Lomovtsev
It is too expensive to pass u64 values via linked list, instead
allocate array for
On 06/04/18 12:14, Vadim Lomovtsev wrote:
From: Vadim Lomovtsev
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put
On Fri, Apr 06, 2018 at 06:47:26AM -0500, Gustavo A. R. Silva wrote:
>
>
> On 04/06/2018 06:43 AM, Vadim Lomovtsev wrote:
> > Hi Gustavo,
> >
> > On Fri, Apr 06, 2018 at 06:36:28AM -0500, Gustavo A. R. Silva wrote:
> > > Hi Vadim,
> > >
> > > On 04/06/2018 06:14 AM, Vadim Lomovtsev wrote:
> > >
On 04/06/2018 03:05 AM, Michal Kubecek wrote:
> Hello,
>
> I encountered a strange behaviour of some (non-linux) TCP stack which
> I believe is incorrect but support engineers from the company producing
> it claim is OK.
>
> Assume a client (sender, Linux 4.4 kernel) sends a stream of MSS sized
Hi Robin,
On Fri, Apr 06, 2018 at 12:48:40PM +0100, Robin Murphy wrote:
> On 06/04/18 12:14, Vadim Lomovtsev wrote:
> > From: Vadim Lomovtsev
> >
> > It is too expensive to pass u64 values via linked list, instead
> > allocate array for them by overall number of mac addresses from netdev.
> >
>
From: Esben Haabendal
This introduces a simpler and generic method for for finding (and mapping)
the TBIPA register.
Instead of relying of complicated logic for finding the TBIPA register
address based on the MDIO or MII register block base
address, which even in some cases relies on undocumente
From: Esben Haabendal
The current (mildly evil) fsl_pq_mdio code uses an undocumented shadow of
the TBIPA register on LS1021A, which happens to be read-only.
Changing TBI PHY address therefore does not work on LS1021A.
The real (and documented) address of the TBIPA registere lies in the eTSEC
bl
Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@intel.com wrote:
>This patch enables virtio_net to switch over to a VF datapath when a VF
>netdev is present with the same MAC address. It allows live migration
>of a VM with a direct attached VF without the need to setup a bond/team
>between
Thu, Apr 05, 2018 at 11:08:21PM CEST, sridhar.samudr...@intel.com wrote:
>This provides a generic interface for paravirtual drivers to listen
>for netdev register/unregister/link change events from pci ethernet
>devices with the same MAC and takeover their datapath. The notifier and
>event handling
On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote:
> Christian Brauner writes:
>
> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote:
> >> On 05.04.2018 17:07, Christian Brauner wrote:
> >> > On Thu, Apr 05, 2018 at 04:01:03PM +0300, Kirill Tkhai wrote:
> >> >> On 04.
Switch stmmac_ops to generic Hardware Interface Helpers instead of using
hard-coded callbacks. This makes the code more readable and more
flexible.
No functional change.
Signed-off-by: Jose Abreu
Cc: David S. Miller
Cc: Joao Pinto
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
drivers/net/
Switch stmmac_hwtimestamp to generic Hardware Interface Helpers instead
of using hard-coded callbacks. This makes the code more readable and
more flexible.
No functional change.
Signed-off-by: Jose Abreu
Cc: David S. Miller
Cc: Joao Pinto
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
driv
Switch stmmac_mode_ops to generic Hardware Interface Helpers instead of
using hard-coded callbacks. This makes the code more readable and more
flexible.
No functional change.
Signed-off-by: Jose Abreu
Cc: David S. Miller
Cc: Joao Pinto
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
drivers
Switch stmmac_dma_ops to generic Hardware Interface Helpers instead of
using hard-coded callbacks. This makes the code more readable and more
flexible.
No functional change.
Signed-off-by: Jose Abreu
Cc: David S. Miller
Cc: Joao Pinto
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
drivers/
Switch stmmac_desc_ops to generic Hardware Interface Helpers instead of
using hard-coded callbacks. This makes the code more readable and more
flexible.
No functional change.
Signed-off-by: Jose Abreu
Cc: David S. Miller
Cc: Joao Pinto
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
drivers
This a starting point for a cleanup and re-organization of stmmac.
In this series we stop using hard-coded callbacks along the code and use
instead helpers which are defined in a single place ("hwif.h").
This brings several advantages:
1) Less typing :)
2) Guaranteed function poin
Hi Florian,
On 05-04-2018 16:50, Florian Fainelli wrote:
>
> On 04/05/2018 03:47 AM, Jose Abreu wrote:
>> Hi All,
>>
>> I would like to know your opinion regarding adding support for
>> driver private ioctl's in ethtool.
>>
>> Background: Synopsys Ethernet IP's have a certain number of
>> features
Hi Michal,
On 06-04-2018 10:07, Michal Kubecek wrote:
> On Thu, Apr 05, 2018 at 08:50:49AM -0700, Florian Fainelli wrote:
>> On 04/05/2018 03:47 AM, Jose Abreu wrote:
>>> Background: Synopsys Ethernet IP's have a certain number of
>>> features which can be reconfigured at runtime. Giving you two
>
From: Vadim Lomovtsev
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put single null check on kmalloc
return value in
From: Esben Haabendal
Signed-off-by: Esben Haabendal
---
drivers/net/phy/dp83640.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 654f42d00092..48403170096a 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/n
On Thu, Apr 5, 2018 at 7:19 PM, Davide Caratti wrote:
> when tcf_bpf_init_from_ops() fails (e.g. because of program having invalid
> number of instructions), tcf_bpf_cfg_cleanup() calls bpf_prog_put(NULL) or
> bpf_prog_destroy(NULL). Unless CONFIG_BPF_SYSCALL is unset, this causes
> the following
On Fri, Apr 06, 2018 at 04:05:40PM +0200, Esben Haabendal wrote:
> From: Esben Haabendal
>
> Signed-off-by: Esben Haabendal
> ---
> drivers/net/phy/dp83640.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
> inde
On Thu, Apr 05, 2018 at 03:20:14PM -0700, Florian Fainelli wrote:
> On 04/04/2018 07:17 PM, Andrew Lunn wrote:
> > On Wed, Apr 04, 2018 at 05:49:10PM -0700, Florian Fainelli wrote:
> >> On 04/04/2018 04:56 PM, Andrew Lunn wrote:
> >>> The Marvell switches under some conditions will pass a frame to
On Thu, Apr 05, 2018 at 03:35:06PM -0700, Florian Fainelli wrote:
> On 04/05/2018 01:20 PM, David Miller wrote:
> > From: Murali Karicheri
> > Date: Thu, 5 Apr 2018 16:14:49 -0400
> >
> >> Is there a standard way to implement and configure storm prevention
> >> in a Linux network device?
> >
> >
On Fri, Apr 06, 2018 at 11:42:04AM +0530, Raghuram Chary J wrote:
> Adding Fixed PHY support to the lan78xx driver.
Hi Raghuram
What do you expect is connected to the MAC if there is no PHY?
Andrew
> +static int lan78xx_get_regs_len(struct net_device *netdev)
> +{
> + return (sizeof(lan78xx_regs) + PHY_REG_SIZE);
If there is no PHY attached, you probably should not include
PHY_REG_SIZE here.
Andrew
On Fri, Apr 06, 2018 at 11:42:02AM +0530, Raghuram Chary J wrote:
> The patch is to configure DSP registers of PHY device
> to handle Gbe-EEE failures with >40m cable length.
>
> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000
> Ethernet device driver")
> Signed-off-by: Ra
Christian Brauner writes:
> On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote:
>> >> On 05.04.2018 17:07, Christian Brauner wrote:
>> >> > On Thu, Apr 05, 2018 at 04:01:03PM +0300,
On Fri, Apr 06, 2018 at 02:51:15PM +0100, Jose Abreu wrote:
> Hi Florian,
>
> On 05-04-2018 16:50, Florian Fainelli wrote:
> >
> > On 04/05/2018 03:47 AM, Jose Abreu wrote:
> >> Hi All,
> >>
> >> I would like to know your opinion regarding adding support for
> >> driver private ioctl's in ethtool.
Hi Andrew,
On 06-04-2018 15:47, Andrew Lunn wrote:
> On Fri, Apr 06, 2018 at 02:51:15PM +0100, Jose Abreu wrote:
>> Hi Florian,
>>
>> On 05-04-2018 16:50, Florian Fainelli wrote:
>>> On 04/05/2018 03:47 AM, Jose Abreu wrote:
Hi All,
I would like to know your opinion regarding adding
On Fri, Apr 06, 2018 at 05:01:29AM -0700, Eric Dumazet wrote:
>
>
> On 04/06/2018 03:05 AM, Michal Kubecek wrote:
> > Hello,
> >
> > I encountered a strange behaviour of some (non-linux) TCP stack which
> > I believe is incorrect but support engineers from the company producing
> > it claim is O
From: Vadim Lomovtsev
Date: Fri, 6 Apr 2018 04:14:25 -0700
> diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
> b/drivers/net/ethernet/cavium/thunder/nic.h
> index 5fc46c5a4f36..448d1fafc827 100644
> --- a/drivers/net/ethernet/cavium/thunder/nic.h
> +++ b/drivers/net/ethernet/cavium/thund
On Thu, Apr 05, 2018 at 06:37:23PM -0700, Alexei Starovoitov wrote:
> On Thu, Apr 05, 2018 at 05:16:36PM +0200, Jiri Olsa wrote:
> > hi,
> > eBPF programs loaded for kprobes are allowed to read kernel
> > internal structures. We check the provided kernel version
> > to ensure that the program is lo
From: Jose Abreu
Date: Fri, 6 Apr 2018 14:08:14 +0100
> This a starting point for a cleanup and re-organization of stmmac.
>
> In this series we stop using hard-coded callbacks along the code and use
> instead helpers which are defined in a single place ("hwif.h").
>
> This brings several adva
From: Andrew Lunn
Date: Fri, 6 Apr 2018 16:14:10 +0200
> On Fri, Apr 06, 2018 at 04:05:40PM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> Signed-off-by: Esben Haabendal
>> ---
>> drivers/net/phy/dp83640.c | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff -
On Fri, Apr 06, 2018 at 11:06:03AM -0400, David Miller wrote:
> From: Vadim Lomovtsev
> Date: Fri, 6 Apr 2018 04:14:25 -0700
>
> > diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
> > b/drivers/net/ethernet/cavium/thunder/nic.h
> > index 5fc46c5a4f36..448d1fafc827 100644
> > --- a/drivers
Self-NACK here, because of https://lkml.org/lkml/2018/4/6/724
Sorry for noise.
Vadim
On Fri, Apr 06, 2018 at 07:04:43AM -0700, Vadim Lomovtsev wrote:
> From: Vadim Lomovtsev
>
> It is too expensive to pass u64 values via linked list, instead
> allocate array for them by overall number of mac a
From: Andrew Lunn
Date: Fri, 6 Apr 2018 16:43:42 +0200
> On Fri, Apr 06, 2018 at 11:42:02AM +0530, Raghuram Chary J wrote:
>> The patch is to configure DSP registers of PHY device
>> to handle Gbe-EEE failures with >40m cable length.
>>
>> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3
From: Anirudh Venkataramanan
1) Return correct size from ice_get_regs_len.
2) Fix incorrect use of ARRAY_SIZE in ice_get_regs.
Fixes: fcea6f3da546 (ice: Add stats and ethtool support)
Signed-off-by: Anirudh Venkataramanan
Tested-by: Tony Brelinski
Signed-off-by: Jeff Kirsher
---
drivers/net/
From: Wei Yongjun
Fix to return error code ICE_ERR_NO_MEMORY from the alloc error
handling case instead of 0, as done elsewhere in this function.
Fixes: dc49c7723676 ("ice: Get MAC/PHY/link info and scheduler topology")
Signed-off-by: Wei Yongjun
Acked-by: Anirudh Venkataramanan
Tested-by: Ton
This series contains a couple of fixes for the new ice driver.
Wei Yongjun fixes the return error code for error case during init.
Anirudh fixes the incorrect use of ARRAY_SIZE() in the ice ethtool code
and fixed "for" loop calculations.
The following are changes since commit 3239534a79ee6f20cff
From: Jeff Kirsher
Date: Fri, 6 Apr 2018 08:36:28 -0700
> This series contains a couple of fixes for the new ice driver.
>
> Wei Yongjun fixes the return error code for error case during init.
>
> Anirudh fixes the incorrect use of ARRAY_SIZE() in the ice ethtool code
> and fixed "for" loop ca
On Fri, Apr 06, 2018 at 09:45:41AM -0500, Eric W. Biederman wrote:
> Christian Brauner writes:
>
> > On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote:
> >> Christian Brauner writes:
> >>
> >> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote:
> >> >> On 05.04.2018
Cc Neal and Yuchung if they missed this thread.
On 04/06/2018 08:03 AM, Michal Kubecek wrote:
> On Fri, Apr 06, 2018 at 05:01:29AM -0700, Eric Dumazet wrote:
>>
>>
>> On 04/06/2018 03:05 AM, Michal Kubecek wrote:
>>> Hello
>>>
>>> I encountered a strange behaviour of some (non-linux) TCP stack whi
Christian Brauner writes:
>> At a practical level there should be no receivers. Plus performance
>> issues. At least my memory is that any unprivileged user on the system
>> is allowed to listen to those events.
>
> Any unprivileged user is allowed to listen to uevents if they have
> net_broadc
On Fri, Apr 06, 2018 at 09:59:59AM +0900, Masahiro Yamada wrote:
> 2018-04-06 3:59 GMT+09:00 Jiri Olsa :
> > On Fri, Apr 06, 2018 at 12:50:00AM +0900, Masahiro Yamada wrote:
> >> 2018-04-06 0:16 GMT+09:00 Jiri Olsa :
> >> > There's no need to pass LD* arguments to link-vmlinux.sh,
> >> > because th
David Miller writes:
> From: Andrew Lunn
> Date: Fri, 6 Apr 2018 16:14:10 +0200
>
>> On Fri, Apr 06, 2018 at 04:05:40PM +0200, Esben Haabendal wrote:
>>> From: Esben Haabendal
>>>
>>> Signed-off-by: Esben Haabendal
>>> ---
>>> drivers/net/phy/dp83640.c | 17 +
>>> 1 file chan
From: Esben Haabendal
Signed-off-by: Esben Haabendal
---
drivers/net/phy/dp83640.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 654f42d00092..a6c87793d899 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/
Andrew Lunn writes:
>> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index
>> 0e0978d8a0eb..f03a510f1247 100644
>> --- a/drivers/net/phy/marvell.c
>> +++ b/drivers/net/phy/marvell.c
>> @@ -457,6 +457,21 @@ static int marvell_of_reg_init(struct phy_device
>> *phydev) } #endif
By storing subprog boundaries as a subprogno mark on each insn, rather than
a start (and implicit end) for each subprog, the code handling subprogs can
in various places be made simpler, more explicit, and more efficient (i.e.
better asymptotic complexity). This also lays the ground for possibl
Error messages for some bad programs have changed.
Also added a test ("calls: interleaved functions") to ensure that subprogs
are required to be contiguous.
It wasn't entirely clear to me what "calls: wrong recursive calls" was
meant to test for, since all of the JMP|CALL insns are unreachable.
By storing a subprogno in each insn's aux data, we avoid the need to keep
the list of subprog starts sorted or bsearch() it in find_subprog().
Also, get rid of the weird one-based indexing of subprog numbers.
Signed-off-by: Edward Cree
---
include/linux/bpf_verifier.h | 3 +-
kernel/bpf/verif
Per-subprog info is stored in env->subprog_info, an array of structs,
rather than multiple arrays with a common index.
Signed-off-by: Edward Cree
---
include/linux/bpf_verifier.h | 9 +---
kernel/bpf/verifier.c| 49 +++-
2 files changed, 32 i
By giving each register its own liveness chain, we elide the skip_callee()
logic. Instead, each register's parent is the state it inherits from;
both check_func_call() and prepare_func_exit() automatically connect
reg states to the correct chain since when they copy the reg state across
(r1-r5
Instead of recursively walking every possible call chain,
check_max_stack_depth() now uses an explicit call graph (recorded in
subprog_info.callees) which it topologically sorts, allowing it to find
for each subprog the maximum stack depth of all call chains, and then
use that depth in calculat
On Fri, Apr 06, 2018 at 07:08:44PM +0200, Esben Haabendal wrote:
> From: Esben Haabendal
Hi Esben
It it good to have some form of commit message. Something like:
The datasheet specifies a 3uS pause after performing a software
reset. The default implementation of genphy_soft_reset() does not
pr
Forwarding to netdev mailing list, it might be a real problem
Ugh. Glaring backtrace screenshots.
Begin forwarded message:
Date: Fri, 06 Apr 2018 16:43:46 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 199307] New: kernel panic,call
trace,sched_clo
On Thu, Apr 05, 2018 at 10:40:29PM +0200, Esben Haabendal wrote:
> From: Esben Haabendal
>
> The LED2[2]/INTn pin on Marvell 88E1318S as well as 88E1510/12/14/18 needs
> to be configured to be usable as interrupt not only when WOL is enabled,
> but whenever we rely on interrupts from the PHY.
>
From: Andrew Lunn
Date: Fri, 6 Apr 2018 19:29:28 +0200
> On Thu, Apr 05, 2018 at 10:40:29PM +0200, Esben Haabendal wrote:
>> From: Esben Haabendal
>>
>> The LED2[2]/INTn pin on Marvell 88E1318S as well as 88E1510/12/14/18 needs
>> to be configured to be usable as interrupt not only when WOL is
On 4/2/18 10:29 PM, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> The RDMA devices are operated in RoCE and iWARP modes have net device
> underneath. Present their names in regular output and their net index
> in detailed mode.
>
> [root@nps ~]# rdma link show mlx5_3/1
> 4/1: mlx5_3/1: stat
Hello,
syzbot hit the following crash on upstream commit
38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +)
Merge tag 'armsoc-drivers' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=65a84dde0214
From: Vadim Lomovtsev
It is too expensive to pass u64 values via linked list, instead
allocate array for them by overall number of mac addresses from netdev.
This eventually removes multiple kmalloc() calls, aviod memory
fragmentation and allow to put single null check on kmalloc
return value in
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 1c1008c793fa net: bcmgenet: add main driver file.
The bot has also determined it's probably a bug fixing patch. (score: 49.2621)
The bot has tested the following trees: v4.16, v4.1
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 33c162a980fe ipv6: datagram: Update dst cache of a connected
datagram sk during pmtu update.
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92.
v4.16: Fai
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 967dd82ffc52 net: dsa: b53: Add support for Broadcom RoboSwitch.
The bot has also determined it's probably a bug fixing patch. (score: 8.8847)
The bot has tested the following tree
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 80105befdb4b net: systemport: add Broadcom SYSTEMPORT Ethernet
MAC driver.
The bot has also determined it's probably a bug fixing patch. (score: 50.4075)
The bot has tested the fo
On 4/5/18 11:52 PM, Jiri Pirko wrote:
> Thu, Apr 05, 2018 at 11:06:41PM CEST, d...@cumulusnetworks.com wrote:
>> On 4/5/18 2:10 PM, David Ahern wrote:
>>>
>>> The ASIC here is the kernel tables in a namespace. It does not make
>>> sense to have 2 devlink instances for a single namespace.
>>
>> I pu
(put discussions back on list which got accidentally removed)
On Tue, Apr 3, 2018 at 4:08 PM, Stephen Hemminger
wrote:
> On Tue, 3 Apr 2018 12:04:38 -0700
> Siwei Liu wrote:
>
>> On Tue, Apr 3, 2018 at 10:35 AM, Stephen Hemminger
>> wrote:
>> > On Sun, 1 Apr 2018 05:13:09 -0400
>> > Si-Wei Liu
There is no functionality change in this patch. The common-purpose
perf_event functions are moved from trace_output_user.c to bpf_load.c
so that these function can be reused later.
Signed-off-by: Yonghong Song
---
samples/bpf/bpf_load.c | 104
sample
Currently, stackmap and bpf_get_stackid helper are provided
for bpf program to get the stack trace. This approach has
a limitation though. If two stack traces have the same hash,
only one will get stored in the stackmap table,
so some stack traces are missing from user perspective.
This patch impl
Currently, stackmap and bpf_get_stackid helper are provided
for bpf program to get the stack trace. This approach has
a limitation though. If two stack traces have the same hash,
only one will get stored in the stackmap table,
so some stack traces are missing from user perspective.
This patch impl
The test_stacktrace_map is enhanced to call bpf_get_stack
in the helper to get the stack trace as well.
The stack traces from bpf_get_stack and bpf_get_stackid
are compared to ensure that for the same stack as
represented as the same hash, their ip addresses
must be the same.
Signed-off-by: Yongho
This patch didn't incur functionality change. The function prototype
got changed so that the same function can be reused later.
Signed-off-by: Yonghong Song
---
kernel/bpf/stackmap.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/kernel/bpf/stackmap.c b/kernel/
The test attached a kprobe program to kernel function sys_write.
It tested to get stack for user space, kernel space and user
space with build_id request. It also tested to get user
and kernel stack into the same buffer with back-to-back
bpf_get_stack helper calls.
Whenever the kernel stack is ava
Signed-off-by: Yonghong Song
---
tools/include/uapi/linux/bpf.h| 17 +++--
tools/testing/selftests/bpf/bpf_helpers.h | 2 ++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9d07465..3930
Forwarding a report about what looks like a regression between 4.14 and 4.15.
New ENOSPC issue? I don't even knew where to start guessing where to look.
Help me, Davem-Wan Kenobi, you are my only hope.
(But adding netdev just in case somebody else goes "That's obviously Xyz")
Linu
On 4/6/2018 5:48 AM, Jiri Pirko wrote:
Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@intel.com wrote:
+
+static void virtnet_bypass_set_rx_mode(struct net_device *dev)
+{
+ struct virtnet_bypass_info *vbi = netdev_priv(dev);
+ struct net_device *child_netdev;
+
On 4/6/2018 5:57 AM, Jiri Pirko wrote:
Thu, Apr 05, 2018 at 11:08:21PM CEST, sridhar.samudr...@intel.com wrote:
This provides a generic interface for paravirtual drivers to listen
for netdev register/unregister/link change events from pci ethernet
devices with the same MAC and takeover their dat
The counter that tracks used TX descriptors pending completion
needs to be zeroed as part of a device reset. This change fixes
a bug causing transmit queues to be stopped unnecessarily and in
some cases a transmit queue stall and timeout reset. If the counter
is not reset, the remaining descriptors
This patch series introduces some fixes to the driver reset
routines and a patch that fixes mistakes caught by the kernel
DMA debugger.
The reset fixes include a fix to reset TX queue counters properly
after a reset as well as updates to driver reset error-handling code.
It also provides updates t
Fix some mistakes caught by the DMA debugger. The first change
fixes a unnecessary unmap that should have been removed in an
earlier update. The next hunk fixes another bad unmap by zeroing
the bit checked to determine that an unmap is needed. The final
change fixes some buffers that are unmapped
From: Nathan Fontenot
When resetting the ibmvnic driver after a partition migration occurs
there is no requirement to do a reset of the main CRQ. The current
driver code does the required re-enable of the main CRQ, then does
a reset of the main CRQ later.
What we should be doing for a driver res
There is a failover case for a non-redundant pseries VNIC
configuration that was not being handled properly. The current
implementation assumes that the driver will always have a redandant
device to communicate with following a failover notification. There
are cases, however, when a non-redundant c
In some cases, if the driver is waiting for a reset following
a device parameter change, failure to schedule a reset can result
in a hang since a completion signal is never sent.
If the device configuration is being altered by a tool such
as ethtool or ifconfig, it could cause the console to hang
On Fri, Apr 6, 2018 at 2:56 PM, Linus Torvalds
wrote:
> Forwarding a report about what looks like a regression between 4.14 and 4.15.
>
> New ENOSPC issue? I don't even knew where to start guessing where to look.
>
> Help me, Davem-Wan Kenobi, you are my only hope.
>
> (But adding netdev just in c
1 - 100 of 116 matches
Mail list logo
