On Mon, Oct 26, 2020 at 11:18:16AM +0800, Yunsheng Lin wrote:
> On 2020/10/23 19:22, Dan Carpenter wrote:
> > Smatch complains that "ret" might be uninitialized if we don't enter
> > the loop. We do always enter the loop so it's a false positive, but
> > it's cleaner to just return a literal zero
Hi,
Thanks for the review. Will send a new patch with the fixes soon.
Fujiwara
On Mon, Oct 26, 2020 at 6:05 AM Jakub Kicinski wrote:
>
> On Sat, 24 Oct 2020 15:42:33 + Masahiro Fujiwara wrote:
> > *_pdp_find() from gtp_encap_recv() would trigger a crash when a peer
> > sends GTP packet
From: Leon Romanovsky
The tcf_block_unbind() expects that the caller will take block->cb_lock
before calling it, however the code took RTNL lock instead. This causes
to the following kernel panic.
WARNING: CPU: 1 PID: 13524 at net/sched/cls_api.c:1488
tcf_block_unbind+0x2db/0x420
Modules link
Returning 0 is no more an error case with MV88E6393 family
which has serdes lane numbers 0, 9 or 10.
So with this change .serdes_get_lane will return lane number
or error (-ENODEV).
Signed-off-by: Pavana Sharma
---
drivers/net/dsa/mv88e6xxx/chip.c | 28 +--
drivers/net/dsa/mv88e6xxx/ch
On Thu, Oct 22, 2020 at 4:47 PM David Laight wrote:
>
> From: Xin Long
> > Sent: 22 October 2020 04:13
> ...
> > I was thinking that by leaving it to 9899 by default users don't need to
> > know the port when want to use it, and yet I didn't want to add another
> > sysctl member. :D
>
> Could you
Signed-off-by: Pavana Sharma
---
include/linux/phy.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3a09d2bf69ea..9de7c57cfd38 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -107,6 +107,7 @@ typedef enum {
PHY_INTERFAC
The Marvell 88E6393X device is a single-chip integration of a 11-port
Ethernet switch with eight integrated Gigabit Ethernet (GbE) transceivers
and three 10-Gigabit interfaces.
This patch adds functionalities specific to mv88e6393x family (88E6393X,
88E6193X and 88E6191X)
Signed-off-by: Pavana Sh
Hi,
Thanks for the review.
Following is the updated patchset.
The 6393X family has MV88E6191X, MV88E6193X and MV88E6393X products listed in
Gigabit Ethernet and Gigabit 10G+ Ethernet categories. There are no 6393
devices
(without X) but there is 6191 device (without X)from a different family.
Hi Christoph,
> From: Jakub Kicinski
> Sent: Saturday, October 24, 2020 11:45 PM
>
> CC: rdma, looks like rdma from the stack trace
>
> On Fri, 23 Oct 2020 20:07:17 -0700 syzbot wrote:
> > syzbot has found a reproducer for the following issue on:
> >
> > HEAD commit:3cb12d27 Merge tag 'net-
Vitaly Chikunov writes:
> Adding netdev and PowerPC maintainers JFYI.
Thanks.
> On Sat, Oct 24, 2020 at 11:23:19AM +0300, Dmitry V. Levin wrote:
>> Hi,
>>
>> On Sat, Oct 24, 2020 at 02:06:41AM +0300, Vitaly Chikunov wrote:
>> > Hi,
>> >
>> > Commit f143c11bb7b9 ("tools: bpf: Use local copy of
bnxt_open_nic() is called during configuration changes that require
the NIC to be closed and then opened. This call is protected by
rtnl_lock. Firmware reset can be happening at the same time. Only
critical portions of the entire firmware reset sequence are protected
by the rtnl_lock. It is pos
From: Vasundhara Volam
As part of the commit b148bb238c02
("bnxt_en: Fix possible crash in bnxt_fw_reset_task()."),
cancel_delayed_work_sync() is called only for VFs to fix a possible
crash by cancelling any pending delayed work items. It was assumed
by mistake that the flush_workqueue() call on
From: Vasundhara Volam
When a PCIe fatal error occurs, the internal latched BAR addresses
in the chip get reset even though the BAR register values in config
space are retained.
pci_restore_state() will not rewrite the BAR addresses if the
BAR address values are valid, causing the chip's interna
These 5 bug fixes are all related to the firmware reset or AER recovery.
2 patches fix the cleanup logic for the workqueue used to handle firmware
reset and recovery. 1 patch ensures that the chip will have the proper
BAR addresses latched after fatal AER recovery. 1 patch fixes the
open path to c
From: Vasundhara Volam
A recent patch has moved the workqueue cleanup logic before
calling unregister_netdev() in bnxt_remove_one(). This caused a
regression because the workqueue can be restarted if the device is
still open. Workqueue cleanup must be done after unregister_netdev().
The workque
From: Vasundhara Volam
In the AER or firmware reset flow, if we are in fatal error state or
if pci_channel_offline() is true, we don't send any commands to the
firmware because the commands will likely not reach the firmware and
most commands don't matter much because the firmware is likely to be
> Subject: [RFC PATCH 3/6] fpga: dfl: add an API to get the base device for dfl
> device
>
> This patch adds an API for dfl devices to find which physical device
> owns the DFL.
>
> This patch makes preparation for supporting DFL Ether Group private
> feature driver. It uses this information to d
> Subject: [RFC PATCH 2/6] fpga: dfl: export network configuration info for DFL
> based FPGA
>
> This patch makes preparation for supporting DFL Ether Group private
> feature driver, which reads bitstream_id.vendor_net_cfg field to
> determin the interconnection of network components on FPGA devic
On 2020/10/23 19:22, Dan Carpenter wrote:
> Smatch complains that "ret" might be uninitialized if we don't enter
> the loop. We do always enter the loop so it's a false positive, but
> it's cleaner to just return a literal zero and that silences the
> warning as well.
Thanks for the clean up. Min
On 2020/10/23 下午11:34, Michael S. Tsirkin wrote:
On Fri, Oct 23, 2020 at 03:08:53PM +0300, Dan Carpenter wrote:
The copy_to/from_user() functions return the number of bytes which we
weren't able to copy but the ioctl should return -EFAULT if they fail.
Fixes: a127c5bbb6a8 ("vhost-vdpa: fix ba
On 10/25/20 3:43 PM, Jakub Kicinski wrote:
> On Fri, 23 Oct 2020 20:48:16 +0200 Guillaume Nault wrote:
>> On Fri, Oct 23, 2020 at 11:23:04AM -0700, Jakub Kicinski wrote:
>>> On Fri, 23 Oct 2020 18:19:43 +0200 Guillaume Nault wrote:
Since commit b7c24497baea ("mpls: load mpls_gso after mpls_i
On 2020/10/23 下午6:40, Zhu Lingshan wrote:
LKP considered variable 'ret' in vhost_vdpa_setup_vq_irq() as
a unused variable, so suggest we remove it. Actually it stores
return value of irq_bypass_register_producer(), but we did not
check it, we should handle the failure case.
This commit will pr
> On Fri, 2020-10-23 at 13:16 +0300, Vasily Averin wrote:
> > On 10/23/20 1:01 PM, Zhang Qilong wrote:
> > > The normal path has only one slash.
> >
> > it is not normal path
> > this string is used to calculate number of symbols in
> > "net/%s/neigh/%s" used below
>
> Then probably better would b
Using size of "net//neigh/" is not clear, the use
of stitching("net/" + /neigh") should be clearer.
Signed-off-by: Zhang Qilong
---
net/core/neighbour.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 8e39e28b0a8d..047
Commit ed42989eab57 ("fix the skb_unshare() in tipc_buf_append()")
replaced skb_unshare() with skb_copy() to not reduce the data reference
counter of the original skb intentionally. This is not the correct
way to handle the cloned skb because it causes memory leak in 2
following cases:
1/ Sending
Trivial fix to use func skb_is_gso in place of
test for skb_shinfo(skb)->gso_size.
Signed-off-by: Yi Li
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 9499a414d67e..55f66e108059 100644
--- a/net/core/dev.c
+++ b/net/co
Adding stable.
> On Oct 21, 2020, at 1:08 PM, Saeed Mirzamohammadi
> wrote:
>
> Attached the syzkaller C repro.
>
> Tested-by: Saeed Mirzamohammadi
>
>> On Oct 20, 2020, at 9:45 AM, Saeed Mirzamohammadi
>> wrote:
>>
>> Thanks! Yes, that looks good to me.
>>
>> Saeed
>>
>>> On Oct 20, 2
On 10/23/20 9:24 AM, Stephen Hemminger wrote:
>
>
> Begin forwarded message:
>
> Date: Fri, 23 Oct 2020 03:38:54 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: step...@networkplumber.org
> Subject: [Bug 209823] New: system panic since commit
> d18d22ce8f62839365c984b1df474d3975ed4eb2
On 10/25/20 9:13 AM, Toke Høiland-Jørgensen wrote:
> David Ahern writes:
>
>> On 10/22/20 9:38 PM, Hangbin Liu wrote:
>>> Note: ip/ipvrf.c is not convert to use libbpf as it only encodes a few
>>> instructions and load directly.
>>
>> for completeness, libbpf should be able to load a program from
On Fri, 23 Oct 2020 16:17:54 -0700 Hemant Kumar wrote:
> +UCI driver enables userspace clients to communicate to external MHI devices
> +like modem and WLAN. UCI driver probe creates standard character device file
> +nodes for userspace clients to perform open, read, write, poll and release
> file
On Fri, 23 Oct 2020 20:48:16 +0200 Guillaume Nault wrote:
> On Fri, Oct 23, 2020 at 11:23:04AM -0700, Jakub Kicinski wrote:
> > On Fri, 23 Oct 2020 18:19:43 +0200 Guillaume Nault wrote:
> > > Since commit b7c24497baea ("mpls: load mpls_gso after mpls_iptunnel"),
> > > mpls_iptunnel.ko has a softd
On Sat, 24 Oct 2020 13:18:09 +0200 Parshuram Thombare wrote:
> This patch adds support for 10GBASE-R interface to the linux driver for
> Cadence's ethernet controller.
> This controller has separate MAC's and PCS'es for low and high speed paths.
> High speed PCS supports 100M, 1G, 2.5G, 5G and 10G
On Mon, 24 Aug 2020 19:51:07 +0200
Johannes Berg wrote:
> This prints out the data from the given nested attribute
> to the given FILE pointer, interpreting the firmware that
> the kernel has for showing netlink policies.
>
> Signed-off-by: Johannes Berg
This patch causes warnings from iproute
On 10/19/20 5:47 AM, Zahari Doychev wrote:
> Currently the icmp and arp prsing functions are called with inccorect
> ethtype in case of vlan or cvlan filter options. In this case either
> cvlan_ethtype or vlan_ethtype has to be used.
>
> Signed-off-by: Zahari Doychev
> ---
> tc/f_flower.c | 43 +
On 10/22/20 3:11 AM, Guillaume Nault wrote:
> Commit 02a261b5ba1c ("m_mpls: add mac_push action") added a matches()
> test for the "mac_push" string before the test for "modify".
> This changes the previous behaviour as 'action m' used to match
> "modify" while it now matches "mac_push".
>
> Rever
On Sat, 24 Oct 2020 15:42:33 + Masahiro Fujiwara wrote:
> *_pdp_find() from gtp_encap_recv() would trigger a crash when a peer
> sends GTP packets while creating new GTP device.
>
> RIP: 0010:gtp1_pdp_find.isra.0+0x68/0x90 [gtp]
>
> Call Trace:
>
> gtp_encap_recv+0xc2/0x2e0 [gtp]
> ? gtp1
Correct skb refcount in alloc_ctrl_skb(), causing skb memleak
when chtls_send_abort() called with NULL skb.
Also race between user context and softirq causing memleak,
consider the call sequence scenario
chtls_setkey() //user context
chtls_peer_close()
chtls_abort_req_rss()
chtls_setkey()
CPL handler functions chtls_pass_open_rpl() and
chtls_close_listsrv_rpl() should return CPL_RET_BUF_DONE
so that caller function will do skb free to avoid leak.
Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition")
Signed-off-by: Vinay Kumar Yadav
---
.../chelsio/inline_crypto/chtls/ch
On Fri, Oct 23, 2020 at 03:23:10PM -0700, Andrii Nakryiko wrote:
> On Fri, Oct 23, 2020 at 1:31 PM Steven Rostedt wrote:
> >
> > On Fri, 23 Oct 2020 13:03:22 -0700
> > Andrii Nakryiko wrote:
> >
> > > Basically, maybe ftrace subsystem could provide a set of APIs to
> > > prepare a set of function
In chtls_pass_establish() we hold child socket lock using bh_lock_sock
and we are again trying bh_lock_sock in add_to_reap_list, causing deadlock.
Remove bh_lock_sock in add_to_reap_list() as lock is already held.
Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition")
Signed-off-by: Vinay
On Fri, Oct 23, 2020 at 01:09:26PM -0700, Andrii Nakryiko wrote:
> On Thu, Oct 22, 2020 at 2:03 AM Jiri Olsa wrote:
> >
> > Adding trampoline batch attach support so it's possible to use
> > batch mode to load tracing programs.
> >
> > Adding trampoline_attach_batch bool to struct bpf_object_open_
On Fri, Oct 23, 2020 at 09:50:20AM -0400, Steven Rostedt wrote:
SNIP
> Is there something to keep an eBPF program from tracing a function with 6
> args? If the program saves only 5 args, but traces a function that has 6
> args, then the tracing program may end up using the register that the 6
> a
On Fri, Oct 23, 2020 at 12:46:15PM -0700, Andrii Nakryiko wrote:
> On Thu, Oct 22, 2020 at 8:01 AM Jiri Olsa wrote:
> >
> > Moving bpf_link_free call into delayed processing so we don't
> > need to wait for it when releasing the link.
> >
> > For example bpf_tracing_link_release could take conside
> >> 1. As the PHY chip has hardware configuration for configuring delays,
> >> we should at least have a mode that respects what's set on the
> >hardware.
> >
> >Yes, that is PHY_INTERFACE_MODE_NA. In DT, set the phy-mode to "". Or
> >for most MAC drivers, don't list a phy-mode at all.
>
> Howeve
From: Nikolay Aleksandrov
Extend the bridge multicast control and data path to configure routes
for L2 (non-IP) multicast groups.
The uapi struct br_mdb_entry union u is extended with another variant,
mac_addr, which does not change the structure size, and which is valid
when the proto field is
于 2020年10月25日 GMT+08:00 下午10:36:08, Andrew Lunn 写到:
>On Sun, Oct 25, 2020 at 10:27:05PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2020年10月25日 GMT+08:00 下午10:18:25, Andrew Lunn 写到:
>> >On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote:
>> >> Currently there are many boards that just
David Ahern writes:
> On 10/22/20 9:38 PM, Hangbin Liu wrote:
>> Note: ip/ipvrf.c is not convert to use libbpf as it only encodes a few
>> instructions and load directly.
>
> for completeness, libbpf should be able to load a program from a buffer
> as well.
It can, but the particular use in ipvr
Andrii Nakryiko writes:
> On Thu, Oct 22, 2020 at 8:39 PM Hangbin Liu wrote:
>>
>> This patch converts iproute2 to use libbpf for loading and attaching
>> BPF programs when it is available, which is started by Toke's
>> implementation[1]. With libbpf iproute2 could correctly process BTF
>> infor
> > +u64 read_mac_stats(struct eth_com *ecom, unsigned int addr)
> > +{
> > + u32 data_l, data_h;
> > +
> > + if (eth_com_read_reg(ecom, addr, &data_l) ||
> > + eth_com_read_reg(ecom, addr + 1, &data_h))
> > + return 0xULL;
> return -1; ?
Since this is a u64 fu
On Sun, Oct 25, 2020 at 03:34:06PM +0100, Ard Biesheuvel wrote:
> On Sun, 25 Oct 2020 at 15:29, Andrew Lunn wrote:
> >
> > On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
> > > On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
> > > >
> > > > > However, that leaves the question why
On Sun, Oct 25, 2020 at 10:27:05PM +0800, Icenowy Zheng wrote:
>
>
> 于 2020年10月25日 GMT+08:00 下午10:18:25, Andrew Lunn 写到:
> >On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote:
> >> Currently there are many boards that just set "rgmii" as phy-mode in
> >the
> >> device tree, and leave
On Sun, 25 Oct 2020 at 15:29, Andrew Lunn wrote:
>
> On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
> > On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
> > >
> > > > However, that leaves the question why bbc4d71d63549bcd was backported,
> > > > although I understand why the disc
On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
> On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
> >
> > > However, that leaves the question why bbc4d71d63549bcd was backported,
> > > although I understand why the discussion is a bit trickier there. But
> > > if it did not fix a
于 2020年10月25日 GMT+08:00 下午10:18:25, Andrew Lunn 写到:
>On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote:
>> Currently there are many boards that just set "rgmii" as phy-mode in
>the
>> device tree, and leave the hardware [TR]XDLY pins to set PHY delay
>mode.
>>
>> In order to keep o
On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote:
> Currently there are many boards that just set "rgmii" as phy-mode in the
> device tree, and leave the hardware [TR]XDLY pins to set PHY delay mode.
>
> In order to keep old device tree working, omit setting delay for just
> "RGMII" w
On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
>
> > However, that leaves the question why bbc4d71d63549bcd was backported,
> > although I understand why the discussion is a bit trickier there. But
> > if it did not fix a regression, only broken code that never worked in
> > the first place, I a
*_pdp_find() from gtp_encap_recv() would trigger a crash when a peer
sends GTP packets while creating new GTP device.
RIP: 0010:gtp1_pdp_find.isra.0+0x68/0x90 [gtp]
Call Trace:
gtp_encap_recv+0xc2/0x2e0 [gtp]
? gtp1_pdp_find.isra.0+0x90/0x90 [gtp]
udp_queue_rcv_one_skb+0x1fe/0x530
udp_queue
On Sun, 2020-10-25 at 06:59 +, Vladimir Oltean wrote:
> On Wed, Oct 21, 2020 at 09:17:07AM +, Nikolay Aleksandrov wrote:
> > > diff --git a/include/uapi/linux/if_bridge.h
> > > b/include/uapi/linux/if_bridge.h
> > > index 4c687686aa8f..a25f6f9aa8c3 100644
> > > --- a/include/uapi/linux/if_
On Sun, Oct 25, 2020 at 09:17:58AM +0100, Michael Walle wrote:
> Am 2020-10-24 14:14, schrieb Ioana Ciornei:
> > - Every PHY driver gains a .handle_interrupt() implementation that, for
> > the most part, would look like below:
> >
> > irq_status = phy_read(phydev, INTR_STATUS);
> > if (i
On Fri, Oct 16, 2020 at 12:18:58PM +0200, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin
>
> Currently in case of alignment or FCS error if the packet cannot be
> corrected it's still not dropped. Report the error properly and drop the
> packet while making the code around a little bit mo
Currently there are many boards that just set "rgmii" as phy-mode in the
device tree, and leave the hardware [TR]XDLY pins to set PHY delay mode.
In order to keep old device tree working, omit setting delay for just
"RGMII" without any internal delay suffix, otherwise many devices are
broken.
The
Am 2020-10-24 14:14, schrieb Ioana Ciornei:
- Every PHY driver gains a .handle_interrupt() implementation that, for
the most part, would look like below:
irq_status = phy_read(phydev, INTR_STATUS);
if (irq_status < 0) {
phy_error(phydev);
return
Hello Genius Open Source professional(s);
I hope this note finds you and yours well during the
Covid-19...20...2... crisis.
Thank you for continuing on with linux. Where would the world be
without it, and, so, without you? I stand on the shoulder or giants so
I can see -- the internet -- and lear
On Sun, Oct 25, 2020 at 08:59:57AM +0200, Vladimir Oltean wrote:
> On Wed, Oct 21, 2020 at 09:17:07AM +, Nikolay Aleksandrov wrote:
> > > diff --git a/include/uapi/linux/if_bridge.h
> > > b/include/uapi/linux/if_bridge.h
> > > index 4c687686aa8f..a25f6f9aa8c3 100644
> > > --- a/include/uapi/li
On Wed, Oct 21, 2020 at 09:17:07AM +, Nikolay Aleksandrov wrote:
> > diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> > index 4c687686aa8f..a25f6f9aa8c3 100644
> > --- a/include/uapi/linux/if_bridge.h
> > +++ b/include/uapi/linux/if_bridge.h
> > @@ -520,12 +520,14
65 matches
Mail list logo
