Thank you for your time,
We are looking for clients in your country with good business or project that
requires financing to execute.
Do get back to me if you are interested in this or you know anybody who has
good business ideas but lack the necessary capital to fund his projects so we
can
On 09/18/2018 06:32 PM, Alexei Starovoitov wrote:
On Tue, Sep 18, 2018 at 06:53:07AM +0200, Mauricio Vasquez B wrote:
Two types of tests are done:
- test_maps: only userspace api.
- test_progs: userspace api and ebpf helpers.
Signed-off-by: Mauricio Vasquez B
---
kernel/bpf/helpers.c
On 09/18/2018 06:27 PM, Alexei Starovoitov wrote:
On Tue, Sep 18, 2018 at 06:52:51AM +0200, Mauricio Vasquez B wrote:
Implement two new kind of maps that support the peek, push and pop
operations.
A use case for this is to keep track of a pool of elements, like
network ports in a SNAT.
On Tue, Sep 18, 2018 at 03:12:11PM +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> In one of my previous patches in this area I introduced code
> to pass out just the error message to store in the extack, for
> use in NLA_REJECT.
>
> Change this code now to set both the error message and
From: Wei Wang
Date: Tue, 18 Sep 2018 13:44:58 -0700
> From: Wei Wang
>
> The latest fix on the memory leak of fib6_metrics still causes
> use-after-free.
> This patch series first revert the previous fix and propose a new fix
> that is more inline with ipv4 logic and is tested to fix the
>
From: Russell King
Date: Tue, 18 Sep 2018 16:48:53 +0100
> If a network interface is created prior to the SFP socket being
> available, ethtool can request module information. This unfortunately
> leads to an oops:
>
> Unable to handle kernel NULL pointer dereference at virtual address
IPVLAN and IPVTAP are using the same functions and parameters. So we can
just add a new link_util with id ipvtap. Others are the same.
Signed-off-by: Hangbin Liu
---
ip/iplink.c | 4 ++--
ip/iplink_ipvlan.c| 28 ++--
man/man8/ip-link.8.in | 4
3
From: Saeed Mahameed
Date: Mon, 17 Sep 2018 20:49:25 -0700
> Sorry about the previous submission of this series which was mistakenly
> marked for net-next, here I am resending with 'net' mark.
>
> This series provides three fixes to mlx5 core and mlx5e netdevice
> driver.
>
> Please pull and
From: Christian Lamparter
Date: Mon, 17 Sep 2018 17:22:40 +0200
> On the Netgear WNDAP620, the emac ethernet isn't receiving nor
> xmitting any frames from/to the RTL8363SB (identifies itself
> as a RTL8367RB).
>
> This is caused by the emac hardware not knowing the forced link
> parameters for
From: Sabrina Dubroca
Date: Mon, 17 Sep 2018 15:30:06 +0200
> The cleanup function uses "$CMD 2 > /dev/null", which doesn't actually
> send stderr to /dev/null, so when the netns doesn't exist, the error
> message is shown. Use "2> /dev/null" instead, so that those messages
> disappear, as was
On 09/18/2018 06:05 PM, Alexei Starovoitov wrote:
On Tue, Sep 18, 2018 at 06:52:34AM +0200, Mauricio Vasquez B wrote:
In the following patches queue and stack maps (FIFO and LIFO
datastructures) will be implemented. In order to avoid confusion and
a possible name clash rename stackmap.c to
From: Li RongQing
Date: Mon, 17 Sep 2018 18:46:55 +0800
> struct pcpu_vstats and pcpu_lstats have same members and
> usage, and pcpu_lstats is used in many files, so rename
> pcpu_vstats as pcpu_lstats to reduce duplicate definition
>
> Signed-off-by: Zhang Yu
> Signed-off-by: Li RongQing
From: Johannes Berg
Date: Mon, 17 Sep 2018 11:57:29 +0200
> From: Johannes Berg
>
> Commonly, ethernet addresses are just using a policy of
> { .len = ETH_ALEN }
> which leaves userspace free to send more data than it should,
> which may hide bugs.
>
> Introduce NLA_EXACT_LEN which
From: Johannes Berg
Date: Mon, 17 Sep 2018 11:57:28 +0200
> From: Johannes Berg
>
> In some situations some netlink attributes may be used for output
> only (kernel->userspace) or may be reserved for future use. It's
> then helpful to be able to prevent userspace from using them in
> messages
From: Jose Abreu
Date: Mon, 17 Sep 2018 09:22:55 +0100
> The fix for coalesce timer and a fix in tail address setting that impacts
> XGMAC2 operation.
>
> The series is:
> Tested-by: Jerome Brunet
> on a113 s400 board (single queue)
Series applied and queued up for -stable.
From: Vlad Buslov
Date: Mon, 17 Sep 2018 10:17:33 +0300
> +struct Qdisc *qdisc_lookup_rcu(struct net_device *dev, u32 handle)
> +{
> + struct Qdisc *q;
> + struct netdev_queue *nq;
Reverse christmas tree for the local variables, please.
From: Jeff Kirsher
Date: Tue, 18 Sep 2018 15:37:17 -0700
> This series contains changes to i40evf so that it becomes a more
> generic virtual function driver for current and future silicon.
>
> While doing the rename of i40evf to a more generic name of iavf,
> we also put the driver on a severe
> On 09/17/2018 10:26 PM, Li RongQing wrote:
> > if skb->head is vmalloc address, when this skb is delivered, full
> > allocation for this skb is required, if there are many devices, the
> > ---
> > net/netlink/af_netlink.c | 14 --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
On Tue, 18 Sep 2018 10:22:11 -0700, Y Song wrote:
> > +/* The umem is stored both in the _rx struct and the _tx struct as we do
> > + * not know if the device has more tx queues than rx, or the opposite.
> > + * This might also change during run time.
> > + */
> > +static void
The BMCR.RESET bit on Marvell PHYs appears to be acting as a commit
operation, so we try to hit that bit which disrupts the link, only when
an actual register programming required a change.
Determine from marvell_set_polarity()'s return code whether the register value
was changed and if it was,
While consolidating the PHY reset in phy_init_hw() an unconditionaly
BMCR soft-reset I became quite trigger happy with those. This was later
on deactivated for the Generic PHY driver on the premise that a prior
software entity (e.g: bootloader) might have applied workarounds in
commit 0878fff1f42c
Hi all,
This patch series eliminates unnecessary software resets of the PHY.
This should hopefully not break anybody's hardware; but I would
appreciate testing to make sure this is is the case.
Sorry for this long email list, I wanted to make sure I reached out to
all people who made changes to
On Tue, Sep 18, 2018 at 4:25 PM David Ahern wrote:
>
> On 9/18/18 1:45 PM, Wei Wang wrote:
> > From: Wei Wang
> >
> > When dst->_metrics and f6i->fib6_metrics share the same memory, both
> > take reference count on the dst_metrics structure. However, when dst is
> > destroyed, ip6_dst_destroy()
This patch makes macsec interfaces reflect the state of the underlying
interface: if the master interface changes state to up/down, the macsec
interface changes its state accordingly.
This closes a loophole in the macsec interface state logic: the macsec
interface cannot be brought up if the
Hi everyone,
I came across an issue with macsec interfaces where they don't reflect
the master interface state. On one hand you cannot set the macsec
interface link state to up unless the master interface is already up,
but on the other hand, if the master interface goes down while the
macsec
On Tue, Sep 18, 2018 at 1:20 PM Willem de Bruijn
wrote:
>
> From: Willem de Bruijn
>
> If boolean CONFIG_BPF_SYSCALL is enabled, kernel/bpf/syscall.c will
> call flow_dissector functions from net/core/flow_dissector.c.
>
> This causes this build failure if CONFIG_NET is disabled:
>
>
On Tue, Sep 18, 2018 at 06:53:07AM +0200, Mauricio Vasquez B wrote:
> Two types of tests are done:
> - test_maps: only userspace api.
> - test_progs: userspace api and ebpf helpers.
>
> Signed-off-by: Mauricio Vasquez B
> ---
> kernel/bpf/helpers.c |2
>
On Tue, Sep 18, 2018 at 06:52:51AM +0200, Mauricio Vasquez B wrote:
> Implement two new kind of maps that support the peek, push and pop
> operations.
>
> A use case for this is to keep track of a pool of elements, like
> network ports in a SNAT.
>
> Signed-off-by: Mauricio Vasquez B
> ---
>
On 9/18/18 1:45 PM, Wei Wang wrote:
> From: Wei Wang
>
> When dst->_metrics and f6i->fib6_metrics share the same memory, both
> take reference count on the dst_metrics structure. However, when dst is
> destroyed, ip6_dst_destroy() only invokes dst_destroy_metrics_generic()
> which does not take
On 9/18/18 1:44 PM, Wei Wang wrote:
> From: Wei Wang
>
> This reverts commit e70a3aad44cc8b24986687ffc98c4a4f6ecf25ea.
>
> This change causes use-after-free on dst->_metrics.
> Reported-by: John Sperbeck
> Signed-off-by: Wei Wang
> Signed-off-by: Eric Dumazet
> ---
> net/ipv6/route.c
On Tue, Sep 18, 2018 at 06:52:34AM +0200, Mauricio Vasquez B wrote:
> In the following patches queue and stack maps (FIFO and LIFO
> datastructures) will be implemented. In order to avoid confusion and
> a possible name clash rename stackmap.c to stacktracemap.c and
> stack_map_ops to
From: Jesse Brandeburg
Remove a bunch of unused code and reformat a few lines. Also
remove some now un-necessary files.
Signed-off-by: Jesse Brandeburg
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/iavf/i40e_adminq.c | 27 -
From: Jesse Brandeburg
Simply move the i40evf files to the new name, updating the #includes
to track the new names, and updating the Makefile as well.
A future patch will remove the i40e references (after the code
removal patches later in this series).
Signed-off-by: Jesse Brandeburg
From: Jesse Brandeburg
Rename the device ID defines to have IAVF in them
and remove all the unused defines.
Signed-off-by: Jesse Brandeburg
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/iavf/i40e_adminq.c | 22 +-
From: Jesse Brandeburg
Remove the register name references to I40E_VF* and change to
IAVF_VF. Update the descriptor names and defines to the IAVF
name.
Signed-off-by: Jesse Brandeburg
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/iavf/i40e_adminq.c |
From: Jesse Brandeburg
Rename the Intel Ethernet Adaptive Virtual Function driver
(i40evf) to a new name (iavf) that is more consistent with
the ongoing maintenance of the driver as the universal VF driver
for multiple product lines.
This first patch fixes up the directory names and the .ko
From: Jesse Brandeburg
Change another string (i40e_debug)
Signed-off-by: Jesse Brandeburg
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/iavf/i40e_adminq.c | 28 +--
drivers/net/ethernet/intel/iavf/i40e_common.c | 12
From: Jesse Brandeburg
Take care of some renames containing I40E_ADMINQ_DESC.
Signed-off-by: Jesse Brandeburg
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/iavf/i40e_adminq.c | 18 +-
drivers/net/ethernet/intel/iavf/i40e_adminq.h | 4
This series contains changes to i40evf so that it becomes a more
generic virtual function driver for current and future silicon.
While doing the rename of i40evf to a more generic name of iavf,
we also put the driver on a severe diet due to how much of the
code was unneeded or was unused. The
From: Jesse Brandeburg
Fix up the i40e_hw names to new name, including versions
inside other strings.
Signed-off-by: Jesse Brandeburg
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/iavf/i40e_adminq.c | 43 ---
From: Jesse Brandeburg
This finishes the process of renaming the files that
make sense to rename (skipping adminq related files that
talk to i40e), and fixes up the build and the #includes
so that everything builds nicely.
Signed-off-by: Jesse Brandeburg
Tested-by: Andrew Bowers
From: Jesse Brandeburg
This is just a rename of an internal variable i40e_status, but
it was a pretty big change and so deserved it's own patch.
Signed-off-by: Jesse Brandeburg
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/iavf/i40e_adminq.c | 81
From: Jesse Brandeburg
We recently updated all our SPDX identifiers to correctly
indicate our net/ethernet/intel/* drivers were always released
and intended to be released under GPL v2, but the MODULE_LICENSE
declaration was never updated.
Fix the MODULE_LICENSE to be GPL v2, for all our
From: Jesse Brandeburg
Rename the i40e_trace file and fix up all the callers
to the new names inside the iavf_trace.h file.
Signed-off-by: Jesse Brandeburg
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 2 +-
On Tue, Sep 18, 2018 at 2:56 PM Song Liu wrote:
>
>
>
> > On Sep 18, 2018, at 2:46 PM, Eric Dumazet wrote:
> >
> > On Tue, Sep 18, 2018 at 2:41 PM Song Liu wrote:
> >>
> >>
> >>
> >>>
> >> I would submit the patch if Eric prefer not to. :)
> >
> >
> > Hmmm maybe the bug is really in
> On Sep 18, 2018, at 2:46 PM, Eric Dumazet wrote:
>
> On Tue, Sep 18, 2018 at 2:41 PM Song Liu wrote:
>>
>>
>>
>>>
>> I would submit the patch if Eric prefer not to. :)
>
>
> Hmmm maybe the bug is really in ixgbe_netpoll()
>
> This whole ndo_poll_controller() stuff is crazy.
>
On Tue, Sep 18, 2018 at 2:41 PM Song Liu wrote:
>
>
>
> >
> I would submit the patch if Eric prefer not to. :)
Hmmm maybe the bug is really in ixgbe_netpoll()
This whole ndo_poll_controller() stuff is crazy.
All sane implementations should only call napi_schedule()
> On Sep 18, 2018, at 2:36 PM, Jeff Kirsher wrote:
>
> On Tue, 2018-09-18 at 14:21 -0700, Eric Dumazet wrote:
>>
>> On 09/18/2018 02:13 PM, Eric Dumazet wrote:
>>> On Tue, Sep 18, 2018 at 1:37 PM Song Liu
>>> wrote:
Looks like a patch like the following fixes the issue for ixgbe.
> On Sep 18, 2018, at 2:28 PM, Eric Dumazet wrote:
>
> On Tue, Sep 18, 2018 at 2:25 PM Florian Fainelli wrote:
>>
>>
>> This would not be the only driver doing this unfortunately... should we
>> add a __must_check annotation to help catch those (mis)uses? Though that
>> could cause false
On Tue, 2018-09-18 at 14:21 -0700, Eric Dumazet wrote:
>
> On 09/18/2018 02:13 PM, Eric Dumazet wrote:
> > On Tue, Sep 18, 2018 at 1:37 PM Song Liu
> > wrote:
> > >
> > > Looks like a patch like the following fixes the issue for ixgbe.
> > > But I
> > > cannot explain it yet.
> > >
> > > Does
On 09/18/2018 02:28 PM, Eric Dumazet wrote:
> On Tue, Sep 18, 2018 at 2:25 PM Florian Fainelli wrote:
>>
>>
>> This would not be the only driver doing this unfortunately... should we
>> add a __must_check annotation to help catch those (mis)uses? Though that
>> could cause false positives for
On 9/18/18 1:20 PM, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> If boolean CONFIG_BPF_SYSCALL is enabled, kernel/bpf/syscall.c will
> call flow_dissector functions from net/core/flow_dissector.c.
>
> This causes this build failure if CONFIG_NET is disabled:
>
>
On Tue, Sep 18, 2018 at 2:25 PM Florian Fainelli wrote:
>
>
> This would not be the only driver doing this unfortunately... should we
> add a __must_check annotation to help catch those (mis)uses? Though that
> could cause false positives for drivers using NAPI to clean their TX ring.
>
Well,
On 09/18/2018 02:13 PM, Eric Dumazet wrote:
> On Tue, Sep 18, 2018 at 1:37 PM Song Liu wrote:
>>
>
>> Looks like a patch like the following fixes the issue for ixgbe. But I
>> cannot explain it yet.
>>
>> Does this ring a bell?
>
> I dunno, it looks like the NIC is generating an interrupt
On Tue, Sep 18, 2018 at 2:22 PM Song Liu wrote:
>
> Thanks Eric!
>
> I was looking at exactly this part. :) And it seems working!
And this should also make busy polling a bit faster as well, avoiding
enabling/receiving interrupts in the busy loop.
>
> I will run a bigger test and update
> On Sep 18, 2018, at 2:13 PM, Eric Dumazet wrote:
>
> On Tue, Sep 18, 2018 at 1:37 PM Song Liu wrote:
>>
>
>> Looks like a patch like the following fixes the issue for ixgbe. But I
>> cannot explain it yet.
>>
>> Does this ring a bell?
>
> I dunno, it looks like the NIC is generating
On 09/18/2018 02:13 PM, Eric Dumazet wrote:
> On Tue, Sep 18, 2018 at 1:37 PM Song Liu wrote:
>>
>
>> Looks like a patch like the following fixes the issue for ixgbe. But I
>> cannot explain it yet.
>>
>> Does this ring a bell?
>
> I dunno, it looks like the NIC is generating an interrupt
On Tue, Sep 18, 2018 at 1:37 PM Song Liu wrote:
>
> Looks like a patch like the following fixes the issue for ixgbe. But I
> cannot explain it yet.
>
> Does this ring a bell?
I dunno, it looks like the NIC is generating an interrupt while it should not,
and constantly sets NAPI_STATE_MISSED.
From: Wei Wang
When dst->_metrics and f6i->fib6_metrics share the same memory, both
take reference count on the dst_metrics structure. However, when dst is
destroyed, ip6_dst_destroy() only invokes dst_destroy_metrics_generic()
which does not take care of READONLY metrics and does not release
From: Wei Wang
This reverts commit e70a3aad44cc8b24986687ffc98c4a4f6ecf25ea.
This change causes use-after-free on dst->_metrics.
The crash trace looks like this:
[ 97.763269] BUG: KASAN: use-after-free in ip6_mtu+0x116/0x140
[ 97.769038] Read of size 4 at addr 881781d2cf84 by task
From: Wei Wang
The latest fix on the memory leak of fib6_metrics still causes
use-after-free.
This patch series first revert the previous fix and propose a new fix
that is more inline with ipv4 logic and is tested to fix the
use-after-free issue reported.
Wei Wang (2):
Revert "ipv6: fix
On Tue, Sep 18, 2018 at 2:09 PM Eric Dumazet wrote:
>
>
>
> On 09/14/2018 07:46 AM, Petar Penkov wrote:
> > From: Petar Penkov
> >
> > Adds a hook for programs of type BPF_PROG_TYPE_FLOW_DISSECTOR and
> > attach type BPF_FLOW_DISSECTOR that is executed in the flow dissector
> > path. The BPF
> On Sep 18, 2018, at 11:17 AM, Eric Dumazet wrote:
>
> On Tue, Sep 18, 2018 at 10:51 AM Alexei Starovoitov wrote:
>>
>> On 9/18/18 6:45 AM, Eric Dumazet wrote:
>>> On Tue, Sep 18, 2018 at 1:41 AM Song Liu wrote:
We are debugging this issue that netconsole message triggers
From: Willem de Bruijn
If boolean CONFIG_BPF_SYSCALL is enabled, kernel/bpf/syscall.c will
call flow_dissector functions from net/core/flow_dissector.c.
This causes this build failure if CONFIG_NET is disabled:
kernel/bpf/syscall.o: In function `__x64_sys_bpf':
On Mon, Sep 17, 2018 at 12:25 AM Kirill Tkhai wrote:
> In inet_init() the order of registration is:
>
> ip_mr_init();
> init_inet_pernet_ops();
>
> This means, ipmr_net_ops pernet operations are before af_inet_ops
> in pernet_list. So, there is a theoretical probability, sometimes
On 18.09.2018 22:02, Florian Fainelli wrote:
> On 09/18/2018 12:12 PM, Heiner Kallweit wrote:
>> I think I've seen a similar or same patch before, not sure why it
>> didn't make it yet. When being in state PHY_HALTED we don't have to
>> reschedule the state machine, phy_start() will start it
On 09/18/2018 12:12 PM, Heiner Kallweit wrote:
> I think I've seen a similar or same patch before, not sure why it
> didn't make it yet. When being in state PHY_HALTED we don't have to
> reschedule the state machine, phy_start() will start it again.
Yes, this is conceptually the same patch as as
phy_stop() may be called e.g. when suspending, therefore all needed
actions should be performed synchronously. Therefore add a synchronous
call to the state machine.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
When bringing down the netdevice (incl. detaching it) and calling
netif_carrier_off directly or indirectly the latter triggers an
asynchronous linkwatch event.
This linkwatch event eventually may fail to access chip registers in
the ndo_get_stats/ndo_get_stats64 callback because the device isn't
There have been few not that successful attempts in the past to make
phy_stop() a synchronous call instead of just changing the state.
Patch 1 of this series addresses an issue which prevented this change.
At least for me it works fine now. Would appreciate if Geert could
re-test as well that
I think I've seen a similar or same patch before, not sure why it
didn't make it yet. When being in state PHY_HALTED we don't have to
reschedule the state machine, phy_start() will start it again.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1
On Tue, 18 Sep 2018 18:37:23 +0530, Arjun Vynipadath wrote:
> Forcing link up of virtual interfaces even when physical link is down
> causes packet drops and ping failures during bonding failover. Hence
> adding a ethtool private flag to toggle force_link_up whenever required.
>
> Signed-off-by:
On Tue, Sep 18, 2018 at 10:51 AM Alexei Starovoitov wrote:
>
> On 9/18/18 6:45 AM, Eric Dumazet wrote:
> > On Tue, Sep 18, 2018 at 1:41 AM Song Liu wrote:
> >>
> >> We are debugging this issue that netconsole message triggers pegged softirq
> >> (ksoftirqd taking 100% CPU for many seconds). We
On 09/14/2018 07:46 AM, Petar Penkov wrote:
> From: Petar Penkov
>
> Adds a hook for programs of type BPF_PROG_TYPE_FLOW_DISSECTOR and
> attach type BPF_FLOW_DISSECTOR that is executed in the flow dissector
> path. The BPF program is per-network namespace
...
>
> + rcu_read_lock();
>
On 9/18/18 6:45 AM, Eric Dumazet wrote:
> On Tue, Sep 18, 2018 at 1:41 AM Song Liu wrote:
>>
>> We are debugging this issue that netconsole message triggers pegged softirq
>> (ksoftirqd taking 100% CPU for many seconds). We found this issue in
>> production with both bnxt and ixgbe, on a 4.11
On Tue, 2018-09-18 at 10:18 -0700, David Ahern wrote:
> On 9/18/18 6:12 AM, Johannes Berg wrote:
> > diff --git a/lib/nlattr.c b/lib/nlattr.c
> > index 120ad569e13d..efbd6c1aff29 100644
> > --- a/lib/nlattr.c
> > +++ b/lib/nlattr.c
> > @@ -181,9 +181,13 @@ int nla_validate(const struct nlattr
On Tue, Sep 18, 2018 at 10:15 AM Jakub Kicinski
wrote:
>
> libc_compat.h is used by libbpf so make sure it's licensed under
> LGPL or BSD license. The license change should be OK, I'm the only
> author of the file.
>
> Signed-off-by: Jakub Kicinski
> Reviewed-by: Quentin Monnet
Acked-by:
On Tue, Sep 18, 2018 at 3:13 AM Magnus Karlsson
wrote:
>
> Previously, the xsk code did not record which umem was bound to a
> specific queue id. This was not required if all drivers were zero-copy
> enabled as this had to be recorded in the driver anyway. So if a user
> tried to bind two umems
On 9/18/18 6:12 AM, Johannes Berg wrote:
> From: Johannes Berg
>
> This isn't used anywhere, so we might as well get rid of it.
>
> Signed-off-by: Johannes Berg
> ---
> include/net/netlink.h | 2 --
> lib/nlattr.c | 11 ---
> 2 files changed, 13 deletions(-)
>
Reviewed-by:
On 9/18/18 6:12 AM, Johannes Berg wrote:
> diff --git a/lib/nlattr.c b/lib/nlattr.c
> index 120ad569e13d..efbd6c1aff29 100644
> --- a/lib/nlattr.c
> +++ b/lib/nlattr.c
> @@ -181,9 +181,13 @@ int nla_validate(const struct nlattr *head, int len, int
> maxtype,
> int rem;
>
>
libc_compat.h is used by libbpf so make sure it's licensed under
LGPL or BSD license. The license change should be OK, I'm the only
author of the file.
Signed-off-by: Jakub Kicinski
Reviewed-by: Quentin Monnet
---
tools/include/tools/libc_compat.h | 2 +-
1 file changed, 1 insertion(+), 1
> On Sep 18, 2018, at 9:33 AM, Eric Dumazet wrote:
>
> On Tue, Sep 18, 2018 at 9:19 AM Song Liu wrote:
>>
>>
>>
>>> On Sep 18, 2018, at 6:45 AM, Eric Dumazet wrote:
>>>
>>> On Tue, Sep 18, 2018 at 1:41 AM Song Liu wrote:
We are debugging this issue that netconsole message
On Tue, Sep 18, 2018 at 9:19 AM Song Liu wrote:
>
>
>
> > On Sep 18, 2018, at 6:45 AM, Eric Dumazet wrote:
> >
> > On Tue, Sep 18, 2018 at 1:41 AM Song Liu wrote:
> >>
> >> We are debugging this issue that netconsole message triggers pegged softirq
> >> (ksoftirqd taking 100% CPU for many
On Tue, 2018-09-18 at 12:19 -0400, Song Liu wrote:
> > On Sep 18, 2018, at 6:45 AM, Eric Dumazet
> > wrote:
> >
> > On Tue, Sep 18, 2018 at 1:41 AM Song Liu
> > wrote:
> > >
> > > We are debugging this issue that netconsole message triggers
> > > pegged softirq
> > > (ksoftirqd taking 100% CPU
> On Sep 18, 2018, at 6:45 AM, Eric Dumazet wrote:
>
> On Tue, Sep 18, 2018 at 1:41 AM Song Liu wrote:
>>
>> We are debugging this issue that netconsole message triggers pegged softirq
>> (ksoftirqd taking 100% CPU for many seconds). We found this issue in
>> production with both bnxt and
These implementations from Samuel Neves support AVX and AVX-512VL.
Originally this used AVX-512F, but Skylake thermal throttling made
AVX-512VL more attractive and possible to do with negligable difference.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc:
It is possible (via shutdown()) for TCP socks to go trough TCP_CLOSE
state via tcp_disconnect() without actually calling tcp_close which
would then call our bpf_tcp_close() callback. Because of this a user
could disconnect a socket then put it in a LISTEN state which would
break our assumptions
After this patch we only allow socks that are in ESTABLISHED state or
are being added via a sock_ops event that is transitioning into an
ESTABLISHED state. By allowing sock_ops events we allow users to
manage sockmaps directly from sock ops programs. The two supported
sock_ops ops are
Ensure that sockets added to a sock{map|hash} that is not in the
ESTABLISHED state is rejected.
Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks")
Signed-off-by: John Fastabend
Acked-by: Yonghong Song
---
tools/testing/selftests/bpf/test_maps.c | 10 +++---
1
Eric noted that using the close callback is not sufficient
to catch all transitions from ESTABLISHED state to a LISTEN
state. So this series does two things. First, only allow
adding socks in ESTABLISH state and second use unhash callback
to catch tcp_disconnect() transitions.
v2: added check for
On 09/18/2018 07:08 AM, Yonghong Song wrote:
> samples/bpf build failed with the following errors:
>
> $ make samples/bpf/
> ...
> HOSTCC samples/bpf/sockex3_user.o
> /data/users/yhs/work/net-next/samples/bpf/sockex3_user.c:16:8: error:
> redefinition of ‘struct bpf_flow_keys’
>
If a network interface is created prior to the SFP socket being
available, ethtool can request module information. This unfortunately
leads to an oops:
Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = (ptrval)
[0008] *pgd=7c400831, *pte=,
On 09/18/2018 01:13 AM, Yonghong Song wrote:
> This is a followup patch for Commit f6f3bac08ff9
> ("tools/bpf: bpftool: add net support").
> Some improvements are made for the bpftool net output.
> Specially, plain output is more concise such that
> per attachment should nicely fit in one line.
>
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Jesse Brandeburg
> Sent: Friday, September 14, 2018 5:38 PM
> To: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org
> Subject: [Intel-wired-lan] [PATCH net-next v2 02/14] iavf:
On 09/17/2018 10:26 PM, Li RongQing wrote:
> if skb->head is vmalloc address, when this skb is delivered, full
> allocation for this skb is required, if there are many devices,
> the full allocation will be called for every devices
>
> now using the first time allocated skb when iterate other
On Tue, Sep 18, 2018 at 1:41 AM Song Liu wrote:
>
> We are debugging this issue that netconsole message triggers pegged softirq
> (ksoftirqd taking 100% CPU for many seconds). We found this issue in
> production with both bnxt and ixgbe, on a 4.11 based kernel. This is easily
> reproducible with
> This will lead to deadlocks, idev->mc_lock must be taken with _bh().
Modified the existing spin_lock to spin_lock_bh
> I have zero confidence in this change, did you do any stress testing
> with lockdep enabled? It would have caught this quickly.
With LOCKDEP enabled ran LTP multicast stress
On Thu, 2018-09-13 at 10:03 -0700, Roopa Prabhu wrote:
> On Thu, Sep 6, 2018 at 8:40 PM, Roopa Prabhu
> wrote:
> > On Thu, Sep 6, 2018 at 2:10 AM, Patrick Ruddy
> > wrote:
> > > Some userspace applications need to know about IGMP joins from the
> > > kernel for 2 reasons:
> > > 1. To allow the
From: Johannes Berg
In one of my previous patches in this area I introduced code
to pass out just the error message to store in the extack, for
use in NLA_REJECT.
Change this code now to set both the error message and the bad
attribute pointer, and carry around a boolean indicating that
the
From: Johannes Berg
In nla_parse() we already set this, but it makes sense to
also do it in nla_validate() which already also sets the
bad attribute pointer.
CC: David Ahern
Signed-off-by: Johannes Berg
---
lib/nlattr.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
1 - 100 of 117 matches
Mail list logo
