Two small bug fixes for ring checking and context memory allocation
that affect the new 57500 chips.
Michael Chan (2):
bnxt_en: Fix ring checking logic on 57500 chips.
bnxt_en: Fix context memory allocation.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 12
drivers/net/etherne
In bnxt_hwrm_check_pf_rings(), add the proper flag to test the NQ
resources. Without the proper flag, the firmware will change
the NQ resource allocation and remap the IRQ, causing missing
IRQs. This issue shows up when adding MQPRIO TX queues, for example.
Fixes: 36d65be9a880 ("bnxt_en: Disable
When allocating memory pages for context memory, if the last page table
should be fully populated, the current code will set nr_pages to 0 when
calling bnxt_alloc_ctx_mem_blk(). This will cause the last page table
to be completely blank and causing some RDMA failures.
Fix it by setting the last p
Am 08.01.19 um 09:41 schrieb Ben Whitten:
> The sx130x family consumes two clocks, a 32MHz clock provided by a
> connected IQ transceiver, and a 133MHz high speed clock.
>
> In the example we connect the concentrator to output 0 of a fixed clock
> providing the 133MHz high speed clock, and we conn
From: Tonghao Zhang
When we offload tc filters to hardware, hardware flows can
be updated when mac of encap destination ip is changed.
But we ignore one case, that the mac of local encap ip can
be changed too, so we should also update them.
To fix it, add route_dev in mlx5e_encap_entry struct to
Am 08.01.19 um 09:41 schrieb Ben Whitten:
> The sx125x consumes a 32MHz clock and if it is coupled with a sx130x
> concentrator may also provide a gated version of this 32MHz for the
> concentrator.
"SX125x", "SX130x", "32 MHz"
>
> In the example we connect to output 0 of "txco" clock source. Th
I have since reverted to the working LTS kernel image offered by Arch
Linux (4.19.13), but am willing to re-test / gather data additional
data on a couple lower-use time periods during the week.
After updating to Linux 4.20.0 (along with a full system update
otherwise) my BRIDGED network connecti
On Sat, Jan 12, 2019 at 6:50 AM Cong Wang wrote:
>
> On Fri, Jan 11, 2019 at 6:19 AM wrote:
> > @@ -622,17 +629,20 @@ static void mlx5e_rep_neigh_update(struct work_struct
> > *work)
> > memcpy(ha, n->ha, ETH_ALEN);
> > nud_state = n->nud_state;
> > dead = n->dead;
> > +
Am 08.01.19 um 09:41 schrieb Ben Whitten:
> The sx125x family are IQ radio transceivers from Semtech configured over
> SPI, they are typically connected to an sx130x series concentrator however
> may be connected to a host directly.
"SX125x" and "SX130x"
>
> Required properties include the radio
Hi Ben,
Am 08.01.19 um 09:41 schrieb Ben Whitten:
> Add basic documentation in YAML format for the sx130x series concentrators
> from Semtech.
> Required is; the location on the SPI bus, the reset gpio and the node for
> downstream IQ radios, typically sx125x.
>
> Signed-off-by: Ben Whitten
> --
On Fri, Jan 11, 2019 at 10:10 AM Michal Kubecek wrote:
>
> On Friday, 11 January 2019 18:09 Peter Oskolkov wrote:
> > On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters
> > wrote:
> > > Thanks for the clarification. I'm thinking about creating a draft
> > > to say no fragments less then 640 unles
From: "Gustavo A. R. Silva"
Date: Tue, 8 Jan 2019 15:27:05 -0600
> 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
Martin reported a set of filters don't work after changing
from reclassify to continue. Looking into the code, it
looks like skb protocol is not always fetched for each
iteration of the filters. But, as demonstrated by Martin,
TC actions could modify skb->protocol, for example act_vlan,
this means
From: Paolo Abeni
Date: Tue, 8 Jan 2019 18:45:05 +0100
> Matteo reported forwarding issues inside the linux bridge,
> if the enslaved interfaces use the fq qdisc.
>
> Similar to commit 8203e2d844d3 ("net: clear skb->tstamp in
> forwarding paths"), we need to clear the tstamp field in
> the brid
From: Taehee Yoo
Date: Wed, 9 Jan 2019 02:23:42 +0900
> This patches fix two bugs in the bpfilter_umh which are related in
> iptables command.
...
Series applied, thank you.
From: Jia-Ju Bai
Date: Tue, 8 Jan 2019 21:04:48 +0800
> The functions isdn_tty_tiocmset() and isdn_tty_set_termios() may be
> concurrently executed.
...
> These possible bugs are found by a static tool written by myself and
> my manual code review.
>
> To fix these possible bugs, the mutex lo
From: Jia-Ju Bai
Date: Tue, 8 Jan 2019 20:45:18 +0800
> In drivers/net/ethernet/nvidia/forcedeth.c, the functions
> nv_start_xmit() and nv_start_xmit_optimized() can be concurrently
> executed with nv_poll_controller().
>
> nv_start_xmit
> line 2321: prev_tx_ctx->skb = skb;
>
> nv_start_xmit
From: Zha Bin
Date: Tue, 8 Jan 2019 16:07:03 +0800
> The vsock core only supports 32bit CID, but the Virtio-vsock spec define
> CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as
> zero. This inconsistency causes one bug in vhost vsock driver. The
> scenarios is:
>
> 0. A ha
On 1/11/19 7:56 PM, tristram...@microchip.com wrote:
>> OK, so there are clearly restrictions to what can be written and how.
>>
>
> It is hardware bug. You need to read those high PHY registers in 32-bit and
> modify them and write them back even though they are 16-bit. The regular low
> PHY
From: wenxu
In the ip_rcv the skb go through the PREROUTING hook first,
Then jump in vrf device go through the same hook again.
When conntrack dnat work with vrf, there will be some conflict for rules.
Because the package go through the hook twice with different nf status
ip link add user1 type
zzoru writes:
>> I received 3 spam messages from this address today.
>> We can simply ignore this report.
> I already mentioned about this.
>
>> and, sorry for my encrypted mails.
>> I don't understand this failure report at all.
>>
>> I don't see the connection to copy_net_ns(). And I don't see
From: Jose Abreu
Date: Wed, 9 Jan 2019 10:05:55 +0100
> Some small fixes for stmmac targeting -net. Detailed info in commit
> log.
Series applied, thanks Jose.
This looks like it is related to some of the recent discussion in netdev
around skb->tstamp (fq) or neighbor cache
Begin forwarded message:
Date: Fri, 11 Jan 2019 22:58:45 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 202235] New: regression: physica
add document for below counters:
TcpEstabResets
TcpAttemptFails
TcpOutRsts
TcpExtTCPSACKDiscard
TcpExtTCPDSACKIgnoredOld
TcpExtTCPDSACKIgnoredNoUndo
TcpExtTCPSackShifted
TcpExtTCPSackMerged
TcpExtTCPSackShiftFallback
TcpExtTCPWantZeroWindowAdv
TcpExtTCPToZeroWindowAdv
TcpExtTCPFromZeroWindowAdv
Tcp
On Fri, Jan 11, 2019 at 6:19 AM wrote:
> @@ -622,17 +629,20 @@ static void mlx5e_rep_neigh_update(struct work_struct
> *work)
> memcpy(ha, n->ha, ETH_ALEN);
> nud_state = n->nud_state;
> dead = n->dead;
> + netdev = n->dev;
> read_unlock_bh(&n->lock);
>
>
On Thu, Jan 10, 2019 at 11:21 AM Davide Caratti wrote:
> when the tunnel_key action is replaced, the kernel forgets to release the
> dst metadata: ensure they are released by tunnel_key_init(), the same way
> it's done in tunnel_key_release().
>
> Fixes: d0f6dd8a914f4 ("net/sched: Introduce act_tu
Fixes 9b42c1f179a6, which changed the default route lookup behavior for
tunnel mode SAs in the outbound direction to use the skb mark, whereas
previously mark=0 was used if the output mark was unspecified. In
mark-based routing schemes such as Android’s, this change in default
behavior causes routi
A behavior change introduced in 9b42c1f179a6 (“xfrm: Extend the
output_mark to support input direction and masking”) results in a
change in:
1. Default outbound behavior with regards to route lookup marks, and
2. Inbound behavior for SAs used to decapsulate packets when the output
mark (as sp
On Thu, Jan 10, 2019 at 11:45 AM Martin Olsson
wrote:
>
> Why are the two filters 200 and 201 skipped when using 'continue' but
> working fine with 'reclassify'?
[...]
> In the debug-rule 999 (and on the mirror destination interface) I see
> all 400 000 untagged packets.
> I expected 40-15568-
On Fri, Jan 11, 2019 at 9:44 AM Nicolas Dichtel
wrote:
>
> Since commit cb9f1b783850, scapy (which uses an AF_PACKET socket in
> SOCK_RAW mode) is unable to send a basic icmp packet over a sit tunnel:
>
> Here is a example of the setup:
> $ ip link set ntfp2 up
> $ ip addr add 10.125.0.1/24 dev nt
From: Daniel Borkmann
Date: Fri, 11 Jan 2019 11:00:01 +0100
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Fix TCP-BPF support for correctly setting the initial window
>via TCP_BPF_IW on an active TFO sender, from Yuchung.
>
> 2) Fix
On 11.01.2019 23:33, Eric W. Biederman wrote:
> zzoru writes:
>
>> net/core: BUG in copy_net_ns() (net_namespace.c)
>
> I don't understand this failure report at all.
>
> I don't see the connection to copy_net_ns(). And I don't see how the
> suggested patch short of covering up a memory stomp
zzoru writes:
> net/core: BUG in copy_net_ns() (net_namespace.c)
I don't understand this failure report at all.
I don't see the connection to copy_net_ns(). And I don't see how the
suggested patch short of covering up a memory stomp could possibly make
a difference.
What am I missing?
> Hel
Hi Alexey,
> From: Alexey Khoroshilov [mailto:khoroshi...@ispras.ru]
> Sent: Saturday, December 22, 2018 9:55 PM
> To: Zhuangyuzeng (Yisen) ; Salil Mehta
> ; lipeng (Y)
> Cc: Alexey Khoroshilov ; David S. Miller
> ; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; ldv-proj...@linuxtesting
> On Jan 11, 2019, at 10:44 AM, Arnaldo Carvalho de Melo
> wrote:
>
> Em Thu, Jan 10, 2019 at 04:19:33PM -0800, Song Liu escreveu:
>> This patch synthesize PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT for
>> BPF programs loaded before perf-record. This is achieved by gathering
>> information
On Fri, Jan 11, 2019 at 10:34:01AM -0800, Florian Fainelli wrote:
> On 1/11/19 7:06 AM, Ido Schimmel wrote:
> > On Thu, Jan 10, 2019 at 11:32:06AM -0800, Florian Fainelli wrote:
> >> +- with VLAN filtering turned on: frames ingressing the device with a VID
> >> that is
> >> + not programmed into
> OK, so there are clearly restrictions to what can be written and how.
>
It is hardware bug. You need to read those high PHY registers in 32-bit and
modify them and write them back even though they are 16-bit. The regular low
PHY registers are not affected.
Another hardware bug with I2C acce
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Jiri Kosina
> Sent: Wednesday, January 2, 2019 11:21 AM
> To: Kirsher, Jeffrey T
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Julia Lawall
> Sent: Sunday, December 30, 2018 7:53 AM
> To: Kirsher, Jeffrey T
> Cc: intel-wired-...@lists.osuosl.org; kernel-janit...@vger.kernel.org; David
> S. Miller ; linux-ker...@
Em Thu, Jan 10, 2019 at 04:19:33PM -0800, Song Liu escreveu:
> This patch synthesize PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT for
> BPF programs loaded before perf-record. This is achieved by gathering
> information about all BPF programs via sys_bpf.
>
> Signed-off-by: Song Liu
> ---
> too
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Colin King
> Sent: Monday, January 7, 2019 2:59 PM
> To: Kirsher, Jeffrey T ; David S . Miller
> ; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org
> Cc: kernel-janit...@vger.ke
On 1/11/19 7:06 AM, Ido Schimmel wrote:
> On Thu, Jan 10, 2019 at 11:32:06AM -0800, Florian Fainelli wrote:
>> This patch provides details on the expected behavior of switchdev
>> enabled network devices when operating in a "stand alone" mode, as well
>> as when being bridge members. This clarifies
On 1/9/2019 4:33 PM, Brian Rak wrote:
On 8/31/2018 10:49 AM, Brian Rak wrote:
We've upgraded a few machines to a 4.18.3 kernel and we're running
into weird IPv6 neighbor discovery issues. Basically, the machines
stop responding to inbound IPv6 neighbor solicitation requests, which
very qui
On Friday, 11 January 2019 18:09 Peter Oskolkov wrote:
> On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters wrote:
> > Thanks for the clarification. I'm thinking about creating a draft
> > to say no fragments less then 640 unless it's the last fragment.
> > Does that work for your code going forw
net/core: BUG in copy_net_ns() (net_namespace.c)
Hello,
I've got the following error report while fuzzing the kernel with syzkaller.
On commit 1bdbe227492075d058e37cb3d400e6468d0095b5
Syzkaller hit 'WARNING in __alloc_pages_slowpath' bug.
syz-executor561 (17453) used greatest stack depth: 2505
binNgjZ2AfInN.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
Hi wenxu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[also build test ERROR on v5.0-rc1 next-20190111]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Add the TCAN4x5x SPI CAN driver. This device
uses the Bosch MCAN IP core along with a SPI
interface map. Leverage the MCAN common core
code to manage the MCAN IP.
This device has a special method to indicate a
write/read operation on the data payload.
Signed-off-by: Dan Murphy
---
drivers/net
Create a m_can platform framework that peripherial
devices can register to and use common code and register sets.
The peripherial devices may provide read/write and configuration
support of the IP.
Signed-off-by: Dan Murphy
---
drivers/net/can/m_can/m_can.c | 6 +
drivers/net/can/m_ca
All
Well it has taken me a while to get this working and ported to a provide a
m_can framework that manages the Bosch m_can stack and abstracts away devices
to use that framework.
The m_can.c is the framework that devices register to.
The device abstractions can provide read/write capability as
DT binding documentation for TI TCAN4x5x driver.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/net/can/tcan4x5x.txt | 37 +++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/can/tcan4x5x.txt
diff --git a/Documentation/devicetre
Migrate the m_can code to use the m_can_platform framework
code.
Signed-off-by: Dan Murphy
---
drivers/net/can/m_can/Kconfig | 12 +
drivers/net/can/m_can/Makefile | 4 +-
drivers/net/can/m_can/m_can.c | 759 -
drivers/net/can/m_can/m_can_plat
On Thu, Jan 10, 2019 at 11:48:13PM +, Jason Gunthorpe wrote:
> There has been some confusion since checkpatch started warning about bool
> use in structures, and people have been avoiding using it.
>
> Many people feel there is still a legitimate place for bool in structures,
> so provide some
binEdyZ3JhedZ.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
binZQ58TGMoIf.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters wrote:
>
> Hi Michal and Eric,
>
> Thanks for the clarification. I'm thinking about creating a draft to say no
> fragments less then 640 unless it's the last fragment. Does that work for
> your code going forward?
I will prepare a patchset to
Em Thu, Jan 10, 2019 at 04:19:25PM -0800, Song Liu escreveu:
> This set catches symbol for all bpf programs loaded/unloaded
> before/during/after perf-record run PERF_RECORD_KSYMBOL and
> PERF_RECORD_BPF_EVENT.
>
> PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT includes key information
> of a bpf p
On 01/11/2019 06:48 PM, Simon Horman wrote:
> EtherAVB may provide a checksum of packet data appended to packet data. In
> order to allow this checksum to be received by the host descriptor data
> needs to be enlarged by 2 bytes to accommodate the checksum.
>
> In the case of M
Hello,
syzbot found the following crash on:
HEAD commit:b19bce0335e2 net: ethernet: mediatek: fix warning in phy_s..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=168e0b9f40
kernel config: https://syzkaller.appspot.com/x/.config?x=7308e68273924137
dashboa
Hi Peter,
bpf_perf_event_open() already returns a value, but if
perf_event_output's output_begin (mostly perf_output_begin) fails,
the only way to know about that is looking before/after the rb->lost,
right?
For ring buffer users that is ok, we'll get a PERF_RECORD_LOST,
etc, but
On Fri, Jan 11, 2019 at 04:43:31PM +0100, Andrew Lunn wrote:
> > > +IGMP snooping
> > > +~
> > > +
> > > +The Linux bridge allows the configuration of IGMP snooping (compile and
> > > run
> > > +time) which must be observed by the underlying switchdev network
> > > device/hardware
> >
On Fri, Jan 11, 2019 at 06:22:12PM +0300, Sergei Shtylyov wrote:
> On 01/11/2019 04:35 PM, Simon Horman wrote:
>
> >>> EtherAVB may provide a checksum of packet data appended to packet data. In
> >>> order to allow this checksum to be received by the host descriptor data
> >>> needs to be enlarged
> > +IGMP snooping
> > +~
> > +
> > +The Linux bridge allows the configuration of IGMP snooping (compile and run
> > +time) which must be observed by the underlying switchdev network
> > device/hardware
> > +in the following way:
> > +
> > +- when IGMP snooping is turned off, multicast
On 1/10/19 10:53 PM, we...@ucloud.cn wrote:
> From: wenxu
>
> In the ip_rcv the skb go through the PREROUTING hook first,
> Then jump in vrf device go through the same hook again.
> When conntrack dnat work with vrf, there will be some conflict for rules.
> Because the package go through the hook
On 01/11/2019 04:35 PM, Simon Horman wrote:
>>> EtherAVB may provide a checksum of packet data appended to packet data. In
>>> order to allow this checksum to be received by the host descriptor data
>>> needs to be enlarged by 2 bytes to accommodate the checksum.
>>>
>>> In the case of MTU-sized p
On Fri, Jan 11, 2019 at 09:12:57AM +0100, Daniel Borkmann wrote:
> Hi Kris,
>
> On 01/11/2019 06:08 AM, Kris Van Hees wrote:
> > Maybe I am missing something trivial here, but it looks to me that there is
> > a leak of htab elements in htab_map_update_elem when you are updating an
> > existing ele
On 2018-12-03 14:40, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li Please rebase this patch
> onto the mt76 branch of
https://github.com/nbd168/wireless
Thanks,
- Felix
Both gue_err() and gue6_err() incorrectly assume
linear skbs. Fix them to use pskb_may_pull().
BUG: KMSAN: uninit-value in gue6_err+0x475/0xc40 net/ipv6/fou6.c:101
CPU: 0 PID: 18083 Comm: syz-executor1 Not tainted 5.0.0-rc1+ #7
Hardware name: Google Google Compute Engine/Google Compute Engine, BIO
On Thu, Jan 10, 2019 at 11:32:06AM -0800, Florian Fainelli wrote:
> This patch provides details on the expected behavior of switchdev
> enabled network devices when operating in a "stand alone" mode, as well
> as when being bridge members. This clarifies a number of things that
> recently came up d
On Wed, Jan 02, 2019 at 02:47:25PM +0530, Vinod Koul wrote:
> Some controllers require that phy delay should be disabled. So add
If the MAC requires it, then the compatible string should imply this. If
it depends on the PHY, then okay.
> optional properties rx-disable-delay and tx-disable-delay
Since commit cb9f1b783850, scapy (which uses an AF_PACKET socket in
SOCK_RAW mode) is unable to send a basic icmp packet over a sit tunnel:
Here is a example of the setup:
$ ip link set ntfp2 up
$ ip addr add 10.125.0.1/24 dev ntfp2
$ ip tunnel add tun1 mode sit ttl 64 local 10.125.0.1 remote 10.1
On Fri, 11 Jan 2019 06:27:35 -0800
Eric Dumazet wrote:
> Both gue_err() and gue6_err() incorrectly assume
> linear skbs. Fix them to use pskb_may_pull().
>
> BUG: KMSAN: uninit-value in gue6_err+0x475/0xc40 net/ipv6/fou6.c:101
> CPU: 0 PID: 18083 Comm: syz-executor1 Not tainted 5.0.0-rc1+ #7
>
>
On Fri, Jan 11, 2019 at 6:20 AM Eric Dumazet wrote:
>
> On Fri, Jan 11, 2019 at 6:15 AM Stefano Brivio wrote:
> >
> > On Fri, 11 Jan 2019 04:55:52 -0800
> > Eric Dumazet wrote:
> >
> > > Both gue_err() and gue6_err() incorrectly assume
> > > linear skbs. Fix them to use pskb_may_pull().
> >
> >
> > Hi Camelia
> >
> > A NULL features is a driver bug. So i would prefer to solve this
> > differently.
> >
> > Please make phy_driver_register() do a WARN_ON(!new_driver->features)
> > and return -EINVAL.
>
> I wasn't aware that features are mandatory. I'll make the change.
It was not origiona
On Friday, 11 January 2019 14:26 Timothy Winters wrote:
> Hi Eric,
>
> So I understand correctly the attack that you are trying to prevent is
> many small fragments from different IPs?
>
> The 6MAN working group has had some discussion about this topic, if
> you want read some IPv6 networking pro
On Fri, Jan 11, 2019 at 6:15 AM Stefano Brivio wrote:
>
> On Fri, 11 Jan 2019 04:55:52 -0800
> Eric Dumazet wrote:
>
> > Both gue_err() and gue6_err() incorrectly assume
> > linear skbs. Fix them to use pskb_may_pull().
>
> Thanks for fixing this! I stupidly didn't suspect we could get
> non-line
On Fri, 11 Jan 2019 04:55:52 -0800
Eric Dumazet wrote:
> Both gue_err() and gue6_err() incorrectly assume
> linear skbs. Fix them to use pskb_may_pull().
Thanks for fixing this! I stupidly didn't suspect we could get
non-linear skbs there. Just two things:
> +++ b/net/ipv4/fou.c
> @@ -1020,10 +
> -Original Message-
> From: Andrew Lunn
> Sent: Friday, January 11, 2019 15:38
> To: Camelia Alexandra Groza
> Cc: f.faine...@gmail.com; hkallwe...@gmail.com; da...@davemloft.net;
> o...@buserror.net; netdev@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH net] net: ph
On Fri, Jan 11, 2019 at 5:26 AM Timothy Winters wrote:
>
> Hi Eric,
>
> So I understand correctly the attack that you are trying to prevent is many
> small fragments from different IPs?
No... Please look for CVE-2018-5391
This has been one of the most discussed topic in 2018
https://access.re
After commit 1c25324caf82 ("net/sched: act_tunnel_key: Don't dump dst port
if it wasn't set"), act_tunnel_key doesn't dump anymore the destination
port, unless it was explicitly configured. This caused systematic failures
in the following TDC test case:
7a88 - Add tunnel_key action with cookie pa
On Fri, Jan 11, 2019 at 07:27:40AM +0100, Frank Wunderlich wrote:
> Should i make v3 with all tags or me as author?
Hi Franks
The code is already merged. So the patch cannot be updated.
Heiner did the right thing, posting to the list. So it is document,
even if it is not in the ideal location. I
> > adding a IFF_VETH just for this seems like an overkill. especially
> > when there are other ways to indicate a virtual device type like
> > rtnetlink kind.
> > Also, its best to keep such checks local to veth, maybe with something
> > along the lines of what Andrew suggests above.
>
> Andrew:
On Fri, Jan 11, 2019 at 01:56:46PM +0200, Camelia Groza wrote:
> Since phy driver features became a link_mode bitmap, phy drivers that
> don't have a list of features configured will cause the kernel to crash
> when probed.
Hi Camelia
A NULL features is a driver bug. So i would prefer to solve th
On Thu, Jan 10, 2019 at 06:52:51PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 01/10/2019 05:02 PM, Simon Horman wrote:
>
> > EtherAVB may provide a checksum of packet data appended to packet data. In
> > order to allow this checksum to be received by the host descriptor data
> > needs to be en
On 11/01/19 00:31, Cong Wang wrote:
> I don't follow this question. The code you quoted from
> fl_init_dissector() is correct, as it merely stores the offsets of ipv4/ipv6
> fields. If somewhere we use it without checking control.addr_type,
> then it is a bug there.
My point is that it shouldn't st
Den fre 11 jan. 2019 kl 05:23 skrev Toshiaki Makita
:
>
> On 2019/01/10 22:26, Fredrik Gustavsson wrote:
> > commit affede4a779420bd8510ab937251a3796d3228df
> > Author: Fredrik Gustavsson
> > Date: Tue Jan 8 11:21:39 2019 +0100
> >
> > veth: Do not drop packets larger then the mtu set on the rec
On Fri, Jan 11, 2019 at 4:52 AM Michal Kubecek wrote:
>
> On Fri, Jan 11, 2019 at 04:27:24AM -0800, Eric Dumazet wrote:
> > On Fri, Jan 11, 2019 at 4:21 AM Michal Kubecek wrote:
> > >
> > > On Fri, Jan 11, 2019 at 02:57:39AM -0800, Eric Dumazet wrote:
> > > > On 01/10/2019 02:22 PM, Florian Westp
Den tors 10 jan. 2019 kl 16:39 skrev Roopa Prabhu :
>
> On Thu, Jan 10, 2019 at 6:21 AM Andrew Lunn wrote:
> >
> > On Thu, Jan 10, 2019 at 02:26:55PM +0100, Fredrik Gustavsson wrote:
> > > commit affede4a779420bd8510ab937251a3796d3228df
> > > Author: Fredrik Gustavsson
> > > Date: Tue Jan 8 11:
Both gue_err() and gue6_err() incorrectly assume
linear skbs. Fix them to use pskb_may_pull().
BUG: KMSAN: uninit-value in gue6_err+0x475/0xc40 net/ipv6/fou6.c:101
CPU: 0 PID: 18083 Comm: syz-executor1 Not tainted 5.0.0-rc1+ #7
Hardware name: Google Google Compute Engine/Google Compute Engine, BIO
On Fri, Jan 11, 2019 at 04:27:24AM -0800, Eric Dumazet wrote:
> On Fri, Jan 11, 2019 at 4:21 AM Michal Kubecek wrote:
> >
> > On Fri, Jan 11, 2019 at 02:57:39AM -0800, Eric Dumazet wrote:
> > > On 01/10/2019 02:22 PM, Florian Westphal wrote:
> > > > Tom Herbert wrote:
> > > >> I couldn't find any
From: Tonghao Zhang
When we offload tc filters to hardware, hardware flows can
be updated when mac of encap destination ip is changed.
But we ignore one case, that the mac of local encap ip can
be changed too, so we should also update them.
To fix it, add route_dev in mlx5e_encap_entry struct to
Wolfgang
On 1/11/19 2:27 AM, Wolfgang Grandegger wrote:
> Hello Dan,
>
> Am 10.01.19 um 13:53 schrieb Dan Murphy:
>> Wolfgang
>>
>> On 1/10/19 1:44 AM, Wolfgang Grandegger wrote:
>>> Hello Dan,
>>>
>>> sorry for my late response on that topic...
>>>
>>> Am 09.01.19 um 21:58 schrieb Dan Murphy:
>>
On Fri, Jan 11, 2019 at 4:21 AM Michal Kubecek wrote:
>
> On Fri, Jan 11, 2019 at 02:57:39AM -0800, Eric Dumazet wrote:
> > On 01/10/2019 02:22 PM, Florian Westphal wrote:
> > > Tom Herbert wrote:
> > >> I couldn't find any mention of the advisory in the commit logs or
> > >> netdev discussion, a
On Fri, Jan 11, 2019 at 02:57:39AM -0800, Eric Dumazet wrote:
> On 01/10/2019 02:22 PM, Florian Westphal wrote:
> > Tom Herbert wrote:
> >> I couldn't find any mention of the advisory in the commit logs or
> >> netdev discussion, and apparently there's no protocol requirement that
> >> intermediat
Since phy driver features became a link_mode bitmap, phy drivers that
don't have a list of features configured will cause the kernel to crash
when probed.
Fixes: 719655a14971 ("net: phy: Replace phy driver features u32 with link_mode
bitmap")
Reported-by: Scott Wood
Signed-off-by: Camelia Groza
On 11/01/19 2:57 AM, Tony Lindgren wrote:
> * Heiner Kallweit [190110 19:41]:
>> On 10.01.2019 20:24, Florian Fainelli wrote:
>>> On 1/10/19 11:22 AM, Heiner Kallweit wrote:
So far genphy_soft_reset was used automatically if the PHY driver
didn't implement the soft_reset callback. This c
Commit cbffaf7aa09e ("can: flexcan: Always use last mailbox for TX")
introduced a loop letting i run up to (including) ARRAY_SIZE(regs->mb)
and in the body accessed regs->mb[i] which is an out-of-bounds array
access that then resulted in an access to an reserved register area.
Later this was chang
The loop body uses regs->mb[i], so i should not ensured to be smaller
than ARRAY_SIZE(regs->mb).
This change fixes a backtrace during boot on an i.MX25 based machine:
[ 10.093464] Unhandled fault: external abort on non-linefetch (0x808) at
0xc89f4480
[ 10.101096] pgd = (ptrval)
[ 10.103830
On 01/10/2019 02:22 PM, Florian Westphal wrote:
> Tom Herbert wrote:
>> I couldn't find any mention of the advisory in the commit logs or
>> netdev discussion, and apparently there's no protocol requirement that
>> intermediate fragements need to be at least minimal MTU. Maybe this
>> patch sho
On Fri, Jan 11, 2019 at 07:26:09AM +0300, Konstantin Khlebnikov wrote:
> On Thu, Jan 10, 2019 at 11:45 PM Cong Wang wrote:
> > On Tue, Jan 8, 2019 at 1:30 AM Konstantin Khlebnikov
> > wrote:
> > > @@ -443,12 +444,14 @@ static struct neigh_hash_table
> > > *neigh_hash_alloc(unsigned int shift)
>
1 - 100 of 116 matches
Mail list logo
