In the function ovs_ct_limit_exit, there is already a helper vaibale
which could be reused to improve the readability, so i fix it in this
patch.
Signed-off-by: Zeng Tao
---
net/openvswitch/conntrack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/conntr
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/rapidio/rio_cm.c: In function rio_txcq_handler:
drivers/rapidio/rio_cm.c:673:7: warning: variable ‘rc’ set but not used
[-Wunused-but-set-variable]
rc is never used, so remove it.
Signed-off-by: Zheng Yongjun
---
drivers/rapidio/rio_cm.c
Thu, Sep 17, 2020 at 10:31:10PM CEST, tlfal...@linux.ibm.com wrote:
>
>On 9/10/20 2:00 AM, Jiri Pirko wrote:
>> Tue, Sep 08, 2020 at 08:27:13PM CEST, tlfal...@linux.ibm.com wrote:
>> > On 9/4/20 5:37 PM, Jakub Kicinski wrote:
>> > > On Fri, 4 Sep 2020 10:31:41 +0200 Jiri Pirko wrote:
>> > > > Thu,
On Fri, Sep 18, 2020 at 03:18:44PM +0800, Zheng Yongjun wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/rapidio/rio_cm.c: In function rio_txcq_handler:
> drivers/rapidio/rio_cm.c:673:7: warning: variable ‘rc’ set but not used
> [-Wunused-but-set-variable]
>
> rc is never used
If a port is for an external controller, port's external attribute is
set. Show such external attribute.
An example of an external controller port for PCI VF:
$ devlink port show pci/:06:00.0/2
pci/:06:00.0/2: type eth netdev ens2f0c1pf0vf1 flavour pcivf pfnum 0 vfnum
1 external true spl
Show the controller number of the devlink port whenever kernel reports
it.
Example of a PCI VF port for an external controller number 1:
$ devlink port show pci/:06:00.0/2
pci/:06:00.0/2: type eth netdev ens2f0c1pf0vf1 flavour pcivf controller 1
pfnum 0 vfnum 1 external true splittable f
Update kernel headers to commit:
e2ce94dc1d89 ("devlink: introduce the health reporter test command")
Signed-off-by: Parav Pandit
---
include/uapi/linux/devlink.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index b7f23faa
For certain devlink port flavours controller number and optionally external
attributes are reported by the kernel.
(a) controller number indicates that a given port belong to which local or
external controller.
(b) external port attribute indicates that if a given port is for external or
local
On Thu, Sep 17, 2020 at 07:35:03PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so add a dependency
> on VHOST to eliminate build errors.
>
> ld: drivers/vdpa/mlx5/core/mr.o: in function `add_direct_chain':
> mr.c:(.text+0x106): undefined r
On 2020/8/22 05:14, David Miller wrote:
> From: Christoph Hellwig
> Date: Thu, 20 Aug 2020 06:37:44 +0200
>
>> If you look at who uses sendpage outside the networking layer itself
>> you see that it is basically block driver and file systems. These
>> have no way to control what memory they get
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function lio_pci_readq:
drivers/net/ethernet/cavium/liquidio/octeon_device.c:1327:6: warning: variable
‘val32’ set but not used [-Wunused-but-set-variable]
drivers/net/ethernet/cavium/liquidio
in the function cbs_dequeue_soft, when q->credits< 0, (now- q->last)
should be accounted for sendslope, not idleslope.
so the solution is as follows: when q->credits is less than 0, directly
calculate delay time, activate hrtimer and when hrtimer fires, calculate
idleslope credits and update it to
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/cortina/gemini.c: In function gmac_get_ringparam:
drivers/net/ethernet/cortina/gemini.c:2125:21: warning: variable ‘config0’ set
but not used [-Wunused-but-set-variable]
drivers/net/ethernet/cortina/gemini.c: In function gmac_in
Hi Ioana,
> -Original Message-
> From: Ioana Ciornei
> Sent: Wednesday, September 16, 2020 10:33 PM
> To: Y.b. Lu ; netdev@vger.kernel.org
> Cc: Y.b. Lu ; David S . Miller ;
> Jakub Kicinski ; Ioana Ciocoi Radulescu
> ; Richard Cochran
>
> Subject: RE: [v3, 6/6] dpaa2-eth: fix a build wa
Hi Andrew,
Thanks for your information. Should I do any modifications to make this patch
be applied?
B.R.
Willy
-Original Message-
From: Andrew Lunn
Sent: Thursday, September 17, 2020 9:40 PM
To: 劉偉權
Cc: hkallwe...@gmail.com; da...@davemloft.net; li...@armlinux.org.uk;
k...@kernel.or
Hi Dan,
On Thu, Sep 17, 2020 at 8:50 PM Dan Murphy wrote:
> On 9/17/20 8:57 AM, Geert Uytterhoeven wrote:
> > Some EtherAVB variants support internal clock delay configuration, which
> > can add larger delays than the delays that are typically supported by
> > the PHY (using an "rgmii-*id" PHY mo
Hi Saeed,
> -Original Message-
> From: Saeed Mahameed
> Sent: Thursday, September 17, 2020 3:23 AM
> To: Y.b. Lu ; netdev@vger.kernel.org
> Cc: David S . Miller ; Jakub Kicinski
> ; Ioana Ciornei ; Ioana Ciocoi
> Radulescu ; Richard Cochran
>
> Subject: Re: [v3, 5/6] dpaa2-eth: support P
Make a distinction between different irqs by netdev name or pci name.
Signed-off-by: Luo bin
---
drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c | 15 +--
drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.h | 1 +
drivers/net/ethernet/huawei/hinic/hinic_rx.c | 2 +-
drivers/net/e
This patch is a preparation for next hardware one-step timestamping
support. For DPAA2, the one step timestamping configuration on
hardware registers has to be done when there is no one-step timestamping
packet in flight. So we will have to use workqueue and skb queue
for such packets transmitting,
This patch is to add APIs of 1588 single step timestamping.
- dpni_set_single_step_cfg
- dpni_get_single_step_cfg
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
Changes for v3:
- Fixed sparse warnings.
Changes for v4:
- None.
---
drivers/net/ethernet/freescale/dpaa
Define a global ptp_qoriq structure pointer, and export to use.
The ptp clock operations will be used in dpaa2-eth driver.
For example, supporting one step timestamping needs to write
current time to hardware frame annotation before sending and
then hardware inserts the delay time on frame during s
Invoke dpaa2_eth_enable_tx_tstamp() once in code after building FD,
rather than calling it in dpaa2_eth_build_single_fd(),
dpaa2_eth_build_sg_fd_single_buf(), and dpaa2_eth_build_sg_fd().
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
Changes for v3:
- None.
Changes for v4:
This patch-set is to add MC APIs of 1588 one-step timestamping, and
support one-step timestamping for PTP Sync packet on DPAA2.
Before egress, one-step timestamping enablement needs,
- Enabling timestamp and FAS (Frame Annotation Status) in
dpni buffer layout.
- Write timestamp to frame annota
This patch is to add PTP sync packet one-step timestamping support.
Before egress, one-step timestamping enablement needs,
- Enabling timestamp and FAS (Frame Annotation Status) in
dpni buffer layout.
- Write timestamp to frame annotation and set PTP bit in
FAS to mark as one-step timestampin
Fix below sparse warning in dpmac.c.
warning: cast to restricted __le64
Signed-off-by: Yangbo Lu
---
Changes for v2:
- Fixed in right way.
---
drivers/net/ethernet/freescale/dpaa2/dpmac-cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/fre
Hi Vladimir,
> -Original Message-
> From: Vladimir Oltean
> Sent: Saturday, September 12, 2020 3:36 PM
> To: Y.b. Lu
> Cc: netdev@vger.kernel.org; devicet...@vger.kernel.org; David S . Miller
> ; Richard Cochran ; Rob
> Herring ; Mark Rutland
> Subject: Re: [PATCH 2/2] ptp_qoriq: suppor
Hi Vladimir,
> -Original Message-
> From: Vladimir Oltean
> Sent: Sunday, September 13, 2020 2:32 AM
> To: Y.b. Lu
> Cc: netdev@vger.kernel.org; devicet...@vger.kernel.org; David S . Miller
> ; Richard Cochran ; Rob
> Herring ; Mark Rutland
> Subject: Re: [PATCH 2/2] ptp_qoriq: support
The FIPER3 (fixed interval period pulse generator) is supported on
DPAA2 and ENETC network controller hardware. This patch-set is to
support it in ptp_qoriq driver and dt-binding.
Changes for v2:
- Some improvement in code.
- Added ACK from Vladimir.
Yangbo Lu (2):
dt-binding: ptp_qoriq: suppor
The FIPER3 (fixed interval period pulse generator) is supported on
DPAA2 and ENETC network controller hardware. This patch is to support
it in ptp_qoriq driver.
Signed-off-by: Yangbo Lu
Acked-by: Vladimir Oltean
---
Changes for v2:
- Some improvement in code.
- Added ACK from Vla
Add fsl,tmr-fiper3 property definition which is supported only
on DPAA2 and ENETC network controller hardware.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
---
Documentation/devicetree/bindings/ptp/ptp-qoriq.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/
On Thu, 17 Sep 2020 12:11:33 -0700
Saeed Mahameed wrote:
> On Thu, 2020-09-17 at 05:54 -0700, Maciej Żenczykowski wrote:
> > On Thu, Sep 17, 2020 at 5:39 AM Jesper Dangaard Brouer
> > wrote:
> > >
> > > As you likely know[1] I'm looking into moving the MTU check (for
> > > TC-BPF) in __bpf_sk
On Thu, Sep 17, 2020 at 07:54:50AM -0500, Seth Forshee wrote:
> On Thu, Sep 17, 2020 at 11:14:06AM +0200, Jiri Olsa wrote:
> > On Thu, Sep 17, 2020 at 10:38:12AM +0200, Jiri Olsa wrote:
> > > On Thu, Sep 17, 2020 at 10:04:55AM +0200, Jiri Olsa wrote:
> > > > On Wed, Sep 16, 2020 at 02:47:33PM -0500
> From: Parav Pandit
> Sent: Friday, September 18, 2020 1:33 PM
>
> For certain devlink port flavours controller number and optionally external
> attributes are reported by the kernel.
>
> (a) controller number indicates that a given port belong to which local or
> external controller.
> (b) e
We get 1 warning when building kernel with W=1:
drivers/ptp/ptp_pch.c:182:5: warning: no previous prototype for
‘pch_ch_control_read’ [-Wmissing-prototypes]
u32 pch_ch_control_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:193:6: warning: no previous prototype for
‘pch_ch_control_write’ [-Wmis
Update kernel headers to commit:
e2ce94dc1d89 ("devlink: introduce the health reporter test command")
Signed-off-by: Parav Pandit
---
include/uapi/linux/devlink.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index b7f23faa
For certain devlink port flavours controller number and optionally external
attributes are reported by the kernel.
(a) controller number indicates that a given port belong to which local or
external controller.
(b) external port attribute indicates that if a given port is for external or
local
If a port is for an external controller, port's external attribute is
set. Show such external attribute.
An example of an external controller port for PCI VF:
$ devlink port show pci/:06:00.0/2
pci/:06:00.0/2: type eth netdev ens2f0c1pf0vf1 flavour pcivf pfnum 0 vfnum
1 external true spl
Show the controller number of the devlink port whenever kernel reports
it.
Example of a PCI VF port for an external controller number 1:
$ devlink port show pci/:06:00.0/2
pci/:06:00.0/2: type eth netdev ens2f0c1pf0vf1 flavour pcivf controller 1
pfnum 0 vfnum 1 external true splittable f
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:161:14-17: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:168:13-16: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:179:14-17: WARNING:
Comparison t
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c:1897:5-13: WARNING:
Comparison to bool
Signed-off-by: Zheng Bin
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek
Zheng Bin (9):
rtlwifi: rtl8192ee: fix comparison to bool warning in hw.c
rtlwifi: rtl8192c: fix comparison to bool warning in phy_common.c
rtlwifi: rtl8192cu: fix comparison to bool warning in mac.c
rtlwifi: rtl8821ae: fix comparison to bool warning in hw.c
rtlwifi: rtl8821ae: fix compar
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c:797:6-33: WARNING:
Comparison to bool
Signed-off-by: Zheng Bin
---
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c:1106:14-18: WARNING:
Comparison to bool
Signed-off-by: Zheng Bin
---
drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/w
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:1816:5-13: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:1825:5-13: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:1839:5-13: WARNING:
Comparison t
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c:616:14-20: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c:621:13-19: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c:626:14-20: WARNING:
Comparison to b
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c:566:14-20: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c:572:13-19: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c:581:14-20: WARNING:
Comparison to b
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c:861:6-35: WARNING:
Comparison to bool
Signed-off-by: Zheng Bin
---
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:831:14-49: WARNING:
Comparison to bool
Signed-off-by: Zheng Bin
---
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek
On Thu, Sep 17, 2020 at 02:14:38PM -0700, Alexei Starovoitov wrote:
> On Thu, Sep 17, 2020 at 1:25 AM Jiri Olsa wrote:
> >
> > > Ideally resolve_btfids would parse dwarf info and check
> > > whether any of the funcs in allowlist were inlined.
> > > That would be more reliable, but not pretty to dr
Historically L2TP core statistics count the L2TP header in the
per-session and per-tunnel byte counts tracked for transmission and
receipt.
Now that l2tp_xmit_skb updates tx stats, it is necessary for
l2tp_xmit_core to pass out the length of the transmitted packet so that
the statistics can be upd
Jesper Dangaard Brouer writes:
> On Thu, 17 Sep 2020 12:11:33 -0700
> Saeed Mahameed wrote:
>
>> On Thu, 2020-09-17 at 05:54 -0700, Maciej Żenczykowski wrote:
>> > On Thu, Sep 17, 2020 at 5:39 AM Jesper Dangaard Brouer
>> > wrote:
>> > >
>> > > As you likely know[1] I'm looking into moving t
Hello folks,
any thoughts on this patch?
It can make the test pass and reduce the failure numbers in
kselftests, it will be great to have this applied.
Thanks
PHLin
On Tue, Sep 8, 2020 at 2:57 PM Po-Hsu Lin wrote:
>
> On Tue, Sep 8, 2020 at 4:12 AM Jakub Kicinski wrote:
> >
> > On Mon, 7 Sep
From: Vladimir Oltean
It is a good measure to ensure correctness if the structures that are
meant to remain constant are only processed by functions that thake
constant arguments.
Signed-off-by: Vladimir Oltean
---
drivers/net/ethernet/mscc/ocelot_ptp.c | 3 ++-
include/soc/mscc/ocelot_ptp.h
From: Vladimir Oltean
While we don't plan on making any changes to this function, currently
this is the only remaining dependency between felix and seville, after
the PCS has been refactored out into pcs-lynx.c.
Duplicate this function in seville to break the dependency completely.
Signed-off-b
From: Vladimir Oltean
Some definitions were likely copied from
drivers/net/mdio/mdio-mscc-miim.c.
They are not necessary, remove them.
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/seville_vsc9953.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/net/dsa/oc
From: Vladimir Oltean
Seville does not need to depend on PCI or on the ENETC MDIO controller.
There will also be other compile-time differences in the future.
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/Kconfig | 22
drivers/net/dsa/ocelot/Makefile
From: Vladimir Oltean
Over the time, some patches have introduced structures aligned with
spaces, near structures aligned with tabs. Fix the inconsistencies.
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/felix.c | 2 +-
drivers/net/dsa/ocelot/felix.h | 2 +-
drive
From: Vladimir Oltean
When introducing the Seville switch support to the Felix driver, some
technical debt was created. Since both VSC9959 and VSC9953 are embedded
switches (one on an arm64 SoC and the other on a powerpc SoC), there is
no use case for having the code for both be present in the sa
From: Vladimir Oltean
The overall idea (issue soft reset, enable memories, initialize
memories, enable core) is the same, so it would make sense that an
attempt is made to unify the procedures.
It is not immediately obvious that the fields are not part of the same
register targets, though. So ad
From: Vladimir Oltean
Not only does Sevile not have a PTP clock, but with separate modules,
this structure cannot even live in felix.c, due to the .owner =
THIS_MODULE assignment causing this link time error:
drivers/net/dsa/ocelot/felix.o:(.data+0x0): undefined reference to
`__this_module'
Si
From: Vladimir Oltean
Reindent these definitions to be in line with the rest of the driver.
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/seville_vsc9953.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dsa/ocelot/seville_vsc9953.c
b/d
From: Vladimir Oltean
As per documentation, proper startup sequence is:
* Enable memories
* Initialize memories
* Enable core
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/seville_vsc9953.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/ocelot/s
From: Vladimir Oltean
There is another one of these right above the readx_poll_status.
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/seville_vsc9953.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/dsa/ocelot/seville_vsc9953.c
b/drivers/net/dsa/ocelot/seville_vsc99
From: Vladimir Oltean
Since these helpers for regmap fields are available, use them.
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/felix_vsc9959.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/oce
Some kernels builds might inline vfs_getattr call within fstat
syscall code path, so fentry/vfs_getattr trampoline is not called.
Alexei suggested [1] we should use security_inode_getattr instead,
because it's less likely to get inlined. Using this idea also for
vfs_truncate (replaced with securit
On 17/09/2020 20:18, Jason Gunthorpe wrote:
> On Tue, Sep 15, 2020 at 11:46:58PM +0300, Oded Gabbay wrote:
>> infrastructure for communication between multiple accelerators. Same
>> as Nvidia uses NVlink, we use RDMA that we have inside our ASIC.
>> The RDMA implementation we did does NOT support s
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:1576:6: warning:
variable 'ret' set but not used [-Wunused-but-set-variable]
1576 | int ret;
| ^~~
driver_for_each_device() has been declared with __must_check, so the
return va
On Fri, Sep 18, 2020 at 02:36:10PM +0300, Gal Pressman wrote:
> On 17/09/2020 20:18, Jason Gunthorpe wrote:
> > On Tue, Sep 15, 2020 at 11:46:58PM +0300, Oded Gabbay wrote:
> >> infrastructure for communication between multiple accelerators. Same
> >> as Nvidia uses NVlink, we use RDMA that we have
On Fri, Sep 18, 2020 at 02:36:10PM +0300, Gal Pressman wrote:
> On 17/09/2020 20:18, Jason Gunthorpe wrote:
> > On Tue, Sep 15, 2020 at 11:46:58PM +0300, Oded Gabbay wrote:
> >> infrastructure for communication between multiple accelerators. Same
> >> as Nvidia uses NVlink, we use RDMA that we have
On Fri, Sep 18, 2020 at 2:52 PM Leon Romanovsky wrote:
>
> On Fri, Sep 18, 2020 at 02:36:10PM +0300, Gal Pressman wrote:
> > On 17/09/2020 20:18, Jason Gunthorpe wrote:
> > > On Tue, Sep 15, 2020 at 11:46:58PM +0300, Oded Gabbay wrote:
> > >> infrastructure for communication between multiple accel
On Fri, Sep 18, 2020 at 2:56 PM Jason Gunthorpe wrote:
>
> On Fri, Sep 18, 2020 at 02:36:10PM +0300, Gal Pressman wrote:
> > On 17/09/2020 20:18, Jason Gunthorpe wrote:
> > > On Tue, Sep 15, 2020 at 11:46:58PM +0300, Oded Gabbay wrote:
> > >> infrastructure for communication between multiple accel
On Fri, Sep 18, 2020 at 3:00 PM Jason Gunthorpe wrote:
>
>
> On Tue, Sep 15, 2020 at 08:10:08PM +0300, Oded Gabbay wrote:
> > Hello,
> >
> > This is the second version of the patch-set to upstream the GAUDI NIC code
> > into the habanalabs driver.
> >
> > The only modification from v2 is in the et
On Fri, Sep 18, 2020 at 02:56:09PM +0300, Oded Gabbay wrote:
> On Fri, Sep 18, 2020 at 2:52 PM Leon Romanovsky wrote:
> >
> > On Fri, Sep 18, 2020 at 02:36:10PM +0300, Gal Pressman wrote:
> > > On 17/09/2020 20:18, Jason Gunthorpe wrote:
> > > > On Tue, Sep 15, 2020 at 11:46:58PM +0300, Oded Gabba
On Fri, Sep 18, 2020 at 3:03 PM Leon Romanovsky wrote:
>
> On Fri, Sep 18, 2020 at 02:56:09PM +0300, Oded Gabbay wrote:
> > On Fri, Sep 18, 2020 at 2:52 PM Leon Romanovsky wrote:
> > >
> > > On Fri, Sep 18, 2020 at 02:36:10PM +0300, Gal Pressman wrote:
> > > > On 17/09/2020 20:18, Jason Gunthorpe
On Fri, Sep 18, 2020 at 2:36 PM Gal Pressman wrote:
>
> On 17/09/2020 20:18, Jason Gunthorpe wrote:
> > On Tue, Sep 15, 2020 at 11:46:58PM +0300, Oded Gabbay wrote:
> >> infrastructure for communication between multiple accelerators. Same
> >> as Nvidia uses NVlink, we use RDMA that we have inside
The ifreq ioctls need a special compat handler at the moment because of
the size difference between the struct on native and compat architectures,
but this difference exists only for one pair of ioctls, SIOCGIFMAP
and SIOCSIFMAP.
Splitting these two out of dev_ioctl() into their own higher level
i
The ethtool compat ioctl handling is hidden away in net/socket.c,
which introduces a couple of minor oddities:
- The implementation may end up diverging, as seen in the RXNFC
extension in commit 84a1d9c48200 ("net: ethtool: extend RXNFC
API to support RSS spreading of filter matches") that doe
is_mptcp is a field from struct tcp_sock used to indicate that the
current tcp_sock is part of the MPTCP protocol.
In this protocol, a first socket (mptcp_sock) is created with
sk_protocol set to IPPROTO_MPTCP (=262) for control purpose but it
isn't directly on the wire. This is the role of the su
It has been observed that the kernel sockets created for the subflows
(except the first one) are not in the same cgroup as their parents.
That's because the additional subflows are created by kernel workers.
This is a problem with eBPF programs attached to the parent's
cgroup won't be executed for
This patch adds a base for MPTCP specific tests.
It is currently limited to the is_mptcp field in case of plain TCP
connection because for the moment there is no easy way to get the subflow
sk from a msk in userspace. This implies that we cannot lookup the
sk_storage attached to the subflow sk in
In order to precisely identify the parent MPTCP connection of a subflow,
it is required to access the mptcp_sock's token which uniquely identify a
MPTCP connection.
This patch adds a new structure 'bpf_mptcp_sock' exposing the 'token' field
of the 'mptcp_sock' extracted from a subflow's 'tcp_sock'
This patch adds verifier side tests for the new bpf_mptcp_sock() helper.
Here are the new tests :
- NULL bpf_sock is correctly handled
- We cannot access a field from bpf_mptcp_sock if the latter is NULL
- We can access a field from bpf_mptcp_sock if the latter is not NULL
- We cannot modify a fie
Previously it was not possible to make a distinction between plain TCP
sockets and MPTCP subflow sockets on the BPF_PROG_TYPE_SOCK_OPS hook.
This patch series now enables a fine control of subflow sockets. In its
current state, it allows to put different sockopt on each subflow from a
same MPTCP c
On Tue, Sep 15, 2020 at 08:10:08PM +0300, Oded Gabbay wrote:
> Hello,
>
> This is the second version of the patch-set to upstream the GAUDI NIC code
> into the habanalabs driver.
>
> The only modification from v2 is in the ethtool patch (patch 12). Details
> are in that patch's commit message.
On Fri, Sep 18, 2020 at 02:59:28PM +0300, Oded Gabbay wrote:
> On Fri, Sep 18, 2020 at 2:56 PM Jason Gunthorpe wrote:
> >
> > On Fri, Sep 18, 2020 at 02:36:10PM +0300, Gal Pressman wrote:
> > > On 17/09/2020 20:18, Jason Gunthorpe wrote:
> > > > On Tue, Sep 15, 2020 at 11:46:58PM +0300, Oded Gabba
On Fri, Sep 18, 2020 at 03:07:19PM +0300, Oded Gabbay wrote:
> On Fri, Sep 18, 2020 at 3:03 PM Leon Romanovsky wrote:
> >
> > On Fri, Sep 18, 2020 at 02:56:09PM +0300, Oded Gabbay wrote:
> > > On Fri, Sep 18, 2020 at 2:52 PM Leon Romanovsky wrote:
> > > >
> > > > On Fri, Sep 18, 2020 at 02:36:10P
Seth reported problem with cross builds, that fail
on resolve_btfids build, because we are trying to
build it on cross build arch.
Fixing this by always forcing the host arch.
Fixes: fbbb68de80a4 ("bpf: Add resolve_btfids tool to resolve BTF IDs in ELF
object")
Reported-by: Seth Forshee
Signed-
Currently all the resolve_btfids 'users' are under CONFIG_BPF
code, so if we have CONFIG_BPF disabled, resolve_btfids will
fail, because there's no data to resolve.
In case CONFIG_BPF is disabled, using resolve_btfids --no-fail
option, that makes resolve_btfids leave quietly if there's no
data to
On Fri, Sep 18, 2020 at 3:19 PM Leon Romanovsky wrote:
>
> On Fri, Sep 18, 2020 at 03:07:19PM +0300, Oded Gabbay wrote:
> > On Fri, Sep 18, 2020 at 3:03 PM Leon Romanovsky wrote:
> > >
> > > On Fri, Sep 18, 2020 at 02:56:09PM +0300, Oded Gabbay wrote:
> > > > On Fri, Sep 18, 2020 at 2:52 PM Leon
On Fri, Sep 18, 2020 at 3:16 PM Jason Gunthorpe wrote:
>
> On Fri, Sep 18, 2020 at 02:59:28PM +0300, Oded Gabbay wrote:
> > On Fri, Sep 18, 2020 at 2:56 PM Jason Gunthorpe wrote:
> > >
> > > On Fri, Sep 18, 2020 at 02:36:10PM +0300, Gal Pressman wrote:
> > > > On 17/09/2020 20:18, Jason Gunthorpe
On Mon, 2020-09-14 at 09:40 +0200, Geert Uytterhoeven wrote:
> Hi David,
>
> CC bridge
>
> On Sun, Sep 13, 2020 at 3:34 AM David Miller wrote:
> > From: Geert Uytterhoeven
> > Date: Sat, 12 Sep 2020 14:33:59 +0200
> >
> > > "dev" is not the bridge device, but the physical Ethernet interface, w
Hi Al,
this series changes import_iovec to transparently deal with comat iovec
structures, and then cleanups up a lot of code dupliation. But to get
there it first has to fix the pre-existing bug that io_uring compat
contexts don't trigger the in_compat_syscall() check. This has so far
been rela
Explicitly check for the magic value insted of implicitly relying on
its number representation.
Signed-off-by: Christoph Hellwig
---
fs/read_write.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/read_write.c b/fs/read_write.c
index 5db58b8c78d0dd..f153116bc5399b 100
Add a flag to force processing a syscall as a compat syscall. This is
required so that in_compat_syscall() works for I/O submitted by io_uring
helper threads on behalf of compat syscalls.
Signed-off-by: Christoph Hellwig
---
arch/sparc/include/asm/compat.h | 3 ++-
arch/x86/include/asm/compat.h
Now that import_iovec handles compat iovecs, the native vmsplice syscall
can be used for the compat case as well.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/unistd32.h | 2 +-
arch/mips/kernel/syscalls/syscall_n32.tbl | 2 +-
arch/mips/kernel/syscalls/syscall_o
Now that import_iovec handles compat iovecs, the native version of
keyctl_instantiate_key_iov can be used for the compat case as well.
Signed-off-by: Christoph Hellwig
---
security/keys/compat.c | 36 ++--
security/keys/internal.h | 5 -
security/keys/keyct
Use in compat_syscall to import either native or the compat iovecs, and
remove the now superflous compat_import_iovec.
Signed-off-by: Christoph Hellwig
---
block/scsi_ioctl.c | 12 +---
drivers/scsi/sg.c | 9 +--
fs/aio.c | 38 +---
fs/io_uring.c | 12
Now that import_iovec handles compat iovecs, the native syscalls
can be used for the compat case as well.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/unistd32.h | 4 +-
arch/mips/kernel/syscalls/syscall_n32.tbl | 4 +-
arch/mips/kernel/syscalls/syscall_o32.tbl
Now that import_iovec handles compat iovecs as well, all the duplicated
code in the compat readv/writev helpers is not needed. Remove them
and switch the compat syscall handlers to use the native helpers.
Signed-off-by: Christoph Hellwig
---
fs/read_write.c | 179 ---
Now that import_iovec handles compat iovecs, the native readv and writev
syscalls can be used for the compat case as well.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/unistd32.h | 4 ++--
arch/mips/kernel/syscalls/syscall_n32.tbl | 4 ++--
arch/mips/ke
1 - 100 of 391 matches
Mail list logo
