> On Sep 19, 2018, at 5:59 PM, Alexei Starovoitov wrote:
>
> On 9/19/18 4:44 PM, Song Liu wrote:
>>
>>
>>> On Sep 19, 2018, at 3:39 PM, Alexei Starovoitov wrote:
>>>
>>> use perf_event_mmap_bpf_prog() helper to notify user space
>>> about JITed bpf programs.
>>> Use RECORD_MMAP perf event
On 9/20/2018 12:29 AM, Jakub Kicinski wrote:
On Wed, 19 Sep 2018 16:51:43 +0900, Prashant Bhole wrote:
Let's add a check for EOPNOTSUPP error when map lookup is failed.
Also in case map doesn't support lookup, the output of map dump is
changed from "can't lookup element" to "lookup not
On Wed, Sep 19, 2018 at 12:17:01PM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 17, 2018 at 02:03:53PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > From Yishai,
> >
> > This series comes to enable the DEVX functionality in some wider scope,
> > specifically,
> > - It enables
In certain multi-function switch dependent modes, firmware adds vlan tag 0
to the untagged frames. This leads to double tagging for the traffic
if the dcbx is enabled, which is not the desired behavior. To avoid this,
driver needs to set "dcb_dont_add_vlan0" flag.
Fixes: cac6f691 ("qed: Add
From: Sudarsana Reddy Kalluru
The patch series addresses few issues in the switch dependent multi-function
modes.
Please consider applying it to 'net' tree.
Sudarsana Reddy Kalluru (3):
qed: Fix populating the invalid stag value in multi function mode.
qed: Do not add VLAN 0 tag to
This patch adds support to configure the DORQ to use vlan-id/priority for
roce EDPM.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru
Signed-off-by: Tomer Tayar
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 40 ++
In multi-function mode, driver receives the stag value (outer vlan)
for a PF from management FW (MFW). If the stag value is negotiated prior to
the driver load, then the stag is not notified to the driver and hence
driver will have the invalid stag value.
The fix is to request the MFW for STAG
On Wed, Sep 19, 2018 at 11:27:31AM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 17, 2018 at 02:03:55PM +0300, Leon Romanovsky wrote:
> > From: Yishai Hadas
> >
> > Set uid as part of QP commands so that the firmware can manage the
> > QP object in a secured way.
> >
> > That will enable using a QP
On Wed, Sep 19, 2018 at 11:31:47AM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 17, 2018 at 02:04:00PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > Add DEVX information to WQ, SRQ, CQ, TRI, TIS, QP,
> > RQ, XRCD, PD, MKEY and MCG.
> >
> > Signed-off-by: Leon Romanovsky
> > ---
On Wed, Sep 19, 2018 at 12:15 AM Magnus Karlsson
wrote:
>
> On Tue, Sep 18, 2018 at 7:23 PM Y Song wrote:
> >
> > 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
On 9/18/18 6:12 AM, Patrick Ruddy wrote:
>
> I've hit a small snag with adding the new groups. The number of defined
> groups currently sits at 31 so I can only add one before hitting the
I believe you have no more available. RTNLGRP_* has been defined from 0
(RTNLGRP_NONE) to 31
> 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.
Tested-by: Chris Healy
Tested with Marvell 88E6161 and Marvell 88E6352 switches (which use
Marvell PHY
From: Paolo Abeni
Date: Wed, 19 Sep 2018 15:02:07 +0200
> the ip6 tunnel xmit ndo assumes that the processed skb always
> contains an ip[v6] header, but syzbot has found a way to send
> frames that fall short of this assumption, leading to the following splat:
...
> This change addresses the
From: Antoine Tenart
Date: Wed, 19 Sep 2018 15:29:06 +0200
> With CONFIG_DMA_API_DEBUG enabled we now get a warning when using the
> mvneta driver:
>
> mvneta d003.ethernet: DMA-API: device driver frees DMA memory with
> wrong function [device address=0x1165b000] [size=4096
From: David Ahern
Date: Wed, 19 Sep 2018 10:19:05 -0700
> On 9/19/18 5:56 AM, Mike Manning wrote:
>> From: Robert Shearman
>>
>> There is no way currently for an IPv6 client connect using a loopback
>> address in a VRF, whereas for IPv4 the loopback address can be added:
>>
>> $ sudo ip
From: Heiner Kallweit
Date: Tue, 18 Sep 2018 21:54:23 +0200
> 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
On 9/20/2018 12:29 AM, Jakub Kicinski wrote:
On Wed, 19 Sep 2018 16:51:43 +0900, Prashant Bhole wrote:
Let's add a check for EOPNOTSUPP error when map lookup is failed.
Also in case map doesn't support lookup, the output of map dump is
changed from "can't lookup element" to "lookup not
On 9/20/2018 12:26 AM, Jakub Kicinski wrote:
On Wed, 19 Sep 2018 16:51:42 +0900, Prashant Bhole wrote:
+static int dump_map_elem(int fd, void *key, void *value,
+struct bpf_map_info *map_info, struct btf *btf,
+json_writer_t *btf_wtr)
+{
+
On 9/20/2018 12:14 AM, Alexei Starovoitov wrote:
On Wed, Sep 19, 2018 at 04:51:41PM +0900, Prashant Bhole wrote:
Return ERR_PTR(-EOPNOTSUPP) from map_lookup_elem() methods of below
map types:
- BPF_MAP_TYPE_PROG_ARRAY
- BPF_MAP_TYPE_STACK_TRACE
- BPF_MAP_TYPE_XSKMAP
-
On 9/20/2018 3:40 AM, Mauricio Vasquez wrote:
On 09/19/2018 10:14 AM, Alexei Starovoitov wrote:
On Wed, Sep 19, 2018 at 04:51:41PM +0900, Prashant Bhole wrote:
Return ERR_PTR(-EOPNOTSUPP) from map_lookup_elem() methods of below
map types:
- BPF_MAP_TYPE_PROG_ARRAY
-
On 2018/9/19 22:15, Timur Tabi wrote:
> On 9/19/18 7:25 AM, Andrew Lunn wrote:
>> ACPI is completely separate and should not affect the DT binding.
>> I've not yet looked at the ACPI changes you added.
> Just FYI, there is no device tree platform on which the upstream EMAC
> driver works. All of
On 9/19/18 4:44 PM, Song Liu wrote:
On Sep 19, 2018, at 3:39 PM, Alexei Starovoitov wrote:
use perf_event_mmap_bpf_prog() helper to notify user space
about JITed bpf programs.
Use RECORD_MMAP perf event to tell user space where JITed bpf program was
loaded.
Use empty program name as unload
On 9/19/18 4:30 PM, Song Liu wrote:
>
>
>> On Sep 19, 2018, at 3:39 PM, Alexei Starovoitov wrote:
>>
>> introduce perf_event_mmap_bpf_prog() helper to emit RECORD_MMAP events
>> into perf ring buffer.
>> It's used by bpf load/unload logic to notify user space of addresses
>> and names of JITed
pfkey_broadcast() can make calls to pfkey_broadcast_one() which
will clone or copy the passed in SKB. This new SKB will be assigned
the sock_rfree() function as its destructor, which requires that
the socket reference the SKB contains is valid when the SKB is freed.
If this SKB is ever passed to
On 09/18/2018 01:17 PM, Heiner Kallweit wrote:
> 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
>>>
On 09/18/2018 12:56 PM, Heiner Kallweit wrote:
> 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
Reviewed-by: Florian Fainelli
Yes!
--
On 09/18/2018 12:55 PM, Heiner Kallweit wrote:
> 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
> On Sep 19, 2018, at 3:39 PM, Alexei Starovoitov wrote:
>
> use perf_event_mmap_bpf_prog() helper to notify user space
> about JITed bpf programs.
> Use RECORD_MMAP perf event to tell user space where JITed bpf program was
> loaded.
> Use empty program name as unload indication.
>
>
From: Vlad Buslov
From: Vlad Buslov
Action API was changed to work with actions and action_idr in concurrency
safe manner, however tcf_del_walker() still uses actions without taking a
reference or idrinfo->lock first, and deletes them directly, disregarding
possible concurrent delete.
Change
Hi,
here are simply fixes to restore 'make alltests'.
Currently it does not run.
Kind regards,
Petr
Petr Vorel (3):
testsuite: Fix missing generate_nlmsg
testsuite: Generate generate_nlmsg when needed
testsuite: Warn about empty $(IPVERS)
testsuite/Makefile | 21 ++---
1
Commit ad23e152 caused generate_nlmsg to be always missing:
$ make alltests
make: ./tools/generate_nlmsg: Command not found
Create testclean: to remove only results directory.
Fixes: ad23e152 testsuite: remove all temp files and implement make clean
Signed-off-by: Petr Vorel
---
alltests target requires having symlink created by configure target
(default target). Without that there is no test being run.
Signed-off-by: Petr Vorel
---
testsuite/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/testsuite/Makefile b/testsuite/Makefile
index 1c2467f5..b3aebec1
Commit 886f2c43 added generate_nlmsg.c. Running alltests
target, which uses the binary required to run 'make -C tools' before.
Fixes: 886f2c43 testsuite: Generate nlmsg blob at runtime
Signed-off-by: Petr Vorel
---
testsuite/Makefile | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
> On Sep 19, 2018, at 3:39 PM, Alexei Starovoitov wrote:
>
> introduce perf_event_mmap_bpf_prog() helper to emit RECORD_MMAP events
> into perf ring buffer.
> It's used by bpf load/unload logic to notify user space of addresses
> and names of JITed bpf programs.
>
> Note that event->mmap.pid
Recognize JITed bpf prog load/unload events.
Add/remove kernel symbols accordingly.
Signed-off-by: Alexei Starovoitov
---
tools/perf/util/machine.c | 27 +++
tools/perf/util/symbol.c | 13 +
tools/perf/util/symbol.h | 1 +
3 files changed, 41 insertions(+)
use perf_event_mmap_bpf_prog() helper to notify user space
about JITed bpf programs.
Use RECORD_MMAP perf event to tell user space where JITed bpf program was
loaded.
Use empty program name as unload indication.
Signed-off-by: Alexei Starovoitov
---
kernel/bpf/core.c | 22
Hi All,
this patch set adds kernel and user space support to reveal
short lived bpf programs.
The kernel stores addr+bpf_prog_name information into perf ring buffer.
Later 'perf report' can properly attribute the cpu time to the program.
The following command was run before and after: 'perf
introduce perf_event_mmap_bpf_prog() helper to emit RECORD_MMAP events
into perf ring buffer.
It's used by bpf load/unload logic to notify user space of addresses
and names of JITed bpf programs.
Note that event->mmap.pid == -1 is an existing indicator of kernel event.
In addition use
On Mon, Sep 17, 2018 at 12:19 AM Vlad Buslov wrote:
> @@ -482,16 +483,25 @@ static int tcf_block_insert(struct tcf_block *block,
> struct net *net,
> struct netlink_ext_ack *extack)
> {
> struct tcf_net *tn = net_generic(net, tcf_net_id);
> + int err;
>
On Mon, Sep 17, 2018 at 12:19 AM Vlad Buslov wrote:
> +static void tcf_qdisc_put(struct Qdisc *q, bool rtnl_held)
> +{
> + if (!q)
> + return;
> +
> + if (rtnl_held)
> + qdisc_put(q);
> + else
> + qdisc_put_unlocked(q);
> +}
This is
On 09/18/2018 07:13 PM, 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
Applied to bpf, thanks
On 09/18/2018 10: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 Mon, Sep 17, 2018 at 12:19 AM Vlad Buslov wrote:
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -130,6 +130,12 @@ int rtnl_is_locked(void)
> }
> EXPORT_SYMBOL(rtnl_is_locked);
>
> +bool refcount_dec_and_rtnl_lock(refcount_t *r)
> +{
> + return
NFP supports fairly enormous ring sizes (up to 256k descriptors).
In commit 466271703867 ("nfp: use kvcalloc() to allocate SW buffer
descriptor arrays") we have started using kvcalloc() functions to
make sure the allocation of software state arrays doesn't hit
the MAX_ORDER limit. Unfortunately,
On Wed, Sep 19, 2018 at 1:25 AM Kirill Tkhai wrote:
>
> On 18.09.2018 23:17, Cong Wang wrote:
> > 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,
On Wed, Sep 19, 2018 at 09:19:31PM +0200, Johannes Berg wrote:
> On Wed, 2018-09-19 at 15:46 -0300, Marcelo Ricardo Leitner wrote:
>
> > > NL_SET_ERR_MSG(extack, "warning: deprecated command");
> > > err = nla_parse(..., extack);
> > > if (err)
> > > return err;
> > > /* do
On Wed, Sep 19, 2018 at 11:40:45AM -0700, Saeed Mahameed wrote:
> On Wed, Sep 19, 2018 at 10:28 AM Jason Gunthorpe wrote:
> >
> > On Mon, Sep 17, 2018 at 02:03:56PM +0300, Leon Romanovsky wrote:
> > > From: Yishai Hadas
> > >
> > > Set uid as part of RQ commands so that the firmware can manage
On 19.09.18 19:03, Stephen Hemminger wrote:
> On Wed, 19 Sep 2018 19:45:08 +0300
> Ido Schimmel wrote:
>
>> On Wed, Sep 19, 2018 at 01:00:15PM +0200, Johannes Wienke wrote:
>>> This behavior of inheriting the mac address is really unexpected to us.
>>> Is it documented somewhere?
>>
>> Not
XFRM mode parameters passed as part of the user templates
in the IP_XFRM_POLICY are never properly validated. Passing
values other than valid XFRM modes can cause stack-out-of-bounds
reads to occur later in the XFRM processing:
[ 140.535608]
Setting register 0x82 to value 01 is done a few lines before for all
chip versions <= 06 anyway. And setting PHY register 0x0b to value 00
is done at the end of rtl8169s_hw_phy_config() already. So we can
remove this.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169.c | 9
PCI_LATENCY_TIMER is ignored on PCIe, therefore we have to do this
for the PCI chips (version <= 06) only. Also we can move setting
PCI_CACHE_LINE_SIZE.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff
>From e4f144286efe0f298c11efe58e17b1ab91c7ee3f Mon Sep 17 00:00:00 2001
From: Saif Hasan
Date: Mon, 17 Sep 2018 16:28:54 -0700
Subject: [PATCH] mpls: allow routes on ip6gre devices
Summary:
This appears to be necessary and sufficient change to enable `MPLS` on
`ip6gre` tunnels (RFC4023).
This
>From e4f144286efe0f298c11efe58e17b1ab91c7ee3f Mon Sep 17 00:00:00 2001
From: Saif Hasan
Date: Mon, 17 Sep 2018 16:28:54 -0700
Subject: [PATCH] mpls: allow routes on ip6gre devices
Summary:
This appears to be necessary and sufficient change to enable `MPLS` on
`ip6gre` tunnels (RFC4023).
This
On Wed, 2018-09-19 at 15:46 -0300, Marcelo Ricardo Leitner wrote:
> > NL_SET_ERR_MSG(extack, "warning: deprecated command");
> > err = nla_parse(..., extack);
> > if (err)
> > return err;
> > /* do something */
> > return 0;
> >
> > Here you could consider the
Summary:
This appears to be necessary and sufficient change to enable `MPLS` on
`ip6gre` tunnels (RFC4023).
This diff allows IP6GRE devices to be recognized by MPLS kernel module
and hence user can configure interface to accept packets with mpls
headers as well setup mpls routes on them.
Test
From: Saif Hasan
Summary:
This appears to be necessary and sufficient change to enable `MPLS` on
`ip6gre` tunnels (RFC4023).
This diff allows IP6GRE devices to be recognized by MPLS kernel module
and hence user can configure interface to accept packets with mpls
headers as well setup mpls
Summary:
This appears to be necessary and sufficient change to enable `MPLS` on
`ip6gre` tunnels (RFC4023).
This diff allows IP6GRE devices to be recognized by MPLS kernel module
and hence user can configure interface to accept packets with mpls
headers as well setup mpls routes on them.
Test
On Wed, Sep 19, 2018 at 11:25:17AM +0200, Johannes Berg wrote:
> On Wed, 2018-09-19 at 00:37 -0300, Marcelo Ricardo Leitner wrote:
>
> > Did you consider indicating the message level, and only overwrite the
> > message that is already in there if the new message level is higher
> > than the
On Wed, Sep 19, 2018 at 10:28 AM Jason Gunthorpe wrote:
>
> On Mon, Sep 17, 2018 at 02:03:56PM +0300, Leon Romanovsky wrote:
> > From: Yishai Hadas
> >
> > Set uid as part of RQ commands so that the firmware can manage the
> > RQ object in a secured way.
> >
> > That will enable using an RQ that
On 09/19/2018 10:14 AM, Alexei Starovoitov wrote:
On Wed, Sep 19, 2018 at 04:51:41PM +0900, Prashant Bhole wrote:
Return ERR_PTR(-EOPNOTSUPP) from map_lookup_elem() methods of below
map types:
- BPF_MAP_TYPE_PROG_ARRAY
- BPF_MAP_TYPE_STACK_TRACE
- BPF_MAP_TYPE_XSKMAP
-
> After running for about 24 hours, I now encountered another panic. This time
> it
> is caused by an out of memory situation. Although the trace shows action in
> the
> filesystem code I'm posting it here because I cannot isolate the error and
> maybe it is caused by our NULL pointer bug or by
On Mon, Sep 17, 2018 at 02:03:53PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> From Yishai,
>
> This series comes to enable the DEVX functionality in some wider scope,
> specifically,
> - It enables using kernel objects that were created by the verbs
> API in the DEVX flow.
> -
David Ahern wrote:
> > I believe ef57170bbfdd6 is the commit that introduced the warning
> >
>
> Hi Florian:
>
> I am still seeing this. I realize the compiler is not understanding the
> conditions properly, but it is a distraction every time I do a kernel
> build on Debian Stretch having to
On Mon, Sep 17, 2018 at 02:04:00PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Add DEVX information to WQ, SRQ, CQ, TRI, TIS, QP,
> RQ, XRCD, PD, MKEY and MCG.
>
> Signed-off-by: Leon Romanovsky
> ---
> include/linux/mlx5/mlx5_ifc.h | 67
>
From: Jian Shen
When roce is loaded before nic, the roce client will not be initialized
until nic client is initialized, but roce init flag is set before it.
Furthermore, in this case of nic initialized success and roce failed,
the nic init flag is not set, and roce init flag is not cleared.
On Mon, Sep 17, 2018 at 02:03:56PM +0300, Leon Romanovsky wrote:
> From: Yishai Hadas
>
> Set uid as part of RQ commands so that the firmware can manage the
> RQ object in a secured way.
>
> That will enable using an RQ that was created by verbs application
> to be used by the DEVX flow in case
On Mon, Sep 17, 2018 at 02:03:55PM +0300, Leon Romanovsky wrote:
> From: Yishai Hadas
>
> Set uid as part of QP commands so that the firmware can manage the
> QP object in a secured way.
>
> That will enable using a QP that was created by verbs application to
> be used by the DEVX flow in case
On 9/19/18 5:56 AM, Mike Manning wrote:
> From: Robert Shearman
>
> There is no way currently for an IPv6 client connect using a loopback
> address in a VRF, whereas for IPv4 the loopback address can be added:
>
> $ sudo ip addr add dev vrfred 127.0.0.1/8
> $ sudo ip -6 addr add ::1/128
On Wed, 19 Sep 2018 19:45:08 +0300
Ido Schimmel wrote:
> On Wed, Sep 19, 2018 at 01:00:15PM +0200, Johannes Wienke wrote:
> > This behavior of inheriting the mac address is really unexpected to us.
> > Is it documented somewhere?
>
> Not that I'm aware, but it's a well established behavior.
bnxt offload code currently supports only 'push' and 'pop' operation: let
.ndo_setup_tc() return -EOPNOTSUPP if VLAN 'modify' action is configured.
Fixes: 2ae7408fedfe ("bnxt_en: bnxt: add TC flower filter offload support")
Signed-off-by: Davide Caratti
---
On 6/18/18 11:10 AM, David Ahern wrote:
> Florian:
>
> I am seeing this warning:
>
> $ make O=kbuild/perf -j 24 -s
> In file included from /home/dsa/kernel-3.git/include/linux/kernel.h:10:0,
> from /home/dsa/kernel-3.git/include/linux/list.h:9,
> from
On Wed, Sep 19, 2018 at 01:00:15PM +0200, Johannes Wienke wrote:
> This behavior of inheriting the mac address is really unexpected to us.
> Is it documented somewhere?
Not that I'm aware, but it's a well established behavior.
Hello,
On Wed, Sep 19, 2018 at 11:24 AM Sabrina Dubroca wrote:
> 2018-09-18, 20:16:12 -0400, Radu Rendec wrote:
> > 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
Instead of commas, just have them as separate argvs.
The parsing state machine might look heavyweight, but it makes it easy to add
more parameters later and distinguish parameter names from encoding names.
Suggested-by: Michal Kubecek
Signed-off-by: Edward Cree
---
ethtool.8.in | 6 +++---
On Wed, Sep 19, 2018 at 04:38:27PM +0100, Edward Cree wrote:
> On 19/09/18 15:41, Michal Kubecek wrote:
> > I'm sorry I didn't notice this before the patch was accepted but as it's
> > not in a release yet, maybe it's still not too late.
> >
> > Could I suggest to make the syntax consistent with
On Wed, Sep 19, 2018 at 05:33:38PM +0200, Andrew Lunn wrote:
> > One loosely related question: how sure can we be that we are never going
> > to need more than 32 bits for FEC encodings? Is it something completely
> > hypothetical or is it something that could happen in the future?
> >
> Hi
On 19/09/18 15:41, Michal Kubecek wrote:
> I'm sorry I didn't notice this before the patch was accepted but as it's
> not in a release yet, maybe it's still not too late.
>
> Could I suggest to make the syntax consistent with other options?
I didn't realise ethtool had any patterns to be
> One loosely related question: how sure can we be that we are never going
> to need more than 32 bits for FEC encodings? Is it something completely
> hypothetical or is it something that could happen in the future?
>
Hi Michal
Hopefully we have moved to a netlink socket by that time :-)
I
On Wed, 19 Sep 2018 16:51:43 +0900, Prashant Bhole wrote:
> Let's add a check for EOPNOTSUPP error when map lookup is failed.
> Also in case map doesn't support lookup, the output of map dump is
> changed from "can't lookup element" to "lookup not supported for
> this map".
>
> Patch adds
On 9/19/2018 3:35 AM, Dan Carpenter wrote:
The ipsec->tx_tbl[] array has IXGBE_IPSEC_MAX_SA_COUNT elements so the >
should be a >=.
Fixes: 0062e7cc955e ("ixgbevf: add VF IPsec offload code")
Signed-off-by: Dan Carpenter
Signed-off-by: Shannon Nelson
diff --git
On Wed, 19 Sep 2018 16:51:42 +0900, Prashant Bhole wrote:
> +static int dump_map_elem(int fd, void *key, void *value,
> + struct bpf_map_info *map_info, struct btf *btf,
> + json_writer_t *btf_wtr)
> +{
> + int num_elems = 0;
> +
> + if
Hello,
2018-09-18, 20:16:12 -0400, Radu Rendec wrote:
> 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.
I got a separate report of the same issue and I've
In current implementation, tls records are encrypted & transmitted
serially. Till the time the previously submitted user data is encrypted,
the implementation waits and on finish starts transmitting the record.
This approach of encrypt-one record at a time is inefficient when
asynchronous crypto
> The focus of any patches for the EMAC should be ACPI, not DT. If anything,
> ACPI support should come first. No one should be writing or reviewing DT
> code before ACPI code.
I suspect that is not going to be easy. Last time i looked, the ACPI
standard had nothing about MDIO busses or PHYs.
On Wed, Sep 19, 2018 at 04:51:41PM +0900, Prashant Bhole wrote:
> Return ERR_PTR(-EOPNOTSUPP) from map_lookup_elem() methods of below
> map types:
> - BPF_MAP_TYPE_PROG_ARRAY
> - BPF_MAP_TYPE_STACK_TRACE
> - BPF_MAP_TYPE_XSKMAP
> - BPF_MAP_TYPE_SOCKMAP/BPF_MAP_TYPE_SOCKHASH
>
> Signed-off-by:
On Wed, Sep 05, 2018 at 06:54:57PM +0100, Edward Cree wrote:
> Of the three drivers that currently support FEC configuration, two (sfc
> and cxgb4[vf]) accept configurations with more than one bit set in the
> feccmd.fec bitmask. (The precise semantics of these combinations vary.)
> Thus, this
On 9/19/18 7:25 AM, Andrew Lunn wrote:
ACPI is completely separate and should not affect the DT binding.
I've not yet looked at the ACPI changes you added.
Just FYI, there is no device tree platform on which the upstream EMAC
driver works. All of the DT code in the driver is theoretical. It
Toke Høiland-Jørgensen wrote:
> > Is it possible to tell a UDP socket that you'd like it to put
> > reception timestamps in skb->tstamp?
>
> I think you probably want SO_TIMESTAMP*?
>
> See
>
From: Robert Shearman
There is no way currently for an IPv6 client connect using a loopback
address in a VRF, whereas for IPv4 the loopback address can be added:
$ sudo ip addr add dev vrfred 127.0.0.1/8
$ sudo ip -6 addr add ::1/128 dev vrfred
RTNETLINK answers: Cannot assign
David Howells writes:
> Hi,
>
> Is it possible to tell a UDP socket that you'd like it to put
> reception timestamps in skb->tstamp?
I think you probably want SO_TIMESTAMP*?
See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/timestamping.txt
Hi,
Is it possible to tell a UDP socket that you'd like it to put reception
timestamps in skb->tstamp?
For some reason, I seem to remember that the kernel used to put something in
there - and AF_RXRPC makes use of it.
David
the ip6 tunnel xmit ndo assumes that the processed skb always
contains an ip[v6] header, but syzbot has found a way to send
frames that fall short of this assumption, leading to the following splat:
BUG: KMSAN: uninit-value in ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307
[inline]
BUG: KMSAN:
There is no way currently for an IPv6 client connect using a loopback
address in a VRF, whereas for IPv4 the loopback address can be added:
$ sudo ip addr add dev vrfred 127.0.0.1/8
$ sudo ip -6 addr add ::1/128 dev vrfred
RTNETLINK answers: Cannot assign requested address
So allow
On Wed, Sep 19, 2018 at 09:19:19AM +, Wang, Dongsheng wrote:
> On 2018/9/18 20:35, Andrew Lunn wrote:
> >>> If you want to describe the MDIO controller, then you embed a mdio
> >>> subnode into your Ethernet MAC node:
> >>>
> >>> emac0: ethernet@feb2 {
> >>> mdio {
> >>>
Dear Ido,
On 9/19/18 12:07 PM, Ido Schimmel wrote:
> On Wed, Sep 19, 2018 at 11:10:22AM +0200, Johannes Wienke wrote:
>> Can someone explain what is happening here and why adding and removing
>> devices to a bridge results in the connectivity issues? How to avoid
>> this behavior? I'd be glad for
The ipsec->tx_tbl[] array has IXGBE_IPSEC_MAX_SA_COUNT elements so the >
should be a >=.
Fixes: 0062e7cc955e ("ixgbevf: add VF IPsec offload code")
Signed-off-by: Dan Carpenter
diff --git a/drivers/net/ethernet/intel/ixgbevf/ipsec.c
b/drivers/net/ethernet/intel/ixgbevf/ipsec.c
index
On Wed, Sep 19, 2018 at 11:10:22AM +0200, Johannes Wienke wrote:
> Can someone explain what is happening here and why adding and removing
> devices to a bridge results in the connectivity issues? How to avoid
> this behavior? I'd be glad for any hint on that.
The MAC address of the bridge
On Wed, 2018-09-19 at 11:28 +0200, Jiri Benc wrote:
> > It might be possible to do this differently, in theory, but all the ways
> > I've tried to come up with so far made the code vastly more complex.
>
> Wouldn't still make sense to store the flag in the struct
> netlink_ext_ack, though?
Does
On Wed, 19 Sep 2018 11:25:17 +0200, Johannes Berg wrote:
> Now, with this patch, all I'm doing is changing the internal behaviour
> of nla_parse/nla_validate - externally, it still overwrites any existing
> message if an error occurs, but internally it keeps the inner-most
> error.
Ah, okay, that
On Wed, 19 Sep 2018 11:15:25 +0200, Johannes Berg wrote:
> For one, having the NL_SET_* macros check it on their own will already
> not work - as we discussed over in the NLA_REJECT thread, we do need to
> be able to override the data, e.g. if somebody does
>
> NL_SET_ERR_MSG(extack, "warning:
1 - 100 of 117 matches
Mail list logo
