On 31.10.2018 09:42, Alexey Kodanev wrote:
> cb->args[2] can store the pointer to the struct fib6_walker,
> allocated in inet6_dump_fib(). On the next loop iteration in
> rtnl_dump_all(), 'memset(&cb, 0, sizeof(cb->args))' can reset
> that pointer, leaking the memory [1].
>
On the second thought w
cb->args[2] can store the pointer to the struct fib6_walker,
allocated in inet6_dump_fib(). On the next loop iteration in
rtnl_dump_all(), 'memset(&cb, 0, sizeof(cb->args))' can reset
that pointer, leaking the memory [1].
Fix it by calling cb->done, if it is set, before filling 'cb->args'
with zer
On 30.10.2018 12:04, Andre Tomt wrote:
On 30.10.2018 11:58, Andre Tomt wrote:
On 27.10.2018 23:41, Andre Tomt wrote:
On 26.10.2018 13:45, Andre Tomt wrote:
On 25.10.2018 19:38, Eric Dumazet wrote:
On 10/24/2018 12:41 PM, Andre Tomt wrote:
It eventually showed up again with mlx4, on 4.18.1
On Tue, Oct 30, 2018 at 07:23:51PM -0700, Richard Cochran wrote:
> This collection of automatic variables is getting ugly. May I ask you
> to prefix a patch that puts them into reverse Christmas tree before
> your changes? (Patch below)
Forgot the diff. Here it is...
---
diff --git a/drivers/pt
On Fri, Oct 26, 2018 at 07:13:00PM +0200, Miroslav Lichvar wrote:
> The timecounter needs to be updated at least once per ~550 seconds in
> order to avoid a 40-bit SYSTIM timestamp to be misinterpreted as an old
> timestamp.
>
> Since commit 500462a9de65 ("timers: Switch to a non-cascading wheel")
On Fri, Oct 26, 2018 at 06:27:41PM +0200, Miroslav Lichvar wrote:
> +static int igb_ptp_gettimex(struct ptp_clock_info *ptp,
> + struct ptp_system_timestamp *sts)
> +{
> + struct igb_adapter *igb = container_of(ptp, struct igb_adapter,
> +
On Fri, Oct 26, 2018 at 06:27:38PM +0200, Miroslav Lichvar wrote:
> The other patches add support for the new ioctl to the e1000e, igb,
> and ixgbe driver. Tests with few different NICs in different machines
> (and PCIe slots) show that:
> - with an I219 (e1000e) the measured delay improved from 25
On Fri, Oct 26, 2018 at 06:27:39PM +0200, Miroslav Lichvar wrote:
> diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
> index 2012551d93e0..1a04c437fd4f 100644
> --- a/drivers/ptp/ptp_chardev.c
> +++ b/drivers/ptp/ptp_chardev.c
> @@ -124,11 +124,13 @@ long ptp_ioctl(struct posix_cl
On Tue, Oct 30, 2018 at 04:45:49PM -0700, tristram...@microchip.com wrote:
> From: Tristram Ha
>
> Initialize mutex before use. Avoid kernel complaint when
> CONFIG_DEBUG_LOCK_ALLOC is enabled.
>
> Fixes: b987e98e50ab90e5 ("dsa: add DSA switch driver for Microchip KSZ9477")
> Signed-off-by: Tri
This is Mr Ubaithullah Masood from Banco Santander Bank S A Hong Kong.
I got your contact during my private search on net..Would you be
interested in a business transaction to act as the beneficiary to
claim 9.8M USD funds of my deceased client who died intestate (
Without a Will)and my bank wants
> On 10/16/2018 06:00 AM, Eric Dumazet wrote:
> > On Mon, Oct 15, 2018 at 11:30 PM Andre Tomt wrote:
> >>
> >> On 15.10.2018 17:41, Eric Dumazet wrote:
> >>> On Mon, Oct 15, 2018 at 8:15 AM Stephen Hemminger
> Something is changed between 4.17.12 and 4.18, after bisecting the
> problem
From: Tristram Ha
Initialize mutex before use. Avoid kernel complaint when
CONFIG_DEBUG_LOCK_ALLOC is enabled.
Fixes: b987e98e50ab90e5 ("dsa: add DSA switch driver for Microchip KSZ9477")
Signed-off-by: Tristram Ha
---
drivers/net/dsa/microchip/ksz_common.c | 11 ++-
1 file changed, 6
From: David Ahern
Date: Tue, 30 Oct 2018 16:06:46 -0600
> or make the table per namespace.
This will increase namespace create/destroy cost, so I'd rather not
for something like this.
This is an RFC post - not working code. I welcome your comments.
If the real device offers IPsec offload, why shouldn't the VLAN device
also offer the offload? This essentially becomes a passthru interface
to the real device by swapping out the xfrm_state's netdevice reference
before calling to
On 10/29/2018 08:31 PM, John Fastabend wrote:
> We return 0 in the case of a nonblocking socket that has no data
> available. However, this is incorrect and may confuse applications.
> After this patch we do the correct thing and return the error
> EAGAIN.
>
> Quoting return codes from recvmsg man
On 10/29/2018 10:56 PM, Yonghong Song wrote:
> On our test machine, bpf selftest test_flow_dissector.sh failed
> with the following error:
> # ./test_flow_dissector.sh
> bpffs not mounted. Mounting...
> libbpf: failed to create map (name: 'jmp_table'): Operation not permitted
> libbpf: fail
On 10/30/18 12:31 PM, David Miller wrote:
> From: Jeff Barnhill <0xeff...@gmail.com>
> Date: Tue, 30 Oct 2018 07:10:58 -0400
>
>> I originally started implementing it the way you suggested; however,
>> it seemed to complicate management of that structure because it isn't
>> currently using rcu. A
From: David Ahern
Allow ip rule dumps and flushes to filter based on ipproto, sport
and dport. Example:
$ ip ru ls ipproto udp
99: from all to 8.8.8.8 ipproto udp dport 53 lookup 1001
$ ip ru ls dport 53
99: from all to 8.8.8.8 ipproto udp dport 53 lookup 1001
Signed-off-by: David Ahern
From: David Ahern
'ip rule add' with no additional arguments just adds another rule
for the main table - which exists by default. Require at least
1 argument similar to delete.
Signed-off-by: David Ahern
---
ip/iprule.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/ip/iprule.c b/ip/
From: David Ahern
'ip ru flush' currently removes all rules with priority > 0 regardless
of any other command line arguments passed in. Update flush_rule to
call filter_nlmsg to determine if the rule should be flushed or not.
This enables rule flushing such as 'ip ru flush table 1001' and
'ip ru
> Could you check on your side that applying this on top of your patch, your
> scenario is still working?
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c
> b/drivers/net/ethernet/cadence/macb_main.c
> index 1d86b4d5645a..e1347d6d1b50 100644
> --- a/drivers/net/ethernet/cadence/macb_main.
Greg,
On Thu, Oct 18, 2018 at 03:43:48PM -0700, David Miller wrote:
> From: Christoph Paasch
> Date: Thu, 18 Oct 2018 13:38:40 -0700
>
> > Upstream commit bffa72cf7f9d ("net: sk_buff rbnode reorg") got
> > backported as commit 6b921536f170 ("net: sk_buff rbnode reorg") into the
> > v4.14.x-tree.
On Tue, Oct 30, 2018 at 11:59 AM Cong Wang wrote:
> I wonder how compiler recognizes it as "never fail" when marked with
> __must_check.
__must_check means that you can not ignore the return value of a function.
Here we do use the return value.
Also prior code was not checking skb->length so r
On Tue, Oct 30, 2018 at 11:42 AM Eric Dumazet wrote:
>
> On Tue, Oct 30, 2018 at 11:09 AM Cong Wang wrote:
>
> > At least skb_header_pointer() is marked as __must_check, I don't see
> > you check its return value here.
>
> This can not fail here.
>
> skb->length must be above 14+4 at this point.
On Mon, Oct 29, 2018 at 8:08 PM Eric Dumazet wrote:
>
>
>
> On 10/29/2018 07:41 PM, Cong Wang wrote:
> > On Mon, Oct 29, 2018 at 7:25 PM Eric Dumazet wrote:
> >>
> >>
> >>
> >> On 10/29/2018 07:21 PM, Cong Wang wrote:
> >>> On Mon, Oct 29, 2018 at 7:14 PM Eric Dumazet
> >>> wrote:
>
>
From: Cong Wang
Date: Tue, 30 Oct 2018 11:09:21 -0700
> On Tue, Oct 30, 2018 at 12:57 AM Eric Dumazet wrote:
>> -static __be32 mlx5e_get_fcs(struct sk_buff *skb)
>> +static u32 mlx5e_get_fcs(const struct sk_buff *skb)
>> {
>> - int last_frag_sz, bytes_in_prev, nr_frags;
>> - u8 *fcs
On Tue, Oct 30, 2018 at 11:09 AM Cong Wang wrote:
> At least skb_header_pointer() is marked as __must_check, I don't see
> you check its return value here.
This can not fail here.
skb->length must be above 14+4 at this point.
My compiler seems to be okay with that.
From: Jeff Barnhill <0xeff...@gmail.com>
Date: Tue, 30 Oct 2018 07:10:58 -0400
> I originally started implementing it the way you suggested; however,
> it seemed to complicate management of that structure because it isn't
> currently using rcu. Also, assuming that can be worked out, where
> would
From: Eric Dumazet
Date: Tue, 30 Oct 2018 00:18:12 -0700
> Abdul Haleem reported a build error on ppc :
>
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: `struct
> iphdr` declared inside parameter list [enabled by default]
>struct iphdr *iph)
> ^
> dri
On Tue, Oct 30, 2018 at 12:57 AM Eric Dumazet wrote:
> -static __be32 mlx5e_get_fcs(struct sk_buff *skb)
> +static u32 mlx5e_get_fcs(const struct sk_buff *skb)
> {
> - int last_frag_sz, bytes_in_prev, nr_frags;
> - u8 *fcs_p1, *fcs_p2;
> - skb_frag_t *last_frag;
> - __be32
On Tue, Oct 30, 2018 at 10:50 AM Eric Dumazet wrote:
>
>
>
> On 10/30/2018 10:32 AM, Cong Wang wrote:
>
> > Unlike Pawel's case, we don't use vlan at all, maybe this is why we see
> > it much less frequently than Pawel.
> >
> > Also, it is probably not specific to mlx5, as there is another report
On 10/30/2018 10:32 AM, Cong Wang wrote:
> Unlike Pawel's case, we don't use vlan at all, maybe this is why we see
> it much less frequently than Pawel.
>
> Also, it is probably not specific to mlx5, as there is another report which
> is probably a non-mlx5 driver.
Not sure if you provided a
On Tue, 30 Oct 2018 10:34:45 -0600
David Ahern wrote:
> A more flexible approach is to use format strings to allow users to
> customize the output order and whitespace as well. So for ss and your
> column list (winging it here):
>
> netid = %N
> state = %S
> recv Q
On Tue, Oct 30, 2018 at 7:16 AM Eric Dumazet wrote:
>
>
>
> On 10/30/2018 01:09 AM, Paweł Staszewski wrote:
> >
> >
> > W dniu 30.10.2018 o 08:29, Eric Dumazet pisze:
> >>
> >> On 10/29/2018 11:09 PM, Dimitris Michailidis wrote:
> >>
> >>> Indeed this is a bug. I would expect it to produce frequen
Extends the existing udp programs to allow checking for proper
GRO aggregation/GSO size, and run the tests via a shell script, using
a veth pair with XDP program attached to trigger the GRO code path.
rfc v2 -> rfc v3:
- add missing test program options documentation
- fix sporatic test failures
XDP support will be used by a later patch to test the GRO path
in a net namespace, leveraging the veth XDP implementation.
To avoid breaking existing setup, XDP support is conditionally
enabled and build only if llc is locally available.
rfc v2 -> rfc v3:
- move 'x' option handling here
Signed-o
And fix a couple of buglets (port option processing,
clean termination on SIGINT). This is preparatory work
for GRO tests.
rfc v2 -> rfc v3:
- use ETH_MAX_MTU
Signed-off-by: Paolo Abeni
---
tools/testing/selftests/net/udpgso_bench_rx.c | 37 +++
1 file changed, 30 insertions(+)
This is the RX counterpart of commit bec1f6f69736 ("udp: generate gso
with UDP_SEGMENT"). When UDP_GRO is enabled, such socket is also
eligible for GRO in the rx path: UDP segments directed to such socket
are assembled into a larger GSO_UDP_L4 packet.
The core UDP GRO support is enabled with setso
Run on top of veth pair, using a dummy XDP program to enable the GRO.
Signed-off-by: Paolo Abeni
---
tools/testing/selftests/net/Makefile| 1 +
tools/testing/selftests/net/udpgro_bench.sh | 92 +
2 files changed, 93 insertions(+)
create mode 100755 tools/testing/sel
The *encap_needed static keys are enabled by UDP tunnels
and several UDP encapsulations type, but they are never
turned off. This can cause unneeded overall performance
degradation for systems where such features are used
transiently.
This patch introduces complete book-keeping for such keys,
decr
So that we can re-use it at the UDP lavel in a later patch
Signed-off-by: Paolo Abeni
---
net/ipv4/ip_input.c | 73 ++---
1 file changed, 36 insertions(+), 37 deletions(-)
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 35a786c0aaa0..72250b4e
In some scenarios, the GRO engine can assemble an UDP GRO packet
that ultimately lands on a non GRO-enabled socket.
This patch tries to address the issue explicitly checking for the UDP
socket features before enqueuing the packet, and eventually segmenting
the unexpected GRO packet, as needed.
We
So that we can re-use it at the UDP lavel in the next patch
Signed-off-by: Paolo Abeni
---
net/ipv6/ip6_input.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 96577e742afd..3065226bdc57 100644
-
When UDP GRO is enabled, the UDP_GRO cmsg will carry the ingress
datagram size. User-space can use such info to compute the original
packets layout.
Signed-off-by: Paolo Abeni
---
Note: I avoided setting a bit in cmsg_flag for UDP_GRO, as that
attempt produced some uglyfication, expecially on the
This series implements GRO support for UDP sockets, as the RX counterpart
of commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").
The core functionality is implemented by the second patch, introducing a new
sockopt to enable UDP_GRO, while patch 3 implements support for passing the
segment s
On 10/30/18 10:38 AM, Stephen Hemminger wrote:
> On Tue, 30 Oct 2018 10:34:45 -0600
> David Ahern wrote:
>
>> On 10/30/18 9:05 AM, Stefano Brivio wrote:
>>> Now that we have an abstraction for columns, it's relatively easy to
>>> selectively display only some of them, and Yoann has a use case for
On Tue, 30 Oct 2018 10:34:45 -0600
David Ahern wrote:
> On 10/30/18 9:05 AM, Stefano Brivio wrote:
> > Now that we have an abstraction for columns, it's relatively easy to
> > selectively display only some of them, and Yoann has a use case for it.
> >
> > Patch 1/3 fixes a rendering issue that s
On 10/30/18 9:05 AM, Stefano Brivio wrote:
> Now that we have an abstraction for columns, it's relatively easy to
> selectively display only some of them, and Yoann has a use case for it.
>
> Patch 1/3 fixes a rendering issue that shows up only when display of
> arbitrary columns is disabled. Patc
The limit for memory locked in the kernel by a process is usually set to
64 bytes by default. This can be an issue when creating large BPF maps.
A workaround is to raise this limit for the current process before
trying to create a new BPF map. Changing the hard limit requires the
CAP_SYS_RESOURCE a
On 30/10/18 15:10, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 30 Oct 2018 14:55:01 +, Marc Zyngier wrote:
>
>>> I.e, isn't the firmware fix papering over a bug that should be fixed in
>>> Linux mvpp2 driver anyway ?
>>
>> Absolutely. Leaving this unpatched in the kernel, with a 100% chanc
Hello,
On Tue, 30 Oct 2018 14:55:01 +, Marc Zyngier wrote:
> > I.e, isn't the firmware fix papering over a bug that should be fixed in
> > Linux mvpp2 driver anyway ?
>
> Absolutely. Leaving this unpatched in the kernel, with a 100% chance of
> memory corruption is just mad.
>
> I'm prett
This will allow us to disable display of any given column.
Signed-off-by: Stefano Brivio
---
misc/ss.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index c8970438ce73..c3f61ef66258 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -1245,8 +1245,15
Now that we have an abstraction for columns, it's relatively easy to
selectively display only some of them, and Yoann has a use case for it.
Patch 1/3 fixes a rendering issue that shows up only when display of
arbitrary columns is disabled. Patch 2/3 implements the relevant option,
and patch 3/3 m
Define a secondary alignment for columns in case the next column is
hidden, this avoids awkward outputs if e.g. the local address is shown,
but not the local port.
Omit embedded delimiter in socket specifiers if the port or service field
is hidden.
Signed-off-by: Stefano Brivio
---
misc/ss.c |
The new option --columns (short: -c) allows to select columns to be
displayed. Note that this doesn't affect the order in which columns are
displayed.
Reported-by: Yoann P.
Signed-off-by: Stefano Brivio
---
man/man8/ss.8 | 5 +
misc/ss.c | 62 ++-
On 30/10/18 13:00, Thomas Petazzoni wrote:
> Hello Marcin,
>
> Thanks for the feedback.
>
> On Tue, 30 Oct 2018 13:37:37 +0100, Marcin Wojtas wrote:
>
>> You use _really_ archaic firmware, the bug you see is 99% caused by a
>> bug already fixed long time ago (cleanup all PP2 BM pools correctly
>
On 10/08/2018 11:48 AM, Oleksij Rempel wrote:
> This series adds SAE J1939 support to the current kernel v4.19-rc6.
>
> This stack has long history, starting back in 27 Apr 2011, if not
> earlier:
> https://lists.openwall.net/netdev/2011/04/27/45
>
> After major rework and testing it is a time to
On 10/30/2018 01:09 AM, Paweł Staszewski wrote:
>
>
> W dniu 30.10.2018 o 08:29, Eric Dumazet pisze:
>>
>> On 10/29/2018 11:09 PM, Dimitris Michailidis wrote:
>>
>>> Indeed this is a bug. I would expect it to produce frequent errors
>>> though as many odd-length
>>> packets would trigger it. D
The current driver supports handling two vector0 interrupts, reset and
mailbox. When the hardware reports an interrupt of another type of
interrupt source, if the driver does not process the interrupt, but
enables the interrupt, the hardware will repeatedly report the unknown
interrupt.
Therefore,
When hns3_nic_init_vector_data() fails to map ring to vector,
it should cancel the netif_napi_add() that has been successfully
done and then exits.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08
SoC")
Signed-off-by: Huazhong Tan
---
V5: Fixes comments from Joe Per
There are some functions that, when they fail to send the command,
need to return the corresponding error value to its caller.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility
Layer Support")
Fixes: 681ec3999b3d ("net: hns3: fix for vlan table lost problem when
reset
Since hclge_reset_wait() is used to wait for the hardware to complete
the reset, it is not necessary to hold the rtnl_lock during
hclge_reset_wait(). So this patch releases the lock for the duration
of hclge_reset_wait().
Fixes: 6d4fab39533f ("net: hns3: Reset net device with rtnl_lock")
Signed-of
Since hclgevf_reset_wait() is used to wait for the hardware to complete
the reset, it is not necessary to hold the rtnl_lock during
hclgevf_reset_wait(). So this patch releases the lock for the duration
of hclgevf_reset_wait().
Fixes: 6988eb2a9b77 ("net: hns3: Add support to reset the enet/ring mg
When hns3_get_ring_config()/hns3_queue_to_ring()/
hns3_get_vector_ring_chain() failed during resetting, the allocated
memory has not been freed before these three functions return. So
this patch adds error handler in these functions to fix it.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 E
It is not necessary to reset the queue in the hns3_uninit_all_ring(),
since the queue is stopped in the down operation, and will be reset
in the up operation. And the judgment of the HCLGE_STATE_RST_HANDLING
flag in the hclge_reset_tqp() is not correct, because we need to reset
tqp during pf reset,
When there is a PHY, the driver needs to complete some operations through
MDIO during reset reinitialization, so HCLGE_STATE_CMD_DISABLE is more
suitable than HCLGE_STATE_RST_HANDLING to prevent the MDIO operation from
being sent during the hardware reset.
Fixes: b50ae26c57cb ("net: hns3: never se
The spin lock of the command queue only need to be initialized once
when the driver initializes the command queue. It is not necessary to
initialize the spin lock when resetting. At the same time, the
modification of the queue member should be performed after acquiring
the lock.
Fixes: 3efb960f056
In a multi-core machine, the mailbox service and reset service
will be executed at the same time. The reset service will re-initialize
the command queue, before that, the mailbox handler can only get some
invalid messages.
The HCLGE_STATE_CMD_DISABLE flag means that the command queue is not
availa
The HEAD pointer of the hardware command queue maybe equal to the command
queue's next_to_use in the driver, so that does not belong to the invalid
HEAD pointer, since the hardware may not process the command in time,
causing the HEAD pointer to be too late to update. The variables' name
in this fu
This patch series include bugfix for the HNS3 ethernet
controller driver.
Change log:
V4->V5:
Fixes comments from Joe Perches & Sergei Shtylyov
V3->V4:
Fixes comments from Sergei Shtylyov
V2->V3:
Fixes comments from Sergei Shtylyov
V1->V2:
Fixes the compilation brea
On 29.10.2018 23:40, Tristram Ha - C24268 wrote:
>> Could you, please, tell me if the above variable was false in your case?
>>
>> bool cloned = skb_cloned(*skb) || skb_header_cloned(*skb);
>>
>> If yes, then, the proper fix would be as follows:
>>
>> diff --git a/drivers/net/ethernet/cadence/mac
Hello Marcin,
Thanks for the feedback.
On Tue, 30 Oct 2018 13:37:37 +0100, Marcin Wojtas wrote:
> You use _really_ archaic firmware, the bug you see is 99% caused by a
> bug already fixed long time ago (cleanup all PP2 BM pools correctly
> during exit boot services). Please grab the latest relea
Marcin,
On 30/10/18 12:37, Marcin Wojtas wrote:
> [Resend in UTF-8]
>
> Hi Marc,
>
> You use _really_ archaic firmware, the bug you see is 99% caused by a
Please let me fix this for you:
s/_really_ archaic/released/
> bug already fixed long time ago (cleanup all PP2 BM pools correctly
> durin
[Resend in UTF-8]
Hi Marc,
You use _really_ archaic firmware, the bug you see is 99% caused by a
bug already fixed long time ago (cleanup all PP2 BM pools correctly
during exit boot services). Please grab the latest release:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/fil
Antoine,
On 30/10/18 10:50, Antoine Tenart wrote:
> Marc,
>
> On Mon, Oct 29, 2018 at 03:05:53PM +, Marc Zyngier wrote:
>>
>> This is a follow-up on the conversation Thomas and I had last week at
>> ELC, with me ranting at the sorry state of the MVPP2 driver.
>
>> Triggering this is dead si
On Sat, Oct 27, 2018 at 06:12:06AM +, Wei Yongjun wrote:
> xfrm_output_one() does not return a error code when there is
> no dst_entry attached to the skb, it is still possible crash
> with a NULL pointer dereference in xfrm_output_resume(). Fix
> it by return error code -EHOSTUNREACH.
>
> Fix
I originally started implementing it the way you suggested; however,
it seemed to complicate management of that structure because it isn't
currently using rcu. Also, assuming that can be worked out, where
would I get the net from? Would I need to store a copy in ifcaddr6,
or is there some way to
On 30.10.2018 11:58, Andre Tomt wrote:
On 27.10.2018 23:41, Andre Tomt wrote:
On 26.10.2018 13:45, Andre Tomt wrote:
On 25.10.2018 19:38, Eric Dumazet wrote:
On 10/24/2018 12:41 PM, Andre Tomt wrote:
It eventually showed up again with mlx4, on 4.18.16 + fix and also
on 4.19. I still do no
On 27.10.2018 23:41, Andre Tomt wrote:
On 26.10.2018 13:45, Andre Tomt wrote:
On 25.10.2018 19:38, Eric Dumazet wrote:
On 10/24/2018 12:41 PM, Andre Tomt wrote:
It eventually showed up again with mlx4, on 4.18.16 + fix and also
on 4.19. I still do not have a useful packet capture.
It is
Marc,
On Mon, Oct 29, 2018 at 03:05:53PM +, Marc Zyngier wrote:
>
> This is a follow-up on the conversation Thomas and I had last week at
> ELC, with me ranting at the sorry state of the MVPP2 driver.
> Triggering this is dead simple:
> - Add a macvtap to one of the MVPP2 interfaces
> - Bri
On 2018/10/30 17:11, Sergei Shtylyov wrote:
On 10/29/2018 4:54 PM, Huazhong Tan wrote:
When hns3_nic_init_vector_data() fails to map ring to vector,
it should cancel the netif_napi_add() that has been successfully
done and then exits.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Eth
On 2018/10/30 17:09, Sergei Shtylyov wrote:
Hello!
On 10/29/2018 4:54 PM, Huazhong Tan wrote:
When hns3_get_ring_config()/hns3_queue_to_ring() failed during resetting,
the allocated memory has not been freed before hns3_get_ring_config() and
hns3_queue_to_ring() return. So this patch fixes
On 10/29/2018 4:54 PM, Huazhong Tan wrote:
When hns3_nic_init_vector_data() fails to map ring to vector,
it should cancel the netif_napi_add() that has been successfully
done and then exits.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08
SoC")
Signed-off-by: Hua
Hello Christoph Hellwig,
The patch 4167b2ad5182: "PCI: Remove NULL device handling from PCI
DMA API" from Jan 10, 2018, leads to the following static checker
warning:
drivers/net/ethernet/amd/pcnet32.c:1921 pcnet32_probe1()
warn: variable dereferenced before check 'pdev' (see line
Hello!
On 10/29/2018 4:54 PM, Huazhong Tan wrote:
When hns3_get_ring_config()/hns3_queue_to_ring() failed during resetting,
the allocated memory has not been freed before hns3_get_ring_config() and
hns3_queue_to_ring() return. So this patch fixes the buffer not freeing
problem during resetting.
W dniu 30.10.2018 o 08:29, Eric Dumazet pisze:
On 10/29/2018 11:09 PM, Dimitris Michailidis wrote:
Indeed this is a bug. I would expect it to produce frequent errors
though as many odd-length
packets would trigger it. Do you have RXFCS? Regardless, how
frequently do you see the problem?
O
As shown by Dmitris, we need to use csum_block_add() instead of csum_add()
when adding the FCS contribution to skb csum.
Before 4.18 (more exactly commit 88078d98d1bb "net: pskb_trim_rcsum()
and CHECKSUM_COMPLETE are friends"), the whole skb csum was thrown away,
so RXFCS changes were ignored.
Th
On 10/29/2018 11:09 PM, Dimitris Michailidis wrote:
>
> Indeed this is a bug. I would expect it to produce frequent errors
> though as many odd-length
> packets would trigger it. Do you have RXFCS? Regardless, how
> frequently do you see the problem?
>
Old kernels (before 88078d98d1bb) were
Abdul Haleem reported a build error on ppc :
drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: `struct
iphdr` declared inside parameter list [enabled by default]
struct iphdr *iph)
^
drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: its scope is
onl
89 matches
Mail list logo
