On Sat, Jul 07, 2018 at 06:29:03PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:526674536360 Add linux-next specific files for 20180706
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=17e6396840
> kernel co
On 1/29/19 7:06 PM, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/net/can/peak_canfd/peak_pciefd_main.c:668:3: warning: this statement
> may fall
Dear Friend,
I know that this letter will come to you as surprise, I got your contact
address while I search for foreign partner to assist me in this business
transaction that is present in our favor now, My name is Mr. KARIM ZAKARI, I
am the Bill and Exchange (assistant) Manager (BOA)
With Micrel KSZ8061 PHY, the link may occasionally not come up after
Ethernet cable connect. The vendor's (Microchip, former Micrel) errata
sheet 8688A.pdf descripes the problem and possible workarounds in
detail, see below.
The batch implements workaround 1, which permanently fixes the issue.
On Mon, Feb 25, 2019 at 05:44:34PM +0200, Tariq Toukan wrote:
> From: Aya Levin
>
> Introduce 50Gbps per lane link modes and 200Gbps speed, update print
> functions and initialization functions accordingly.
> In addition, update related man page accordingly.
>
> Signed-off-by: Aya Levin
> Signe
On Mon, Feb 25, 2019 at 04:38:11PM -0800, Stephen Hemminger wrote:
> On Tue, 26 Feb 2019 00:39:54 +0530
> Leslie Monis wrote:
>
> > The current implementation of the PIE queuing discipline is according to the
> > IETF draft [http://tools.ietf.org/html/draft-pan-aqm-pie-00] and the paper
> > [PIE:
The function name tcp_do_sendmsg has been renamed. But it still
appears in __tcp_transmit_skb's comment text. This patch changes
it to tcp_sendmsg_locked.
Signed-off-by: Geliang Tang
---
net/ipv4/tcp_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_output
On Tue, Feb 26, 2019 at 08:25:41AM +0100, Heiner Kallweit wrote:
> When debugging an issue I found implausible values in state->pause.
> Reason in that state->pause isn't initialized and later only single
> bits are changed. Also the struct itself isn't initialized in
> phylink_resolve(). So better
Hi Gustavo,
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, change the following form:
>
> sizeof(*rp) + (sizeof(rp->entry[0]) * count);
>
> to :
>
Mon, Feb 25, 2019 at 08:01:32PM CET, gust...@embeddedor.com wrote:
>One of the more common cases of allocation size calculations is finding
>the size of a structure that has a zero-sized array at the end, along
>with memory for some number of elements for that array. For example:
>
>struct foo {
>
Tue, Feb 26, 2019 at 04:34:03AM CET, jakub.kicin...@netronome.com wrote:
>Instead of iterating over all devlink ports add a NDO which
>will return the devlink instance from the driver.
>
>v2: add the netdev_to_devlink() helper (Michal)
>v3: check that devlink has ops (Florian)
>v4: hold devlink_mut
2019-02-26, 11:48:54 +0800, Hangbin Liu wrote:
> Hi David,
> On Mon, Feb 25, 2019 at 07:23:33PM -0700, David Ahern wrote:
> > On 2/25/19 7:17 PM, Hangbin Liu wrote:
> > > I also thought about this issue. Currently we didn't check the ipproto in
> > > both
> > > IPv4 and IPv6. You can set icmp in i
Tue, Feb 26, 2019 at 04:34:06AM CET, jakub.kicin...@netronome.com wrote:
>When ethtool is calling into devlink compat code make sure we have
>a reference on the netdevice on which the operation was invoked.
>
>v3: move the hold/lock logic into devlink_compat_* functions (Florian)
>
>Signed-off-by:
Tue, Feb 26, 2019 at 04:34:07AM CET, jakub.kicin...@netronome.com wrote:
>Commit 76726ccb7f46 ("devlink: add flash update command") and
>commit 2d8dc5bbf4e7 ("devlink: Add support for reload")
>access devlink ops without NULL-checking. There is, however, no
>driver which would pass in NULL ops, so
Hi Matthias,
> On some systems the Bluetooth Device Address (BD_ADDR) isn't stored
> on the Bluetooth chip itself. One way to configure the address is
> through the device tree (patched in by the bootloader). The btqcomsmd
> driver is an example, it can read the address from the DT property
> 'loc
> Subject: RE: [PATCH net-next 1/4] dpaa2-eth: Use a single page per Rx buffer
>
> > Subject: Re: [PATCH net-next 1/4] dpaa2-eth: Use a single page per Rx
> > buffer
> >
> >
> > On Wed, 6 Feb 2019 15:36:33 + Ioana Ciocoi Radulescu
> > wrote:
> >
> > > > From: Ilias Apalodimas
> > > >
> > >
$subject should begin with "net: macb: "
Parshuram,
Sorry but NACK on the series.
David,
This patch series seem pretty intrusive, so I would like that you wait
for my explicit ACK before applying even next versions of it.
More comments below...
On 25/02/2019 at 18:21, Florian Fainelli wrote
On Sat, Feb 23, 2019 at 03:51:51PM -0800, Eric Dumazet wrote:
> syzbot reported a WARN_ON(!tcp_skb_pcount(skb))
> in tcp_send_loss_probe() [1]
>
> This was caused by TCP_REPAIR sent skbs that inadvertenly
> were missing a call to tcp_init_tso_segs()
>
> [1]
> WARNING: CPU: 1 PID: 0 at net/ipv4/tc
At Technical University of Munich we use MAC 802.11 TX status frames to
perform several measurements in MAC 802.11 setups.
With ath based drivers this was possible until commit d94a461d7a7df6
("ath9k: use ieee80211_tx_status_noskb where possible") as the driver
ignored the IEEE80211_TX_CTL_REQ_TX_
The csum calculation is different for IPv4/6. For VLAN packets,
tc_skb_protocol returns the VLAN protocol rather than the packet's one
(e.g. IPv4/6), so csum is not calculated. Furthermore, VLAN may not be
stripped so csum is not calculated in this case too. Calculate the
csum for those cases.
Fix
Fix the incorrect reference link to RFC 8033
Signed-off-by: Leslie Monis
---
net/sched/sch_pie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
index f8314a14a256..4c0670b6aec1 100644
--- a/net/sched/sch_pie.c
+++ b/net/sched/sch_pie
Hi Martin,
On Mon, 25 Feb 2019 at 17:49, Anand Moon wrote:
>
> hi Martin,
>
> +Bartosz Golaszewski
>
> On Mon, 25 Feb 2019 at 02:25, Martin Blumenstingl
> wrote:
> >
> > I have seen Anand's your question in [0]:
> > > only issue is I have is the each time their is random MAC address so I
> > >
On 2/23/19 1:16 AM, Rob Herring wrote:
> On Fri, Feb 22, 2019 at 09:28:04AM +0100, Christophe Roullier wrote:
>> Add properties to support all Phy config
>> PHY_MODE (MII,GMII, RMII, RGMII) and in normal, PHY wo crystal (25Mhz),
>> PHY wo crystal (50Mhz), No 125Mhz from PHY config.
>>
>> Sign
On Tue, Feb 26, 2019 at 03:53:31PM +0530, Leslie Monis wrote:
> Fix the incorrect reference link to RFC 8033
>
> Signed-off-by: Leslie Monis
> ---
> net/sched/sch_pie.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
> index f83
There have been reports of oversize UDP packets being sent to the
driver to be transmitted, causing error conditions. The issue is
likely caused by the dst of the SKB switching between 'lo' with
64K MTU and the hardware device with a smaller MTU. Patches are
being proposed by Mahesh Bandewar to
Jakub Kicinski writes:
> On Sat, 23 Feb 2019 13:11:02 +0100, Toke Høiland-Jørgensen wrote:
>> Jesper Dangaard Brouer writes:
>> > On Fri, 22 Feb 2019 13:37:34 -0800 Jakub Kicinski wrote:
>> >> On Fri, 22 Feb 2019 11:13:50 +0100, Toke Høiland-Jørgensen wrote:
>> >> > Jakub Kicinski writes:
Hi Julius,
On 26.02.19 10:40, Julius Niedworok wrote:
In order to force delivery of TX status frames for research and debugging
purposes, implement the IFF_ECHO flag for ieee80211 devices. When this flag
is set for a specific interface, IEEE80211_TX_CTL_REQ_TX_STATUS is enabled
in all packets s
Hi Anand,
On Tue, Feb 26, 2019 at 11:26 AM Anand Moon wrote:
>
> Hi Martin,
>
> On Mon, 25 Feb 2019 at 17:49, Anand Moon wrote:
> >
> > hi Martin,
> >
> > +Bartosz Golaszewski
> >
> > On Mon, 25 Feb 2019 at 02:25, Martin Blumenstingl
> > wrote:
> > >
> > > I have seen Anand's your question in
From: Eran Ben Elisha
Today, tls_sw_recvmsg is capable of using asynchronous mode to handle
application data TLS records. Moreover, it assumes that if the cipher
can be handled asynchronously, then all packets will be processed
asynchronously.
However, this assumption is not always true. Specifi
Cleanup the handling of partial records while fixing a bug where the
tls_push_pending_closed_record function is using the software tls
context instead of the hardware context.
The bug resulted in the following crash:
[ 88.791229] BUG: unable to handle kernel NULL pointer dereference at
This series fixes issues encountered in tls_device code paths,
which were introduced recently.
Additionally, this series includes a fix for tls software only receive flow,
which causes corruption of payload received by user space applications.
This series was tested using the OpenSSL integration
TLS device cannot use the sw context. This patch returns the original
tls device write space handler and moves the sw/device specific portions
to the relevant files.
Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for
performance")
Signed-off-by: Boris Pismenny
Reviewe
Currently, the receive function fails to handle records already
decrypted by the device due to the commit mentioned below.
This commit advances the TLS record sequence number and prepares the context
to handle the next record.
Fixes: fedf201e1296 ("net: tls: Refactor control message handling on r
Hi Martin,
On Tue, 26 Feb 2019 at 17:07, Martin Blumenstingl
wrote:
>
> Hi Anand,
>
> On Tue, Feb 26, 2019 at 11:26 AM Anand Moon wrote:
> >
> > Hi Martin,
> >
> > On Mon, 25 Feb 2019 at 17:49, Anand Moon wrote:
> > >
> > > hi Martin,
> > >
> > > +Bartosz Golaszewski
> > >
> > > On Mon, 25 Feb
On Tue, Feb 26, 2019 at 12:15:54AM +0800, Xin Long wrote:
> On Mon, Feb 25, 2019 at 10:08 PM Neil Horman wrote:
> >
> > On Mon, Feb 25, 2019 at 09:20:44PM +0800, Xin Long wrote:
> > > On Mon, Feb 25, 2019 at 8:47 PM Neil Horman wrote:
> > > >
> > > > On Mon, Feb 25, 2019 at 07:25:37PM +0800, Xin
> -Original Message-
> From: Boris Pismenny
> Sent: Tuesday, February 26, 2019 5:43 PM
> To: avia...@mellanox.com; davejwat...@fb.com;
> john.fastab...@gmail.com; dan...@iogearbox.net; Vakul Garg
> ; netdev@vger.kernel.org
> Cc: era...@mellanox.com; bor...@mellanox.com
> Subject: [PATCH
> -Original Message-
> From: Boris Pismenny
> Sent: Tuesday, February 26, 2019 5:43 PM
> To: avia...@mellanox.com; davejwat...@fb.com;
> john.fastab...@gmail.com; dan...@iogearbox.net; Vakul Garg
> ; netdev@vger.kernel.org
> Cc: era...@mellanox.com; bor...@mellanox.com
> Subject: [PATCH
> On Mon, 25 Feb 2019 22:49:39 +0800
> Sheng Lan wrote:
>
>> From: Sheng Lan
>> Subject: [PATCH] net: netem: fix skb length BUG_ON in __skb_to_sgvec
>>
>> It can be reproduced by following steps:
>> 1. virtio_net NIC is configured with gso/tso on
>> 2. configure nginx as http server with an
Andrea Greco wrote:
> SPUR DOWN field returns spurup instead of spurdown.
>
> Signed-off-by: Andrea Greco
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
d0480d4326e2 ath9k: debugfs: Fix SPUR-DOWN field
--
https://patchwork.kernel.org/patch/10824837/
https
YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
> drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
> variable 'acq' set but not used [-Wunused-but-set-variable]
>
> It's not used after 89ce
Hi Oliver,
> On 26.02.2019 12:04, Oliver Hartkopp wrote:
>
> Hi Julius,
>
(..)
>
> The reason for IFF_ECHO was, that the data frame which is sent onto the wire
> (by one application) is not visible to all the other applications on the same
> (local) host. Therefore a successful transmission o
On Tue, 2019-02-26 at 14:13 +0100, Julius Niedworok wrote:
>
> Thank you for the explanation - I can adjust the comment, if you like to.
>
> > So what are you getting back after you enabled IFF_ECHO on your mac80211
> > device?
> >
> > Is it just a 'status' about a sent packet, or is it the pac
On 23/02/2019 0:23, Marcelo Leitner wrote:
> On Mon, Feb 18, 2019 at 07:00:19PM +, Yossi Kuperman wrote:
>> Hello All,
>>
>> Following is a description of yet another possible approach to
>> implement connection tracking offload. We would like to hear your
>> opinion. There is the “native” way
On 25/02/2019 12:40, xiangxia.m@gmail.com wrote:
> From: Tonghao Zhang
>
> This patch is a little improvement. Simplify the parse_tc_fdb_actions().
>
> Signed-off-by: Tonghao Zhang
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 dele
Define connection bindings (external PHY connections and internal links)
for the ENETC on-chip ethernet controllers.
Signed-off-by: Claudiu Manoil
---
v3 - added this patch to the set
v4 - documented strictly the enetc node bindings, changed node type
from "pci" to "ethernet" and added compa
The LS1028A RDB board features an Atheros PHY connected over
SGMII to the ENETC PF0 (or Port0). ENETC Port1 (PF1) has no
external connection on this board, so it can be disabled for now.
Signed-off-by: Alex Marginean
Signed-off-by: Claudiu Manoil
---
v2 - added a mdio node as parent for the phy
Each ENETC PF has its own MDIO interface, the corresponding
MDIO registers are mapped in the ENETC's Port register block.
The current patch adds a driver for these PF level MDIO buses,
so that each PF can manage directly its own external link.
Signed-off-by: Alex Marginean
Signed-off-by: Claudiu
The LS1028A SoC features a PCI Integrated Endpoint Root Complex
(IERC) defining several integrated PCI devices, including the ENETC
ethernet controller integrated endpoints (IEPs). The IERC implements
ECAM (Enhanced Configuration Access Mechanism) to provide access
to the PCIe config space of the I
This is the missing part to enable PCI probing of the ENETC ethernet
ports on the LS1028A SoC and external traffic on the LS1028A RDB board.
It's one of the first items on the TODO list for the recently merged
ENETC ethernet driver.
v3: Add DT bindings doc for ENETC connections
v4: none
Claudiu M
On 2/26/2019 2:38 PM, Vakul Garg wrote:
>
>
>> -Original Message-
>> From: Boris Pismenny
>> Sent: Tuesday, February 26, 2019 5:43 PM
>> To: avia...@mellanox.com; davejwat...@fb.com;
>> john.fastab...@gmail.com; dan...@iogearbox.net; Vakul Garg
>> ; netdev@vger.kernel.org
>> Cc: era...@
On 25/02/2019 12:40, xiangxia.m@gmail.com wrote:
> From: Tonghao Zhang
>
> This patch deletes unnecessary setting of the esw_attr->parse_attr
> to parse_attr in parse_tc_fdb_actions() because it is already done
> by the mlx5e_flow_esw_attr_init() function.
>
> Signed-off-by: Tonghao Zhang
On 25/02/2019 12:40, xiangxia.m@gmail.com wrote:
> From: Tonghao Zhang
>
> The encapsulation is not supported for mlx5 VFs. When we try to
> offload that action, the -EINVAL is returned, but not -EOPNOTSUPP.
> This patch changes the returned value and ignore to confuse user.
>
> For exampl
On 25/02/2019 12:40, xiangxia.m@gmail.com wrote:
> From: Tonghao Zhang
>
> If we try to offload decapsulation actions to VFs hw, we get the log [1].
> It's not friendly, because the kind of net device is null, and we don't
> know what '0' means.
>
> [1] "mlx5_core :05:01.2 vf_0: decaps
Roopa Prabhu writes:
> From: Roopa Prabhu
>
> This patch adds extack coverage in vxlan link
> create and changelink paths. Introduces a new helper
> vxlan_nl2flags to consolidate flag attribute validation.
>
> thanks to Johannes Berg for some tips to construct the
> generic vxlan flag extack s
Hello,
syzbot found the following crash on:
HEAD commit:ff7b11aa481f net: socket: set sock->sk to NULL after calli..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=1e5cc0
kernel config: https://syzkaller.appspot.com/x/.config?x=7132344728e7ec3f
dashboa
On 25/02/2019 12:40, xiangxia.m@gmail.com wrote:
> From: Tonghao Zhang
>
> When max modify header action is zero, we return -EOPNOTSUPP
> directly. In this way, we can ignore wrong message info (e.g.
> "mlx5: parsed 0 pedit actions, can't do more").
>
> This happens when offloading pedit a
On Tue, Feb 26, 2019 at 01:45:06PM +0530, Rajasingh Thavamani wrote:
> With Micrel KSZ8061 PHY, the link may occasionally not come up after
> Ethernet cable connect. The vendor's (Microchip, former Micrel) errata
> sheet 8688A.pdf descripes the problem and possible workarounds in
> detail, see
On Tue, Feb 26, 2019 at 5:51 AM Petr Machata wrote:
>
>
> Roopa Prabhu writes:
>
> > From: Roopa Prabhu
> >
> > This patch adds extack coverage in vxlan link
> > create and changelink paths. Introduces a new helper
> > vxlan_nl2flags to consolidate flag attribute validation.
> >
> > thanks to Jo
On 2/26/2019 2:49 PM, Vakul Garg wrote:
>
>
>> -Original Message-
>> From: Boris Pismenny
>> Sent: Tuesday, February 26, 2019 5:43 PM
>> To: avia...@mellanox.com; davejwat...@fb.com;
>> john.fastab...@gmail.com; dan...@iogearbox.net; Vakul Garg
>> ; netdev@vger.kernel.org
>> Cc: era...
[ Upstream commit c91951f15978f1a0c6b65f063d30f7ea7bc6fb42 ]
In bpf/syscall.c, bpf_map_get_fd_by_id() use bpf_map_inc_not_zero() to increase
the refcount, both map->refcnt and map->usercnt. Then, if bpf_map_new_fd()
fails,
should handle map->usercnt too.
Signed-off-by: zerons
---
kernel/bpf/sy
The current implementation for UDP GRO tests is racy: the receiver
may flush the RX queue while the sending is still transmitting and
incorrectly report RX errors, with a wrong number of packet received.
Add explicit timeouts to the receiver for both connection activation
(first packet received fo
On 02/26/2019 03:15 PM, zerons wrote:
> [ Upstream commit c91951f15978f1a0c6b65f063d30f7ea7bc6fb42 ]
Thanks for the fix! What do you mean by "upstream commit" above in this context?
> In bpf/syscall.c, bpf_map_get_fd_by_id() use bpf_map_inc_not_zero() to
> increase
> the refcount, both map->refc
Hi everyone,
I would like to discuss some design flaws of AF_XDP socket (XSK) implementation
in kernel. At the moment I don't see a way to work around them without changing
the API, so I would like to make sure that I'm not missing anything and to
suggest and discuss some possible improvements tha
On Mon 25 Feb 2019 at 22:39, Cong Wang wrote:
> On Mon, Feb 25, 2019 at 8:11 AM Vlad Buslov wrote:
>>
>>
>> On Fri 22 Feb 2019 at 19:32, Cong Wang wrote:
>> >
>> > So if it is no longer RCU any more, why do you still use
>> > rcu_dereference_protected()? That is, why not just deref it as a raw
> -Original Message-
> From: Boris Pismenny
> Sent: Tuesday, February 26, 2019 5:43 PM
> To: avia...@mellanox.com; davejwat...@fb.com;
> john.fastab...@gmail.com; dan...@iogearbox.net; Vakul Garg
> ; netdev@vger.kernel.org
> Cc: era...@mellanox.com; bor...@mellanox.com
> Subject: [PATCH
On 2/26/19 22:44, Daniel Borkmann wrote:
> On 02/26/2019 03:15 PM, zerons wrote:
>> [ Upstream commit c91951f15978f1a0c6b65f063d30f7ea7bc6fb42 ]
>
> Thanks for the fix! What do you mean by "upstream commit" above in this
> context?
>
This patch is based on that commit, I thought I should mentio
> -Original Message-
> From: Boris Pismenny
> Sent: Tuesday, February 26, 2019 5:43 PM
> To: avia...@mellanox.com; davejwat...@fb.com;
> john.fastab...@gmail.com; dan...@iogearbox.net; Vakul Garg
> ; netdev@vger.kernel.org
> Cc: era...@mellanox.com; bor...@mellanox.com
> Subject: [PATCH
On 2/26/2019 4:57 PM, Vakul Garg wrote:
>
>
>> -Original Message-
>> From: Boris Pismenny
>> Sent: Tuesday, February 26, 2019 5:43 PM
>> To: avia...@mellanox.com; davejwat...@fb.com;
>> john.fastab...@gmail.com; dan...@iogearbox.net; Vakul Garg
>> ; netdev@vger.kernel.org
>> Cc: era...
On Mon 25 Feb 2019 at 22:52, Cong Wang wrote:
> On Mon, Feb 25, 2019 at 7:38 AM Vlad Buslov wrote:
>>
>> Using tcf_walker->stop flag to determine when tcf_walker->fn() was called
>> at least once is unreliable. Some classifiers set 'stop' flag on error
>> before calling walker callback, other c
On 02/26/2019 12:41 AM, Geliang Tang wrote:
> The function name tcp_do_sendmsg has been renamed. But it still
> appears in __tcp_transmit_skb's comment text. This patch changes
> it to tcp_sendmsg_locked.
>
> Signed-off-by: Geliang Tang
> ---
> net/ipv4/tcp_output.c | 2 +-
> 1 file changed,
On 02/26/2019 01:23 AM, Andrei Vagin wrote:
>
> Thank you Eric. I saw a few test fails when tcp_peek_sndq()
> returned more data than we expected. I have executed the test with this
> fix in a loop and it works without any problem. Without this fix, it
> fails after a few iteration.
>
> https:
On 02/26/2019 02:56 AM, Michael Chan wrote:
> There have been reports of oversize UDP packets being sent to the
> driver to be transmitted, causing error conditions. The issue is
> likely caused by the dst of the SKB switching between 'lo' with
> 64K MTU and the hardware device with a smaller M
On Fri, Feb 22, 2019 at 11:27:05AM -0800, Alexei Starovoitov wrote:
> On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
> >
> > Then we should still probably fix up "__probe_kernel_read()" to not
> > allow user accesses. The easiest way to do that is actually likely to
> > use the "u
On 2/26/19 2:02 AM, Marc Kleine-Budde wrote:
> On 1/29/19 7:06 PM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> This patch fixes the following warnings:
>>
>> drivers/net/can/peak_canfd/peak_pc
On 02/26/2019 05:27 AM, Alexei Starovoitov wrote:
> On 2/25/19 2:36 AM, Daniel Borkmann wrote:
>>
>> Not through the stack, but was more thinking something like low-overhead
>> kprobes-style extension for a BPF prog where such sequence would be added
>> 'inline' at beginning / exit of BPF prog invo
Function walker_check_empty() incorrectly verifies that tp pointer is not
NULL, instead of actual filter pointer. Fix conditional to check the right
pointer. Adjust filter pointer naming accordingly to other cls API
functions.
Fixes: 6676d5e416ee ("net: sched: set dedicated tcf_walker flag when tp
Comment in tdc_config.py recommends putting customizations in
tdc_config_local.py file that wasn't included in gitignore. Add the local
config file to gitignore.
Signed-off-by: Vlad Buslov
---
tools/testing/selftests/tc-testing/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools
From: Dmitry Bogdanov
Recently the maximum number of queues was increased up to 8, but
NIC was not fully configured for 8 queues. In setups with more than 4 CPU
cores parts of TX traffic gets lost if the kernel routes it to queues 4th-8th.
This patch sets a tx hw traffic mode with 8 queues.
Bug
Al Viro writes:
> On Tue, Feb 26, 2019 at 06:28:17AM +, Al Viro wrote:
[...]
>> * if after relocking we see that unix_peer(sk) now
>> is equal to other, we arrange for wakeup forwarding from other's
>> peer_wait *and* if that has (likely) succeeded we fail with -EAGAIN.
>> Huh?
This r
On Tue, 26 Feb 2019 13:50:46 +0530
Leslie Monis wrote:
> On Mon, Feb 25, 2019 at 04:38:11PM -0800, Stephen Hemminger wrote:
> > On Tue, 26 Feb 2019 00:39:54 +0530
> > Leslie Monis wrote:
> >
> > > The current implementation of the PIE queuing discipline is according to
> > > the
> > > IETF d
On 02/26/2019 05:02 AM, Sheng Lan wrote:
>
>
>
>> On Mon, 25 Feb 2019 22:49:39 +0800
>> Sheng Lan wrote:
>>
>>> From: Sheng Lan
>>> Subject: [PATCH] net: netem: fix skb length BUG_ON in __skb_to_sgvec
>>>
>>> It can be reproduced by following steps:
>>> 1. virtio_net NIC is configured with
On Tue, 26 Feb 2019 21:02:10 +0800
Sheng Lan wrote:
> > On Mon, 25 Feb 2019 22:49:39 +0800
> > Sheng Lan wrote:
> >
> >> From: Sheng Lan
> >> Subject: [PATCH] net: netem: fix skb length BUG_ON in __skb_to_sgvec
> >>
> >> It can be reproduced by following steps:
> >> 1. virtio_net NIC is conf
On 02/26/2019 07:59 AM, Stephen Hemminger wrote:
>
>
> Maybe the fix is to stop TSO fragment from overwriting by doing something
> like:
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 730bc44dbad9..5fe91d0224f6 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tc
On Tue 26 Feb 2019 at 00:15, Cong Wang wrote:
> On Mon, Feb 25, 2019 at 7:45 AM Vlad Buslov wrote:
>>
>> Function tc_dump_chain() obtains and releases block->lock on each iteration
>> of its inner loop that dumps all chains on block. Outputting chain template
>> info is fast operation so lockin
On 2/26/19 12:08 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190225:
>
on i386:
ld: net/sched/sch_pie.o: in function `pie_timer':
sch_pie.c:(.text+0x604): undefined reference to `__udivdi3'
--
~Randy
On Mon, 25 Feb 2019 at 15:53, Marc Zyngier wrote:
>
> Hi Ard,
>
> On 25/02/2019 12:45, Ard Biesheuvel wrote:
> > On Sun, 24 Feb 2019 at 15:08, Marc Zyngier wrote:
> >>
> >> For quite some time, I wondered why the PCI mwifiex device built in my
> >> Chromebook was unable to use the good old legacy
Hello Peter.
On 26.02.19 02:43, Peter Oskolkov wrote:
> Now that all users of struct inet_frag_queue have been converted
> to use 'rb_fragments', remove the unused 'fragments' field.
>
> Build with `make allyesconfig` succeeded. ip_defrag selftest passed.
>
> Signed-off-by: Peter Oskolkov
> ---
On 02/26/2019 03:58 PM, zerons wrote:
> On 2/26/19 22:44, Daniel Borkmann wrote:
>> On 02/26/2019 03:15 PM, zerons wrote:
>>> [ Upstream commit c91951f15978f1a0c6b65f063d30f7ea7bc6fb42 ]
>>
>> Thanks for the fix! What do you mean by "upstream commit" above in this
>> context?
>
> This patch is ba
From: Peter Oskolkov
Date: Mon, 25 Feb 2019 17:43:46 -0800
> Now that all users of struct inet_frag_queue have been converted
> to use 'rb_fragments', remove the unused 'fragments' field.
>
> Build with `make allyesconfig` succeeded. ip_defrag selftest passed.
>
> Signed-off-by: Peter Oskolkov
On 2/26/19 6:49 AM, Maxim Mikityanskiy wrote:
> Hi everyone,
>
> I would like to discuss some design flaws of AF_XDP socket (XSK)
> implementation
> in kernel. At the moment I don't see a way to work around them without
> changing
> the API, so I would like to make sure that I'm not missing anyt
From: Jakub Kicinski
Date: Mon, 25 Feb 2019 19:34:01 -0800
> This is a follow up to the series which added device flash
> updates via devlink. I went with the approach of adding a
> new NDO in the end. It seems to end up looking cleaner.
>
> First patch removes the option to build devlink as a m
From: David Ahern
RTA_VIA was added for MPLS as a way of specifying a gateway from a
different address family. IPv4 and IPv6 do not currently support RTA_VIA
so using it leads to routes that are not what the user intended. Catch
and fail - returning a proper error message.
MPLS on the other hand
From: David Ahern
MPLS does not support nexthops with an MPLS address family.
Specifically, it does not handle RTA_GATEWAY attribute. Make it
clear by returning an error.
Fixes: 03c0566542f4c ("mpls: Netlink commands to add, remove, and dump routes")
Signed-off-by: David Ahern
---
net/mpls/af_
From: David Ahern
IPv6 currently does not support nexthops outside of the AF_INET6 family.
Specifically, it does not handle RTA_VIA attribute. If it is passed
in a route add request, the actual route added only uses the device
which is clearly not what the user intended:
$ ip -6 ro add 2001:db
From: David Ahern
IPv4 currently does not support nexthops outside of the AF_INET family.
Specifically, it does not handle RTA_VIA attribute. If it is passed
in a route add request, the actual route added only uses the device
which is clearly not what the user intended:
$ ip ro add 172.16.1.0/
From: Roopa Prabhu
Date: Mon, 25 Feb 2019 22:03:00 -0800
> From: Roopa Prabhu
>
> This series adds extack support to changelink paths.
> In the process re-factors flag sets to a separate helper.
> Also adds some changelink testcases to rtnetlink.sh
>
> (This series was initially part of anothe
From: YueHaibing
Date: Mon, 25 Feb 2019 02:03:28 +
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function
> 'mlxsw_sp_port_get_link_ksettings':
> drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3062:5: warning:
> variable 'autoneg_st
From:
Date: Tue, 26 Feb 2019 09:23:04 +
> This patch series seem pretty intrusive, so I would like that you wait
> for my explicit ACK before applying even next versions of it.
Ok.
From: Leslie Monis
Date: Tue, 26 Feb 2019 15:53:31 +0530
> Fix the incorrect reference link to RFC 8033
>
> Signed-off-by: Leslie Monis
Applied to net-next.
From: Michael Chan
Date: Tue, 26 Feb 2019 05:56:41 -0500
> There have been reports of oversize UDP packets being sent to the
> driver to be transmitted, causing error conditions. The issue is
> likely caused by the dst of the SKB switching between 'lo' with
> 64K MTU and the hardware device with
1 - 100 of 242 matches
Mail list logo
