Commit b04df400c302 ("tools/bpftool: add perf subcommand")
introduced bpftool subcommand perf to query bpf program
kuprobe and tracepoint attachments.
The perf subcommand will first test whether bpf subcommand
BPF_TASK_FD_QUERY is supported in kernel or not. It does it
by opening a file with argv[
> Looks like the recent conversion from poll to poll_mask callback started
> in 152524231023 ("net: add support for ->poll_mask in proto_ops") missed
> to eventually convert kTLS, too: TCP's ->poll was converted over to the
> ->poll_mask in commit 2c7d3dacebd4 ("net/tcp: convert to ->poll_mask")
>
Once upon a time nfp_cpp_resource_find() took a name parameter,
which could be any user-chosen string. Resources are identified
by a CRC32 hash of a 8 byte string, so we had to pad user input
with zeros to make sure CRC32 gave the correct result.
Since then nfp_cpp_resource_find() was made to ope
We are gathering software statistics on per-ring basis.
.ndo_get_stats64 handler adds the rings up. Unfortunately
we are currently only adding up active rings, which means
that if user decreases the number of active rings the
statistics from deactivated rings will no longer be counted
and total in
Hi!
Various fixes for the NFP. Patch 1 fixes a harmless GCC 8 warning.
Patch 2 ensures statistics are correct after users decrease the number
of channels/rings. Patch 3 restores phy_port_name behaviour for flower,
ndo_get_phy_port_name used to return -EOPNOTSUPP on one of the netdevs,
and we nee
.ndo_get_phys_port_name was recently extended to support multi-vNIC
FWs. These are firmwares which can have more than one vNIC per PF
without associated port (e.g. Adaptive Buffer Management FW), therefore
we need a way of distinguishing the vNICs. Unfortunately, it's too
late to make flower use
From: Pieter Jansen van Vuuren
We need to release the refcnt on dst_entry in the route table, otherwise
we will leak the route.
Fixes: 8e6a9046b66a ("nfp: flower vxlan neighbour offload")
Signed-off-by: Pieter Jansen van Vuuren
Signed-off-by: Louis Peens
Reviewed-by: Jakub Kicinski
---
drive
On 6/11/18 7:42 PM, Jakub Kicinski wrote:
On Mon, 11 Jun 2018 19:01:08 -0700, Yonghong Song wrote:
Commit b04df400c302 ("tools/bpftool: add perf subcommand")
introduced bpftool subcommand perf to query bpf program
kuprobe and tracepoint attachments.
The perf subcommand will first test whethe
I would like to bring up some problems with the current GSO
implementation in SCTP.
The most important for me right now is that SCTP uses
"skb_gro_receive()" to build "GSO" frames :-(
Really it just ends up using the slow path (basically, label 'merge'
and onwards).
So, using a GRO helper to b
On Mon, 11 Jun 2018 20:11:33 -0600
Subash Abhinov Kasiviswanathan wrote:
> This patch adds support for OUTPUT_MARK in xfrm state to exercise the
> functionality added by kernel commit 077fbac405bf
> ("net: xfrm: support setting an output mark.").
>
> Sample output with output-mark -
>
> src 192
On 06/11/2018 06:00 PM, David Miller wrote:
>
> This is not necessary. skb_gro_receive() will never change what
> 'head' points to.
>
> In it's original implementation (see commit 71d93b39e52e ("net: Add
> skb_gro_receive")), it did:
>
>
> + *head = nskb;
> + nsk
On Mon, 11 Jun 2018 19:01:08 -0700, Yonghong Song wrote:
> Commit b04df400c302 ("tools/bpftool: add perf subcommand")
> introduced bpftool subcommand perf to query bpf program
> kuprobe and tracepoint attachments.
>
> The perf subcommand will first test whether bpf subcommand
> BPF_TASK_FD_QUERY i
On Tue, Jun 12, 2018 at 11:12 AM Subash Abhinov Kasiviswanathan
wrote:
>
> This patch adds support for OUTPUT_MARK in xfrm state to exercise the
> functionality added by kernel commit 077fbac405bf
> ("net: xfrm: support setting an output mark.").
>
> Sample output with output-mark -
>
> src 192.16
On Mon, Jun 11, 2018 at 11:56:56AM -0700, Siwei Liu wrote:
> The current implementation may only work with new userspace, even so
> the eth0/eth0nsby naming is not consistenly persisted due to races in
> bus probing.
Which race do you mean exactly?
--
MST
This patch adds support for OUTPUT_MARK in xfrm state to exercise the
functionality added by kernel commit 077fbac405bf
("net: xfrm: support setting an output mark.").
Sample output with output-mark -
src 192.168.1.1 dst 192.168.1.2
proto esp spi 0x4321 reqid 0 mode tunnel
rep
Commit b04df400c302 ("tools/bpftool: add perf subcommand")
introduced bpftool subcommand perf to query bpf program
kuprobe and tracepoint attachments.
The perf subcommand will first test whether bpf subcommand
BPF_TASK_FD_QUERY is supported in kernel or not. It does it
by opening a file with argv[
On 6/11/18 6:49 PM, Jakub Kicinski wrote:
On Mon, 11 Jun 2018 18:15:16 -0700, Yonghong Song wrote:
Commit b04df400c302 ("tools/bpftool: add perf subcommand")
introduced bpftool subcommand perf to query bpf program
kuprobe and tracepoint attachments.
The perf subcommand will first test whethe
On Mon, 11 Jun 2018 18:15:16 -0700, Yonghong Song wrote:
> Commit b04df400c302 ("tools/bpftool: add perf subcommand")
> introduced bpftool subcommand perf to query bpf program
> kuprobe and tracepoint attachments.
>
> The perf subcommand will first test whether bpf subcommand
> BPF_TASK_FD_QUERY i
Commit b04df400c302 ("tools/bpftool: add perf subcommand")
introduced bpftool subcommand perf to query bpf program
kuprobe and tracepoint attachments.
The perf subcommand will first test whether bpf subcommand
BPF_TASK_FD_QUERY is supported in kernel or not. It does it
by opening a file with argv[
This is not necessary. skb_gro_receive() will never change what
'head' points to.
In it's original implementation (see commit 71d93b39e52e ("net: Add
skb_gro_receive")), it did:
+ *head = nskb;
+ nskb->next = p->next;
+ p->next = NULL;
===
Jeff,
Looks like I have some bugs on non-x86 architecture. I need to address
these in a v2 of this set so please hold off on applying until I can
get that submitted either tonight or tomorrow morning.
Thanks.
- Alex
On Mon, Jun 11, 2018 at 4:10 PM, kbuild test robot wrote:
> Hi Alexander,
>
>
From: Daniel Borkmann
Date: Tue, 12 Jun 2018 01:59:56 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Avoid an allocation warning in AF_XDP by adding __GFP_NOWARN for the
>umem setup, from Björn.
>
> 2) Silence a warning in bpf
From: Jeff Kirsher
Date: Mon, 11 Jun 2018 09:16:25 -0700
> This series contains fixes to ixgbe IPsec and MACVLAN.
>
> Alex provides the 5 fixes in this series, starting with fixing an issue
> where num_rx_pools was not being populated until after the queues and
> interrupts were reinitialized wh
On 6/11/2018 12:34 PM, Samudrala, Sridhar wrote:
On 6/11/2018 11:10 AM, Michael S. Tsirkin wrote:
On Mon, Jun 04, 2018 at 08:42:31PM -0700, Stephen Hemminger wrote:
* Set permanent and current address of net_failover device
to match the primary.
We copy the dev_addr of standby dev to
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Avoid an allocation warning in AF_XDP by adding __GFP_NOWARN for the
umem setup, from Björn.
2) Silence a warning in bpf fs when an application tries to open(2) a
pinned bpf obj due to
vlan_changelink silently ignores attempts to change the vlan id
or protocol id of an existing vlan interface. Implement by adding
the new vlan id and protocol to the interface's vlan group and then
removing the old vlan id and protocol from the vlan group.
Signed-off-by: Chas Williams <3ch...@gma
Yeah, true, it's missing INERRS in this case. I'll fix it up a bit.
Frank
On 6/11/18, 4:38 PM, "Eric Dumazet" wrote:
On 06/11/2018 04:25 PM, van der Linden, Frank wrote:
> A few comments on this one:
>
> - obviously this is fairly serious, as it can let corrupted dat
From: dsah...@kernel.org
Date: Mon, 11 Jun 2018 07:12:12 -0700
> From: David Ahern
>
> Valdis reported a BUG in ipv6_add_addr:
...
> Looking at the code I found 1 element (peer_pfx) of the newly introduced
> ifa6_config struct that is not initialized. Use a memset rather than hard
> coding an i
On 06/11/2018 04:25 PM, van der Linden, Frank wrote:
> A few comments on this one:
>
> - obviously this is fairly serious, as it can let corrupted data all the way
> up to the application
Sure, although anyone relying on CRC checksum for ensuring TCP data integrity
has big troubles ;)
I woul
From: Daniel Borkmann
Date: Mon, 11 Jun 2018 23:22:04 +0200
> While hacking on kTLS, I ran into the following panic from an
> unprivileged netserver / netperf TCP session:
...
> Debugging further, it turns out that calling into ctx->sk_poll() is
> invalid since sk_poll itself is NULL which was s
On Mon, Jun 11, 2018 at 11:47 AM, John Fastabend
wrote:
> In selftest test_maps the sockmap test case attempts to add a socket
> in listening state to the sockmap. This is no longer a valid operation
> so it fails as expected. However, the test wrongly reports this as an
> error now. Fix the test
A few comments on this one:
- obviously this is fairly serious, as it can let corrupted data all the way up
to the application
- I am not nuts about the patch itself, the code feels a bit cluttered, but
it's the least invasive way
I could think of. Probably some refactoring is needed at some p
commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash
table") introduced an optimization for the handling of child sockets
created for a new TCP connection.
But this optimization passes any data associated with the last ACK of the
connection handshake up the stack without verifying
Hi John,
On 06/08/2018 05:06 PM, John Fastabend wrote:
> This fixes a crash where we assign tcp_prot to IPv6 sockets instead
> of tcpv6_prot.
>
> Previously we overwrote the sk->prot field with tcp_prot even in the
> AF_INET6 case. This patch ensures the correct tcp_prot and tcpv6_prot
> are used
Hi Alexander,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[also build test ERROR on next-20180608]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github
On Mon, Jun 11, 2018 at 7:29 PM, Maciej Żenczykowski
wrote:
>> This change is a potential performance regression for us. Our
>> networking code sets up multiple sockets used by multiple threads to
>> listen on the same udp port. For the first socket, the bind is done
>> before setting SO_REUSEPO
both patches work properly for me.
Maybe it could be helpful in the first patch to add a print when
pass-through setting fails if raw-ip has not been set, just to let the
user know what is happening.
Thanks for testing Daniele.
I can add an error message there when pass through mode setting fa
On Mon, Jun 11, 2018 at 4:57 AM, Björn Töpel wrote:
> From: Björn Töpel
>
> syzkaller reported a warning from xdp_umem_pin_pages():
>
> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70
> mm/slab_common.c:996
> ...
> __do_kmalloc mm/slab.c:3713 [inline]
> __kmalloc
> This change is a potential performance regression for us. Our
> networking code sets up multiple sockets used by multiple threads to
> listen on the same udp port. For the first socket, the bind is done
> before setting SO_REUSEPORT so that we can get an error and detect
> that the port is curr
On 06/11/18 11:22 PM, Daniel Borkmann wrote:
> While hacking on kTLS, I ran into the following panic from an
> unprivileged netserver / netperf TCP session:
>
> [...]
> Looks like the recent conversion from poll to poll_mask callback started
> in 152524231023 ("net: add support for ->poll_mask i
On 06/11/2018 01:57 PM, Björn Töpel wrote:
> From: Björn Töpel
>
> syzkaller reported a warning from xdp_umem_pin_pages():
>
> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70
> mm/slab_common.c:996
> ...
> __do_kmalloc mm/slab.c:3713 [inline]
> __kmalloc+0x25/0x
On Sun, Jun 3, 2018 at 2:47 PM, Maciej Żenczykowski
wrote:
> From: Maciej Żenczykowski
>
> It is not safe to do so because such sockets are already in the
> hash tables and changing these options can result in invalidating
> the tb->fastreuse(port) caching.
>
> This can have later far reaching co
While hacking on kTLS, I ran into the following panic from an
unprivileged netserver / netperf TCP session:
BUG: unable to handle kernel NULL pointer dereference at
PGD 80037f378067 P4D 80037f378067 PUD 3c0e61067 PMD 0
Oops: 0010 [#1] SMP KASAN PTI
CPU: 1 PID: 2289
From: Julian Anastasov
Date: Mon, 11 Jun 2018 02:02:54 +0300
> IPVS setups with local client and remote tunnel server need
> to create exception for the local virtual IP. What we do is to
> change PMTU from 64KB (on "lo") to 1460 in the common case.
>
> Suggested-by: Martin KaFai Lau
> Fixes: 4
smc->clcsock is an internal TCP socket, after TCP socket
converts to ->poll_mask, ->poll doesn't exist any more.
So just convert smc socket to ->poll_mask too.
Fixes: 2c7d3dacebd4 ("net/tcp: convert to ->poll_mask")
Reported-by: syzbot+f5066e369b2d5fff6...@syzkaller.appspotmail.com
Cc: Christoph H
> -Original Message-
> From: Cong Wang [mailto:xiyou.wangc...@gmail.com]
> Sent: Monday, June 11, 2018 1:03 PM
> To: Kirsher, Jeffrey T
> Cc: David Miller ; Keller, Jacob E
> ; Linux Kernel Network Developers
> ; nhor...@redhat.com; sassm...@redhat.com;
> jogre...@redhat.com; Eric Dumazet
On Mon, Jun 11, 2018 at 12:57 PM, Keller, Jacob E
wrote:
>
> I'm open to alternative suggestinos for fixing this, I think Eric suggested
> that maybe we should just remove the ->reset() call from qdisc_destroy..?
You can't remove ->reset() for non-failure call path.
For failure path, yeah, but
On Mon, Jun 11, 2018 at 10:00 AM, Jeff Kirsher
wrote:
>
> We could mitigate some of these issues by changing fq_codel_init to more
> explicitly cleanup after itself when failing. For example, we could
> ensure that q->flowcnt was set to 0 so that the loop over each flow in
> fq_codel_reset would n
> -Original Message-
> From: Kirsher, Jeffrey T
> Sent: Monday, June 11, 2018 10:00 AM
> To: da...@davemloft.net
> Cc: Keller, Jacob E ; netdev@vger.kernel.org;
> nhor...@redhat.com; sassm...@redhat.com; jogre...@redhat.com; Eric
> Dumazet ; Kirsher, Jeffrey T
>
> Subject: [net] fq_codel:
Hello Sebastian
Thanks for checking this out,
SA> I tried to figure out if the URB-completion handler uses any
SA> locking and stumbled here.
SA> i2400m_pm_notifier() is called from process context. This
SA> function invokes i2400m_fw_cache() + i2400m_fw_uncache(). Both
SA> f
This set of patches addresses two set of fixes. First it backs out
the common callback model which was merged in net-next without
completing all the review feedback or getting maintainer approval.
Then it fixes the transparent VF management code to handle network
namespaces.
Stephen Hemminger (3)
When VF is added, the paravirtual device is already present
and may have been moved to another network namespace. For example,
sometimes the management interface is put in another net namespace
in some environments.
The VF should get moved to where the netvsc device is when the
VF is discovered. T
When finding the parent netvsc device, the search needs to be across
all netvsc device instances (independent of network namespace).
Find parent device of VF using upper_dev_get routine which
searches only adjacent list.
Fixes: e8ff40d4bff1 ("hv_netvsc: improve VF device matching")
Signed-off-by:
The callback model of handling network failover is not suitable
in the current form.
1. It was merged without addressing all the review feedback.
2. It was merged without approval of any of the netvsc maintainers.
3. Design discussion on how to handle PV/VF fallback is still
not complete
On 6/11/2018 11:10 AM, Michael S. Tsirkin wrote:
On Mon, Jun 04, 2018 at 08:42:31PM -0700, Stephen Hemminger wrote:
* Set permanent and current address of net_failover device
to match the primary.
* Carrier should be marked off before registering device
the net_failover device
On Mon, Jun 11, 2018 at 8:22 AM, Stephen Hemminger
wrote:
> On Fri, 8 Jun 2018 17:42:21 -0700
> Siwei Liu wrote:
>
>> On Fri, Jun 8, 2018 at 5:02 PM, Stephen Hemminger
>> wrote:
>> > On Fri, 8 Jun 2018 16:44:12 -0700
>> > Siwei Liu wrote:
>> >
>> >> On Fri, Jun 8, 2018 at 4:18 PM, Stephen Hemmi
On Sun, Jun 03, 2018 at 10:47:05AM -0700, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> It is not safe to do so because such sockets are already in the
> hash tables and changing these options can result in invalidating
> the tb->fastreuse(port) caching.
>
> This can have later far
On Fri, Jun 8, 2018 at 6:29 PM, Jakub Kicinski wrote:
> On Fri, 8 Jun 2018 16:44:12 -0700, Siwei Liu wrote:
>> >> I have a somewhat different view regarding IFF_HIDDEN. The purpose of
>> >> that flag, as well as the 1-netdev model, is to have a means to
>> >> inherit the interface name from the VF
In selftest test_maps the sockmap test case attempts to add a socket
in listening state to the sockmap. This is no longer a valid operation
so it fails as expected. However, the test wrongly reports this as an
error now. Fix the test to avoid adding sockets in listening state.
Fixes: 945ae430aa44
Cc: Pavel
On Fri, Jun 08, 2018 at 03:07:30AM -0700, Maciej Żenczykowski wrote:
> I think we probably need to make sk->sk_reuse back into a boolean.
> (ie. eliminate SK_FORCE_REUSE)
>
> Then add a new tcp/udp sk->ignore_bind_conflicts boolean setting...
> (ie. not just for tcp, but sol_socket) [o
On Mon, Jun 04, 2018 at 08:42:31PM -0700, Stephen Hemminger wrote:
> * Set permanent and current address of net_failover device
> to match the primary.
>
> * Carrier should be marked off before registering device
> the net_failover device.
Sridhar, do we want to address this?
If yes,
On Mon, Jun 11, 2018 at 10:57:42AM -0700, Eric Biggers wrote:
> Hi Simon,
>
> On Mon, Jun 11, 2018 at 11:40:23AM +0200, Simon Horman wrote:
> > On Fri, Jun 08, 2018 at 09:20:37AM -0700, Eric Biggers wrote:
> > > From: Eric Biggers
> > >
> > > My recent fix for dns_resolver_preparse() printing ve
On Wed, Jun 06, 2018 at 03:21:21PM -0700, Stephen Hemminger wrote:
> > >
> > > I think you need to get rid of triggering off of the name change.
> >
> > Worth considering down the road since it's a bit of a hack but it's one
> > we won't have trouble supporting, unlike the delayed uplink.
>
>
Hi Simon,
On Mon, Jun 11, 2018 at 11:40:23AM +0200, Simon Horman wrote:
> On Fri, Jun 08, 2018 at 09:20:37AM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > My recent fix for dns_resolver_preparse() printing very long strings was
> > incomplete, as shown by syzbot which still managed t
This patch is meant to provide the basic tools needed to allow us to create
subordinate device traffic classes. The general idea here is to allow
subdividing the queues of a device into queue groups accessible through an
upper device such as a macvlan.
The idea here is to enforce the idea that an
This patch series is meant to allow support for the L2 forward offload, aka
MACVLAN offload without the need for using ndo_select_queue.
The existing solution currently requires that we use ndo_select_queue in
the transmit path if we want to associate specific Tx queues with a given
MACVLAN interf
This patch makes it so that we use the tc_to_txq mapping in the macvlan
device in order to select the Tx queue for outgoing packets.
The idea here is to try and move away from using ixgbe_select_queue and to
come up with a generic way to make this work for devices going forward. By
encoding this i
This patch adds a generic version of the ndo_select_queue functions for
either returning 0 or selecting a queue based on the processor ID. This is
generally meant to just reduce the number of functions we have to change
in the future when we have to deal with ndo_select_queue changes.
Signed-off-b
For most of these calls we can just pass NULL through to the fallback
function as the sb_dev. The only cases where we cannot are the cases where
we might be dealing with either an upper device or a driver that would
have configured things to support an sb_dev itself.
The only driver that has any s
This patch makes it so that instead of passing a void pointer as the
accel_priv we instead pass a net_device pointer as sb_dev. Making this
change allows us to pass the subordinate device through to the fallback
function eventually so that we can keep the actual code in the
ndo_select_queue call as
This patch makes it so that we do not report the traffic class or allow XPS
configuration on single queue devices. This is mostly to avoid unnecessary
complexity with changes I have planned that will allow us to reuse
the unused tc_to_txq and XPS configuration on a single queue device to
allow it t
This change makes it so that we can support the concept of subordinate
device traffic classes to the core networking code. In doing this we can
start pulling out the driver specific bits needed to support selecting a
queue based on an upper device.
The solution at is currently stands is only parti
Hi,
On the latest 4.9 stable active-passive bonding does not always
failover to the passive slave when carrier is lost on the active
slave. It seems that the issue stems from the backport of
c4adfc822bf5d8e97660b6114b5a8892530ce8cb, bonding: make speed, duplex
setting consistent with link state. T
Subash Abhinov Kasiviswanathan writes:
>> thanks, I will test it on Monday.
>>
>> Just a question for my knowledge: is the new sysfs attribute really
>> needed? I mean, is there not any other way to understand from qmi_wwan
>> without user intervention that there is the rmnet device attached?
>>
From: Jacob Keller
The function qdisc_create_dftl attempts to create a default qdisc. If
this fails, it calls qdisc_destroy when cleaning up. The qdisc_destroy
function calls the ->reset op on the qdisc.
In the case of sch_fq_codel.c, this function will panic when the qdisc
wasn't properly initi
2018-06-12 1:35 GMT+09:00 Taehee Yoo :
> In the nft_reject_br_send_v4_tcp_reset(), a ttl is set by
> the nf_reject_ip_tcphdr_put(). so, below code is unnecessary.
>
> Signed-off-by: Taehee Yoo
> ---
> net/bridge/netfilter/nft_reject_bridge.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(
Kernel panic on x86_64 machine running mainline 4.17.0 kernel while testing
selftests bpf test_tunnel.sh test caused this kernel panic.
I have noticed this kernel panic start happening from
4.17.0-rc7-next-20180529 and still happening on 4.17.0-next-20180608.
[ 213.638287] BUG: unable to handle k
/linux/commits/Andrea-Greco/arcnet-leds-Removed-leds-dependecy/20180611-222941
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/net/arcnet/com20020-io.c:3
In the nft_reject_br_send_v4_tcp_reset(), a ttl is set by
the nf_reject_ip_tcphdr_put(). so, below code is unnecessary.
Signed-off-by: Taehee Yoo
---
net/bridge/netfilter/nft_reject_bridge.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bridge/netfilter/nft_reject_bri
Hi Marcel,
On Mon, Jun 11, 2018 at 5:52 PM Marcel Holtmann wrote:
>
> Hi Ricardo,
>
> the commit message is misleading me. If I build something with ACPI or
> DT support, then modinfo will show all modalias information for ACPI and
> DT compatible strings. What else does udev/modp
/linux/commits/Andrea-Greco/arcnet-leds-Removed-leds-dependecy/20180611-222941
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin
From: Alexander Duyck
This patch moves the IPsec init function in ixgbe_sw_init. This way it is a
bit more consistent with the placement of similar initialization functions
and is placed before the reset_hw call which should allow us to clean up
any link issues that may be introduced by the fact
From: Alexander Duyck
When we were enabling macvlan interfaces we weren't correctly configuring
things until ixgbe_setup_tc was called a second time either by tweaking the
number of queues or increasing the macvlan count past 15.
The issue came down to the fact that num_rx_pools is not populated
From: Alexander Duyck
This patch fixes two issues. First we add an early test for the Tx and Rx
security block ready bits. By doing this we can avoid the need for waits or
loopback in the event that the security block is already flushed out.
Secondly we fix the boolean logic that was testing for
From: Alexander Duyck
There is no point in adding code if CONFIG_XFRM is defined that we won't
use unless CONFIG_XFRM_OFFLOAD is defined. So instead of leaving this code
floating around I am replacing the ifdef with what I believe is the correct
one so that we only include the code and variables
This series contains fixes to ixgbe IPsec and MACVLAN.
Alex provides the 5 fixes in this series, starting with fixing an issue
where num_rx_pools was not being populated until after the queues and
interrupts were reinitialized when enabling MACVLAN interfaces. Updated
to use CONFIG_XFRM_OFFLOAD i
From: Alexander Duyck
This patch addresses two issues. First it adds the correct bit definitions
for the SECTXSTAT and SECRXSTAT registers. Then it makes use of those
definitions to test for if IPsec has been disabled on the part and if so we
do not enable it.
CC: stable
Signed-off-by: Alexande
On Mon, Jun 11, 2018 at 02:02:54AM +0300, Julian Anastasov wrote:
> IPVS setups with local client and remote tunnel server need
> to create exception for the local virtual IP. What we do is to
> change PMTU from 64KB (on "lo") to 1460 in the common case.
>
> Suggested-by: Martin KaFai Lau
> Fixes
I tried to figure out if the URB-completion handler uses any locking and
stumbled here.
i2400m_pm_notifier() is called from process context. This function
invokes i2400m_fw_cache() + i2400m_fw_uncache(). Both functions do
spin_lock(&i2400m->rx_lock);
while in other places (say i2400mu_rxd
Hi Ricardo,
the commit message is misleading me. If I build something with ACPI or DT
support, then modinfo will show all modalias information for ACPI and DT
compatible strings. What else does udev/modprobe actually need? Is
something broken with the modalias export?
>>>
>
Hi Rob,
Added support to automatically configure the SCO packet routing at the
device setup. The SCO packets are used with the HSP / HFP profiles, but in
some devices (ex. CYW43438) they are routed to a PCM output by default.
This
change allows sending the vendor specific
On Sat, Jun 9, 2018 at 12:26 AM, Attila Tőkés wrote:
> Hello Rob,
>
> On Fri, Jun 8, 2018 at 8:25 PM, Rob Herring wrote:
>>
>> On Fri, Jun 8, 2018 at 10:20 AM, wrote:
>> > From: Attila Tőkés
>> >
>> > Added support to automatically configure the SCO packet routing at the
>> > device setup. The
Hi Marcel,
On Mon, Jun 11, 2018 at 5:28 PM Marcel Holtmann wrote:
>
> Hi Marcel,
>
> >> the commit message is misleading me. If I build something with ACPI or DT
> >> support, then modinfo will show all modalias information for ACPI and DT
> >> compatible strings. What else does udev/modprobe ac
Hi Marcel,
>> the commit message is misleading me. If I build something with ACPI or DT
>> support, then modinfo will show all modalias information for ACPI and DT
>> compatible strings. What else does udev/modprobe actually need? Is something
>> broken with the modalias export?
>
> The main p
On Fri, 8 Jun 2018 17:42:21 -0700
Siwei Liu wrote:
> On Fri, Jun 8, 2018 at 5:02 PM, Stephen Hemminger
> wrote:
> > On Fri, 8 Jun 2018 16:44:12 -0700
> > Siwei Liu wrote:
> >
> >> On Fri, Jun 8, 2018 at 4:18 PM, Stephen Hemminger
> >> wrote:
> >> > On Fri, 8 Jun 2018 15:25:59 -0700
> >> >
On Fri, 8 Jun 2018 15:54:38 -0700
Siwei Liu wrote:
> On Wed, Jun 6, 2018 at 2:54 PM, Samudrala, Sridhar
> wrote:
> >
> >
> > On 6/6/2018 2:24 PM, Stephen Hemminger wrote:
> >>
> >> On Wed, 6 Jun 2018 15:30:27 +0300
> >> "Michael S. Tsirkin" wrote:
> >>
> >>> On Wed, Jun 06, 2018 at 09:25:12
Hi Marcel,
On Mon, Jun 11, 2018 at 3:01 PM Marcel Holtmann wrote:
>
>
> the commit message is misleading me. If I build something with ACPI or DT
> support, then modinfo will show all modalias information for ACPI and DT
> compatible strings. What else does udev/modprobe actually need? Is someth
On Mon, 11 Jun 2018 09:16:59 +0700
Hoang Le wrote:
> @@ -33,6 +35,8 @@ static void about(struct cmdl *cmdl)
> "\n"
> "Options:\n"
> " -h, --help \t\tPrint help for last given command\n"
> + " -j, --json \t\tJson format printouts\n"
> +
Hi Subash,
2018-06-09 19:55 GMT+02:00 Subash Abhinov Kasiviswanathan
:
>> thanks, I will test it on Monday.
>>
>> Just a question for my knowledge: is the new sysfs attribute really
>> needed? I mean, is there not any other way to understand from qmi_wwan
>> without user intervention that there is
From: Andrea Greco
Add devicetree bindings for smsc com20020
Signed-off-by: Andrea Greco
---
.../devicetree/bindings/net/smsc-com20020.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
diff --git
1 - 100 of 156 matches
Mail list logo
