On Tue, Mar 13, 2018 at 11:16 PM, Roman Mashak wrote:
Makes sense :)
Acked-by: Yotam Gigi
> Signed-off-by: Roman Mashak
> ---
> tc/m_sample.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
On 3/13/18 10:20 PM, Sinan Kaya wrote:
+/* Assumes caller has executed a write barrier to order memory and device
+ * requests.
+ */
static inline void ixgbevf_write_tail(struct ixgbevf_ring *ring, u32 value)
{
- writel(value, ring->tail);
+ writel_relaxed(value, ring->tail);
}
From: Veerasenareddy Burru
Added ethtool changes to show port type as TP (Twisted Pair) for
10GBASE-T ports. Same driver and firmware works for liquidio NIC with
SFP+ ports or TP ports.
Signed-off-by: Veerasenareddy Burru
The SK_MEM_QUANTUM was changed from PAGE_SIZE to 4096.
Signed-off-by: Tonghao Zhang
---
Documentation/networking/ip-sysctl.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt
This patch moves the udp_rmem_min, udp_wmem_min
to namespace and init the udp_l3mdev_accept explicitly.
The udp_rmem_min/udp_wmem_min affect udp rx/tx queue,
with this patch namespaces can set them differently.
Signed-off-by: Tonghao Zhang
---
v2: use a common helper
On Tue, Mar 13, 2018 at 5:28 PM, Samudrala, Sridhar
wrote:
> On 3/12/2018 3:44 PM, Siwei Liu wrote:
>>
>> Apologies, still some comments going. Please see inline.
>>
>> On Thu, Mar 1, 2018 at 12:08 PM, Sridhar Samudrala
>> wrote:
>>>
>>>
On Tue, Mar 13, 2018 at 11:20:24PM -0400, Sinan Kaya wrote:
> Code includes wmb() followed by writel() in multiple places. writel()
> already has a barrier on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since
On 03/13/2018 11:35 AM, Dave Taht wrote:
> On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
> wrote:
>> During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
>> v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of
Added Konstantin in case he is in charge of administering patchwork.kernel.org?
On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote:
> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding wrote:
> > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote:
> >> On Tue,
From: Andrey Ignatov
"Post-hooks" are hooks that are called right before returning from
sys_bind. At this time IP and port are already allocated and no further
changes to `struct sock` can happen before returning from sys_bind but
BPF program has a chance to inspect the socket and
From: Andrey Ignatov
Add selftest to work with bpf_sock_addr context from
`BPF_PROG_TYPE_CGROUP_INET4_BIND` and BPF_PROG_TYPE_CGROUP_INET6_BIND`
programs.
Try to bind(2) on IP:port and apply:
* loads to make sure context can be read correctly, including narrow
loads (byte, half)
For our container management we've been using complicated and fragile setup
consisting of LD_PRELOAD wrapper intercepting bind and connect calls from
all containerized applications.
The setup involves per-container IPs, policy, etc, so traditional
network-only solutions that involve VRFs, netns,
From: Andrey Ignatov
== The problem ==
See description of the problem in the initial patch of this patch set.
== The solution ==
The patch provides much more reliable in-kernel solution for the 2nd
part of the problem: making outgoing connecttion from desired IP.
It adds new
From: Andrey Ignatov
Add selftest for BPF_CGROUP_INET4_CONNECT and BPF_CGROUP_INET6_CONNECT
attach types.
Try to connect(2) to specified IP:port and test that:
* remote IP:port pair is overridden;
* local end of connection is bound to specified IP.
All combinations of IPv4/IPv6
From: Andrey Ignatov
== The problem ==
There is a use-case when all processes inside a cgroup should use one
single IP address on a host that has multiple IP configured. Those
processes should use the IP for both ingress and egress, for TCP and UDP
traffic. So TCP/UDP servers
From: Andrey Ignatov
Refactor `bind()` code to make it ready to be called from BPF helper
function `bpf_bind()` (will be added soon). Implementation of
`inet_bind()` and `inet6_bind()` is separated into `__inet_bind()` and
`__inet6_bind()` correspondingly. These function can be used
On Wed, Mar 14, 2018 at 11:23:40AM +0800, Jason Wang wrote:
> Now we have ndo_xdp_xmit, switch to use it instead of the slow generic
> XDP TX routine. XDP_TX on TAP gets ~20% improvements from ~1.5Mpps to
> ~1.8Mpps on 2.60GHz Core(TM) i7-5600U.
>
> Signed-off-by: Jason Wang
Now we have ndo_xdp_xmit, switch to use it instead of the slow generic
XDP TX routine. XDP_TX on TAP gets ~20% improvements from ~1.5Mpps to
~1.8Mpps on 2.60GHz Core(TM) i7-5600U.
Signed-off-by: Jason Wang
---
drivers/net/tun.c | 19 ---
1 file changed, 8
Code includes wmb() followed by writel(). writel() already has a barrier
on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing the
register write.
Since code already has an explicit barrier call, changing writel() to
writel_relaxed().
Code includes wmb() followed by writel() in multiple places. writel()
already has a barrier on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing the
register write.
Since code already has an explicit barrier call, changing writel() to
Code includes wmb() followed by writel(). writel() already has a barrier
on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing the
register write.
Since code already has an explicit barrier call, changing writel() to
writel_relaxed().
Code includes wmb() followed by writel(). writel() already has a barrier
on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing the
register write.
Since code already has an explicit barrier call, changing writel() to
writel_relaxed().
Code includes wmb() followed by writel() in multiple places. writel()
already has a barrier on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing the
register write.
Since code already has an explicit barrier call, changing writel() to
Code includes wmb() followed by writel(). writel() already has a barrier
on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing the
register write.
Since code already has an explicit barrier call, changing writel() to
writel_relaxed().
Code includes wmb() followed by writel() in multiple places. writel()
already has a barrier on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing the
register write.
Since code already has an explicit barrier call, changing writel() to
Code includes wmb() followed by writel(). writel() already has a barrier
on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing the
register write.
Since code already has an explicit barrier call, changing writel() to
writel_relaxed().
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Wednesday, March 7, 2018 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com>
> Subject: [Intel-wired-lan]
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Wednesday, March 7, 2018 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com>
> Subject: [Intel-wired-lan]
>> + kfree(buf);
free tb? buf is an array.
On Wed, Mar 14, 2018 at 8:25 AM, David Miller wrote:
> From: Arnd Bergmann
> Date: Tue, 13 Mar 2018 21:58:39 +0100
>
>> After the removal of the VLA, we get a harmless warning about a large
>> stack frame:
>>
>>
--
I need your partnership to transfer $17.5 million to you and you will
take 40% of it, details of the business will be disclosed once i
receive your positive reply.
On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding wrote:
> On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote:
>> On Tue, Mar 13, 2018 at 10:17 PM, tcharding wrote:
>> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote:
>> >> tcharding
if the kernel fails duplicating 'sdata', creation of a new action fails
with -ENOMEM. However, subsequent attempts to install the same action
using the same value of 'index' will systematically fail with -ENOSPC,
and that value of 'index' will no more be usable by act_simple, until
rmmod / insmod
On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 13, 2018 at 10:17 PM, tcharding wrote:
> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote:
> >> tcharding wrote:
>
> I'm pretty much sure it depends on the original email
On Tue, 13 Mar 2018 17:53:39 +0200, Or Gerlitz wrote:
> > Starting with type 2, in our current NIC HW APIs we have to duplicate
> > these rules
> > into two rules set to HW:
> >
> > 2.1 VF rep --> uplink 0
> > 2.2 VF rep --> uplink 1
> >
> > and we do that in the driver (add/del two HW rules,
On Sun, Mar 11, 2018 at 12:12 AM, Kees Cook wrote:
>
> The problem is that it's not a "constant expression", so the compiler
> frontend still yells about it under -Wvla. I would characterize this
> mainly as a fix for "accidental VLA" or "misdetected VLA" or something
>
On 2018/03/14 6:14, Jesse Brandeburg wrote:
> which iproute2 tool shows the /proc/net/dev stats?
ip -s -s link show
--
Toshiaki Makita
> I don't think the difference between C and C++ const pointer
> conversions
I mean I don't think the difference between them was intended.
No, it's undefined behavior to write to a const variable. The `static`
and `const` on the variable both change the code generation in the
real world as permitted / encouraged by the standard. It's placed in
read-only memory. Trying to write to it will break. It's not
"implemented defined" to write
On 03/13/2018 05:35 PM, Eric Dumazet wrote:
On 03/13/2018 05:26 PM, Eric Dumazet wrote:
On 03/13/2018 05:04 PM, Alexei Starovoitov wrote:
On 3/13/18 4:27 PM, Eric Dumazet wrote:
On 03/13/2018 04:09 PM, Alexei Starovoitov wrote:
we have bpf_skb_proto_6_to_4() that was used by cilium
On 3/8/18 2:31 PM, Toke Høiland-Jørgensen wrote:
> Enable proper JSON output support for fq_codel in `tc -s qdisc` output.
>
> Signed-off-by: Toke Høiland-Jørgensen
> ---
> tc/q_fq_codel.c | 49 -
> 1 file changed, 32 insertions(+),
On 3/8/18 2:31 PM, Toke Høiland-Jørgensen wrote:
> Add missing documentation of the memory_limit fq_codel parameter and the
> ce_threshold codel and fq_codel parameters.
>
> Signed-off-by: Toke Høiland-Jørgensen
> ---
> man/man8/tc-codel.8| 10 +-
>
On 3/9/18 2:07 AM, Simon Horman wrote:
> From: Pieter Jansen van Vuuren
>
> Add matching support for distinguishing between first and later fragmented
> packets.
>
> # tc filter add dev eth0 protocol ip parent : \
> flower indev eth0 \
>
On Tue, 13 Mar 2018 17:36:23 -0700
"Samudrala, Sridhar" wrote:
> OK. looks like you want to see atleast some code shared between netvsc and
> virtio_net
> even when they are using 2 different netdev models.
> Will try to add a new file under net/core and move some
On Tue, Mar 13, 2018 at 05:28:07PM -0700, Samudrala, Sridhar wrote:
> > I am not sure if it's a good idea to leave the
> > virtio_bypass around if running into failure: the guest is not
> > migratable as the VF doesn't have a backup path,
>
> Are you talking about a failure when registering
On 3/12/2018 2:08 PM, Jiri Pirko wrote:
Mon, Mar 12, 2018 at 09:58:06PM CET, sridhar.samudr...@intel.com wrote:
On 3/12/2018 1:12 PM, Jiri Pirko wrote:
Thu, Mar 01, 2018 at 09:08:43PM CET, sridhar.samudr...@intel.com wrote:
This patch enables virtio_net to switch over to a VF datapath when a
Introduce function that initializes one TX pool. Use that to
create each pool entry in both the standard TX pool and TSO
pool arrays.
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 90 --
1 file changed, 48
On 03/13/2018 05:26 PM, Eric Dumazet wrote:
On 03/13/2018 05:04 PM, Alexei Starovoitov wrote:
On 3/13/18 4:27 PM, Eric Dumazet wrote:
On 03/13/2018 04:09 PM, Alexei Starovoitov wrote:
we have bpf_skb_proto_6_to_4() that was used by cilium for long time.
It's not clear why it's not
Remove some unused fields in the structure and include values
describing the individual buffer size and number of buffers in
a TX pool. This allows us to use these fields for TX pool buffer
accounting as opposed to using hard coded values. Finally, split
TSO buffers out and provide an additional
Update TX and TX completion routines to account for TX pool
restructuring. TX routine first chooses the pool depending
on whether a packet is GSO or not, then uses it accordingly.
For the completion routine to know which pool it needs to use,
set the most significant bit of the correlator index
Improve TX pool buffer accounting to prevent the producer
index from overruning the consumer. First, set the next free
index to an invalid value if it is in use. If next buffer
to be consumed is in use, drop the packet.
Finally, if the transmit fails for some other reason, roll
back the consumer
Introduce function that frees one TX pool. Use that to release
each pool in both the standard TX pool and TSO pool arrays.
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
Update TX pool reset routine to accommodate new TSO pool array. Introduce
a function that resets one TX pool, and use that function to initialize
each pool in both pool arrays.
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 45
This patch restructures the TX pool data structure and provides a
separate TX pool array for TSO transmissions. This is already used
in some way due to our unique DMA situation, namely that we cannot
use single DMA mappings for packet data. Previously, both buffer
arrays used the same pool entry.
On 3/12/2018 3:44 PM, Siwei Liu wrote:
Apologies, still some comments going. Please see inline.
On Thu, Mar 1, 2018 at 12:08 PM, Sridhar Samudrala
wrote:
This patch enables virtio_net to switch over to a VF datapath when a VF
netdev is present with the same MAC
On 03/13/2018 05:04 PM, Alexei Starovoitov wrote:
On 3/13/18 4:27 PM, Eric Dumazet wrote:
On 03/13/2018 04:09 PM, Alexei Starovoitov wrote:
we have bpf_skb_proto_6_to_4() that was used by cilium for long time.
It's not clear why it's not crashing there, but we cannot just
reject changing
From: Arnd Bergmann
Date: Tue, 13 Mar 2018 21:58:39 +0100
> After the removal of the VLA, we get a harmless warning about a large
> stack frame:
>
> net/core/pktgen.c: In function 'pktgen_if_write':
> net/core/pktgen.c:1710:1: error: the frame size of 1076 bytes is larger than
>
On Tue, 2018-03-13 at 18:15 -0600, Subash Abhinov Kasiviswanathan wrote:
> > Did any work actually occur on all these files in 2018?
> > $ git log --name-only --since=01-01-2018
> > drivers/net/ethernet/qualcomm/rmnet/ | \
> > grep "^drivers" | sort | uniq
> >
Did any work actually occur on all these files in 2018?
$ git log --name-only --since=01-01-2018
drivers/net/ethernet/qualcomm/rmnet/ | \
grep "^drivers" | sort | uniq
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h
On 3/13/18 4:27 PM, Eric Dumazet wrote:
On 03/13/2018 04:09 PM, Alexei Starovoitov wrote:
we have bpf_skb_proto_6_to_4() that was used by cilium for long time.
It's not clear why it's not crashing there, but we cannot just
reject changing proto in bpf programs now.
We have to fix whatever
On 03/13/2018 04:49 PM, Yonghong Song wrote:
>
>
> On 3/13/18 4:45 PM, Omar Sandoval wrote:
>> On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote:
>>> Error injection is a useful mechanism to fail arbitrary kernel
>>> functions. However, it is often hard to guarantee an error
On 3/13/18 4:45 PM, Omar Sandoval wrote:
On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote:
Error injection is a useful mechanism to fail arbitrary kernel
functions. However, it is often hard to guarantee an error propagates
appropriately to user space programs. By injecting
On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote:
> Error injection is a useful mechanism to fail arbitrary kernel
> functions. However, it is often hard to guarantee an error propagates
> appropriately to user space programs. By injecting into syscalls, we can
> return arbitrary
The driver-internal string operations are only ever used for
statistics, so remove the stringset parameters and rename them
accordingly.
Signed-off-by: Ben Hutchings
---
drivers/net/ethernet/hisilicon/hns/hnae.h | 13
The hns driver used to assume that it would only ever be asked
about ETH_SS_TEST or ETH_SS_STATS, and for any other stringset
it would claim a count of 0 but if asked for names would copy
over all the statistic names. This resulted in a potential
heap buffer overflow.
This was "fixed" some time
On Tue, 2018-03-13 at 16:50 -0600, Subash Abhinov Kasiviswanathan wrote:
> Signed-off-by: Subash Abhinov Kasiviswanathan
> ---
> drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +-
> drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 2 +-
>
On 03/13/2018 04:09 PM, Alexei Starovoitov wrote:
we have bpf_skb_proto_6_to_4() that was used by cilium for long time.
It's not clear why it's not crashing there, but we cannot just
reject changing proto in bpf programs now.
We have to fix whatever needs to be fixed in skb_segment
(if bug is
On 03/14/2018 12:09 AM, Alexei Starovoitov wrote:
> On 3/13/18 3:47 PM, Eric Dumazet wrote:
>>
>>
>> On 03/13/2018 03:37 PM, Yonghong Song wrote:
>>> Adding additional cc's:
>>> Saeed Mahameed as this is most likely mlx5 driver related.
>>> Diptanu Gon Choudhury who initially reported the
On 3/13/18 3:47 PM, Eric Dumazet wrote:
On 03/13/2018 03:37 PM, Yonghong Song wrote:
Adding additional cc's:
Saeed Mahameed as this is most likely mlx5 driver related.
Diptanu Gon Choudhury who initially reported the issue.
On 3/13/18 1:44 AM, Steffen Klassert wrote:
On Mon, Mar 12,
Ummm, if you change pkt_len to be a proper __be16, then you don't need
these
casts when passing it to ntohs().
Hi David
I have fixed this now in v2.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Device of the de-aggregated skb is correctly assigned after inspecting
the mux_id, so remove the assignment in rmnet_map_deaggregate().
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 1 -
1 file changed, 1
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c| 2 +-
This is needed to query the mux_id and flags of a rmnet device.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 30 ++
1 file changed, 30 insertions(+)
diff --git
Fix warnings which were reported when running with sparse
(make C=1 CF=-D__CHECK_ENDIAN__)
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:81:15:
warning: cast to restricted __be16
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:271:37:
warning: incorrect type in assignment (different
This series contains some minor updates for rmnet driver.
Patch 1 contains fixes for sparse warnings.
Patch 2 updates the copyright date to 2018.
Patch 3 is a cleanup in receive path.
Patch 4 has the implementation of the fill_info operation.
v1->v2: Remove the force casts since the data type is
On 03/13/2018 03:37 PM, Yonghong Song wrote:
Adding additional cc's:
Saeed Mahameed as this is most likely mlx5 driver related.
Diptanu Gon Choudhury who initially reported the issue.
On 3/13/18 1:44 AM, Steffen Klassert wrote:
On Mon, Mar 12, 2018 at 11:25:09PM -0700, Eric Dumazet
Adding additional cc's:
Saeed Mahameed as this is most likely mlx5 driver related.
Diptanu Gon Choudhury who initially reported the issue.
On 3/13/18 1:44 AM, Steffen Klassert wrote:
On Mon, Mar 12, 2018 at 11:25:09PM -0700, Eric Dumazet wrote:
On 03/12/2018 11:08 PM, Yonghong Song
On Tue, Mar 13, 2018 at 2:02 PM, Andrew Morton
wrote:
> On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote:
>
>> On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
>> wrote:
>> > On Mon, Mar 12, 2018 at 3:55 PM,
2018-03-13 20:58 GMT+01:00 Vivien Didelot :
> Hi Salvatore,
Hi Vivien,
> Salvatore Mesoraca writes:
>
>> dsa_switch's num_ports is currently fixed to DSA_MAX_PORTS. So we avoid
>> 2 VLAs[1] by using DSA_MAX_PORTS instead of
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
Changes v4 -> v5:
1. Only allow build_id lookup in non-nmi context. Added comment and
commit message to highlight this limitation.
2. Minor fix reported by kbuild test robot.
Changes v3 -> v4:
1. Add fallback when build_id lookup failed. In this case, status is set
to
test_stacktrace_build_id() is added. It accesses tracepoint urandom_read
with "dd" and "urandom_read" and gathers stack traces. Then it reads the
stack traces from the stackmap.
urandom_read is a statically link binary that reads from /dev/urandom.
test_stacktrace_build_id() calls readelf to read
There is no need for complex checking between the last consumed index
and current consumed index, a simple subtraction will do.
This also eliminates the possibility of a permanent transmit queue stall
under the following conditions:
- one CPU bursts ring->size worth of traffic (up to 256
On 03/13/2018 02:41 PM, Timofey Titovets wrote:
Hi list,
We currently upgrade our servers from 4.14.13 to 4.14.26
And get some problems with random kernel oops by:
[ 422.081094] BUG: unable to handle kernel NULL pointer dereference
at 0038
[ 422.081254] IP: tcp_push+0x42/0x110
[
On Tue, 2018-03-13 at 21:19 +0100, Alexander Zubkov wrote:
> Debian maintainer found that basic command:
> # ip route flush all
> No longer worked as expected which breaks user scripts and
> expectations. It no longer flushed all IPv4 routes.
>
> Recently behaviour of "default" prefix
On 03/13/2018 02:14 PM, Jesse Brandeburg wrote:
On Tue, 13 Mar 2018 12:17:10 -0700
Eric Dumazet wrote:
Yes, this is a recurring mistake
See commit
bf909456f6a89654cb65c01fe83a4f9b133bf978 Revert "net: hns3: Add packet
statistics of netdev"
Thanks for the pointer,
Hi list,
We currently upgrade our servers from 4.14.13 to 4.14.26
And get some problems with random kernel oops by:
[ 422.081094] BUG: unable to handle kernel NULL pointer dereference
at 0038
[ 422.081254] IP: tcp_push+0x42/0x110
[ 422.081314] PGD 0 P4D 0
[ 422.081364] Oops: 0002
Consider the situation where a macb netdev is connected through
a phydev that sits on a mii bus other than the one provided to
this particular netdev. This situation is what this patchset aims
to accomplish through the existing phy-handle optional binding.
This optional binding (as described in
Document the existence of the optional binding, directing to the
general ethernet document that describes this binding.
Signed-off-by: Brad Mouring
Reviewed-by: Florian Fainelli
---
Documentation/devicetree/bindings/net/macb.txt | 1 +
1 file changed,
The macb mii setup (mii_probe() and mii_init()) previously was
somewhat interspersed, likely a result of organic growth and hacking.
This change moves mii bus registration into mii_init and probing the
bus for devices into mii_probe.
Signed-off-by: Brad Mouring
In phy_device's general probe, this device will already be set for
phy register polling, rendering this code redundant.
Signed-off-by: Brad Mouring
Suggested-by: Andrew Lunn
Reviewed-by: Florian Fainelli
---
This optional binding (as described in the ethernet DT bindings doc)
directs the netdev to the phydev to use. This is useful for a phy
chip that has >1 phy in it, and two netdevs are using the same phy
chip (i.e. the second mac's phy lives on the first mac's MDIO bus)
The devicetree snippet would
> On Mar 12, 2018, at 3:47 PM, Song Liu wrote:
>
>
>
>> On Mar 12, 2018, at 2:31 PM, Alexei Starovoitov wrote:
>>
>> On 3/12/18 2:12 PM, Song Liu wrote:
>>>
On Mar 12, 2018, at 2:00 PM, Alexei Starovoitov wrote:
On 3/12/18
From: Alexander Duyck
Add a new driver called "pci-pf-stub" to act as a "white-list" for PF
devices that provide no other functionality other then acting as a means of
allocating a set of VFs. For now I only have one example ID provided by
Amazon in terms of devices
From: Alexander Duyck
Instead of implementing our own version of a SR-IOV configuration stub in
the nvme driver we can just reuse the existing
pci_sriov_configure_simple function.
Signed-off-by: Alexander Duyck
---
v5: Replaced call to
From: Alexander Duyck
Instead of implementing our own version of a SR-IOV configuration stub in
the ena driver we can just reuse the existing
pci_sriov_configure_simple function.
Signed-off-by: Alexander Duyck
---
v5: Replaced call to
From: Alexander Duyck
Hardware-realized virtio_pci devices can implement SR-IOV, so this
patch enables its use. The device in question is an upcoming Intel
NIC that implements both a virtio_net PF and virtio_net VFs. These
are hardware realizations of what has been
From: Alexander Duyck
This patch adds a common configuration function called
pci_sriov_configure_simple that will allow for managing VFs on devices
where the PF is not capable of managing VF resources.
Signed-off-by: Alexander Duyck
---
This series is meant to add support for SR-IOV on devices when the VFs are
not managed by the kernel. Examples of recent patches attempting to do this
include:
virto - https://patchwork.kernel.org/patch/10241225/
pci-stub - https://patchwork.kernel.org/patch/10109935/
vfio -
Signed-off-by: Roman Mashak
---
tc/m_sample.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tc/m_sample.c b/tc/m_sample.c
index ff5ee6bd1ef6..dff986f5 100644
--- a/tc/m_sample.c
+++ b/tc/m_sample.c
@@ -65,7 +65,7 @@ static int
1 - 100 of 282 matches
Mail list logo