* Re: [PATCH net-next v3 02/10] ptp: ocp: add Celestica timecard PCI ids
From: Jakub Kicinski @ 2022-05-17 0:43 UTC (permalink / raw)
To: Jonathan Lemon
Cc: netdev, richardcochran, davem, pabeni, edumazet, kernel-team
In-Reply-To: <20220513225924.1655-3-jonathan.lemon@gmail.com>
On Fri, 13 May 2022 15:59:16 -0700 Jonathan Lemon wrote:
> +#ifndef PCI_VENDOR_ID_CELESTICA
> +#define PCI_VENDOR_ID_CELESTICA 0x18d4
> +#endif
> +
> +#ifndef PCI_DEVICE_ID_CELESTICA_TIMECARD
> +#define PCI_DEVICE_ID_CELESTICA_TIMECARD 0x1008
> +#endif
The ifdefs are unnecessary, these kind of constructs are often used out
of tree when one does not control the headers, but not sure what purpose
they'd serve upstream?
^ permalink raw reply
* Re: [PATCH net-next v3 08/10] ptp: ocp: fix PPS source selector reporting
From: Jakub Kicinski @ 2022-05-17 0:43 UTC (permalink / raw)
To: Jonathan Lemon
Cc: netdev, richardcochran, davem, pabeni, edumazet, kernel-team
In-Reply-To: <20220513225924.1655-9-jonathan.lemon@gmail.com>
On Fri, 13 May 2022 15:59:22 -0700 Jonathan Lemon wrote:
> The NTL timecard design has a PPS1 selector which selects the
> the PPS source automatically, according to Section 1.9 of the
> documentation.
>
> If there is a SMA PPS input detected:
> - send signal to MAC and PPS slave selector.
>
> If there is a MAC PPS input detected:
> - send GNSS1 to the MAC
> - send MAC to the PPS slave
>
> If there is a GNSS1 input detected:
> - send GNSS1 to the MAC
> - send GNSS1 to the PPS slave.MAC
>
> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
This one and patch 10 need Fixes tags
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply
From: Rob Herring @ 2022-05-17 0:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Brown, LABBE Corentin, alexandre.torgue, calvin.johnson,
davem, edumazet, hkallweit1, jernej.skrabec, joabreu,
krzysztof.kozlowski+dt, kuba, lgirdwood, linux, pabeni,
peppe.cavallaro, samuel, wens, netdev, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <YnlDbbegQ1IbbaHy@lunn.ch>
On Mon, May 09, 2022 at 06:38:05PM +0200, Andrew Lunn wrote:
> > No, that's not a thing - the supplies are individual, named properties
> > and even if there were a list we'd still want them to be named so it's
> > clear what's going on.
>
> So we have a collection of regulators, varying in numbers between
> different PHYs, with different vendor names and purposes. In general,
> they all should be turned on. Yet we want them named so it is clear
> what is going on.
In what order do we turn the supplies on? How much time in between each
one? Does an external clock need to be running before or after (and how
long after). Oh, and what about resets and the order and timing of them
relative to everything else?
This always happens in the same order. First, it's just one resource
like a regulator or reset. Then one more. Then another device with some
timing constraints. If we wanted a generic solution in DT, it would need
to be able to describe any power sequencing waveform. But we don't have
that because we don't want it.
> Is there a generic solution here so that the phylib core can somehow
> enumerate them and turn them on, without actually knowing what they
> are called because they have vendor specific names in order to be
> clear what they are?
Other devices have specific compatibles so that the device can be
identified and powered up. Once again, MDIO should not be special here.
> There must be a solution to this, phylib cannot be the first subsystem
> to have this requirement, so if you could point to an example, that
> would be great.
Well, no one seems to want to make non-discoverable devices on
'discoverable' buses work. Still an issue for PCI and USB. I thought
MDIO had a solution here to probe any devices in the DT even if not
discovered.
Rob
^ permalink raw reply
* [PATCH v2 06/13] openrisc: Update litex defconfig to support glibc userland
From: Stafford Horne @ 2022-05-17 0:55 UTC (permalink / raw)
To: LKML
Cc: Openrisc, Stafford Horne, Jonas Bonn, Stefan Kristiansson,
Karol Gugala, Mateusz Holenko, Gabriel Somlo, Joel Stanley,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, netdev, bpf
In-Reply-To: <20220517005510.3500105-1-shorne@gmail.com>
I have been using a litex SoC for glibc verification. Update the
default litex config to support required userspace API's needed for the
full glibc testsuite to pass.
This includes enabling the litex mmc driver and filesystems used
in a typical litex environment.
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/configs/or1klitex_defconfig | 33 +++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/openrisc/configs/or1klitex_defconfig b/arch/openrisc/configs/or1klitex_defconfig
index d695879a4d26..4c0138340bd9 100644
--- a/arch/openrisc/configs/or1klitex_defconfig
+++ b/arch/openrisc/configs/or1klitex_defconfig
@@ -1,22 +1,55 @@
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_CGROUPS=y
+CONFIG_NAMESPACES=y
+CONFIG_USER_NS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SGETMASK_SYSCALL=y
CONFIG_EMBEDDED=y
CONFIG_OPENRISC_BUILTIN_DTB="or1klitex"
+# CONFIG_OPENRISC_HAVE_INST_RORI is not set
CONFIG_HZ_100=y
+CONFIG_OPENRISC_HAVE_SHADOW_GPRS=y
CONFIG_NET=y
CONFIG_PACKET=y
+CONFIG_PACKET_DIAG=y
CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_INET_UDP_DIAG=y
+CONFIG_INET_RAW_DIAG=y
+# CONFIG_WIRELESS is not set
+# CONFIG_ETHTOOL_NETLINK is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_OF_OVERLAY=y
CONFIG_NETDEVICES=y
CONFIG_LITEX_LITEETH=y
+# CONFIG_WLAN is not set
CONFIG_SERIAL_LITEUART=y
CONFIG_SERIAL_LITEUART_CONSOLE=y
CONFIG_TTY_PRINTK=y
+# CONFIG_GPIO_CDEV is not set
+CONFIG_MMC=y
+CONFIG_MMC_LITEX=y
+# CONFIG_VHOST_MENU is not set
+# CONFIG_IOMMU_SUPPORT is not set
CONFIG_LITEX_SOC_CONTROLLER=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_EXFAT_FS=y
CONFIG_TMPFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,bpf"
CONFIG_PRINTK_TIME=y
CONFIG_PANIC_ON_OOPS=y
CONFIG_SOFTLOCKUP_DETECTOR=y
--
2.31.1
^ permalink raw reply related
* [linux-next:master] BUILD REGRESSION 3f7bdc402fb06f897ff1f492a2d42e1f7c2efedb
From: kernel test robot @ 2022-05-17 0:56 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, linux-pm, linux-omap, linux-mm, linux-fbdev, kvm,
intel-gfx, dri-devel, bpf, amd-gfx, Linux Memory Management List
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 3f7bdc402fb06f897ff1f492a2d42e1f7c2efedb Add linux-next specific files for 20220516
Error/Warning reports:
https://lore.kernel.org/linux-mm/202204291924.vTGZmerI-lkp@intel.com
https://lore.kernel.org/linux-mm/202205041248.WgCwPcEV-lkp@intel.com
https://lore.kernel.org/linux-mm/202205122113.uLKzd3SZ-lkp@intel.com
https://lore.kernel.org/linux-mm/202205150051.3RzuooAG-lkp@intel.com
https://lore.kernel.org/linux-mm/202205150117.sd6HzBVm-lkp@intel.com
https://lore.kernel.org/llvm/202205170327.TVBbIsh2-lkp@intel.com
https://lore.kernel.org/llvm/202205170352.5YjuBP5H-lkp@intel.com
Error/Warning: (recently discovered and may have been fixed)
<command-line>: fatal error: ./include/generated/utsrelease.h: No such file or directory
ERROR: modpost: "__udivdi3" [drivers/mtd/parsers/scpart.ko] undefined!
arch/riscv/include/asm/tlbflush.h:23:2: error: expected assembly-time absolute expression
arch/x86/kvm/pmu.h:20:32: warning: 'vmx_icl_pebs_cpu' defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1364:5: warning: no previous prototype for 'amdgpu_discovery_get_mall_info' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/soc21.c:171:6: warning: no previous prototype for 'soc21_grbm_select' [-Wmissing-prototypes]
drivers/gpu/drm/solomon/ssd130x-spi.c:154:35: warning: 'ssd130x_spi_table' defined but not used [-Wunused-const-variable=]
drivers/video/fbdev/omap/hwa742.c:492:5: warning: no previous prototype for 'hwa742_update_window_async' [-Wmissing-prototypes]
fs/buffer.c:2254:5: warning: stack frame size (2152) exceeds limit (1024) in 'block_read_full_folio' [-Wframe-larger-than]
fs/ntfs/aops.c:378:12: warning: stack frame size (2216) exceeds limit (1024) in 'ntfs_read_folio' [-Wframe-larger-than]
kernel/trace/fgraph.c:37:12: warning: no previous prototype for 'ftrace_enable_ftrace_graph_caller' [-Wmissing-prototypes]
kernel/trace/fgraph.c:46:12: warning: no previous prototype for 'ftrace_disable_ftrace_graph_caller' [-Wmissing-prototypes]
Unverified Error/Warning (likely false positive, please contact us if interested):
Error: Section .bss not empty in prom_init.c
Makefile:686: arch/h8300/Makefile: No such file or directory
arch/Kconfig:10: can't open file "arch/h8300/Kconfig"
arch/arm64/kvm/pmu.c:9:46: warning: tentative definition of variable with internal linkage has incomplete non-array type 'typeof(struct kvm_pmu_events)' (aka 'struct kvm_pmu_events') [-Wtentative-definition-incomplete-type]
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5102:14: warning: variable 'allow_lttpr_non_transparent_mode' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5147:6: warning: no previous prototype for 'dp_parse_lttpr_mode' [-Wmissing-prototypes]
drivers/gpu/drm/bridge/adv7511/adv7511.h:229:17: warning: 'ADV7511_REG_CEC_RX_FRAME_HDR' defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/bridge/adv7511/adv7511.h:235:17: warning: 'ADV7511_REG_CEC_RX_FRAME_LEN' defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:46 sysfs_gt_attribute_w_func() error: uninitialized symbol 'ret'.
drivers/opp/core.c:1499:13: warning: Uninitialized variable: iter->rate [uninitvar]
drivers/opp/core.c:1533:14: warning: Uninitialized variable: temp->removed [uninitvar]
drivers/opp/core.c:2682:16: warning: Uninitialized variable: tmp_opp->rate [uninitvar]
drivers/opp/core.c:365:12: warning: Uninitialized variable: opp->available [uninitvar]
drivers/opp/core.c:442:17: warning: Uninitialized variable: temp_opp->available [uninitvar]
drivers/opp/core.c:491:17: warning: Uninitialized variable: temp_opp->level [uninitvar]
drivers/opp/core.c:60:26: warning: Uninitialized variables: opp_table.node, opp_table.lazy, opp_table.head, opp_table.dev_list, opp_table.opp_list, opp_table.kref, opp_table.lock, opp_table.np, opp_table.clock_latency_ns_max, opp_table.voltage_tolerance_v1, opp_table.parsed_static_opps, opp_table.shared_opp, opp_table.current_rate, opp_table.current_opp, opp_table.suspend_opp, opp_table.genpd_virt_dev_lock, opp_table.genpd_virt_devs, opp_table.required_opp_tables, opp_table.required_opp_count, opp_table.supported_hw, opp_table.supported_hw_count, opp_table.prop_name, opp_table.clk, opp_table.regulators, opp_table.regulator_count, opp_table.paths, opp_table.path_count, opp_table.enabled, opp_table.genpd_performance_state, opp_table.is_genpd, opp_table.set_opp, opp_table.sod_supplies, opp_table.set_opp_data [uninitvar]
kernel/bpf/verifier.c:5354 process_kptr_func() warn: passing zero to 'PTR_ERR'
make[1]: *** No rule to make target 'arch/h8300/Makefile'.
mm/shmem.c:1910 shmem_getpage_gfp() warn: should '(((1) << 12) / 512) << folio_order(folio)' be a 64 bit type?
{standard input}:1991: Error: unknown pseudo-op: `.lc'
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- arc-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- arm-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| |-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
| `-- drivers-video-fbdev-omap-hwa742.c:warning:no-previous-prototype-for-hwa742_update_window_async
|-- arm-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| |-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
| `-- drivers-video-fbdev-omap-hwa742.c:warning:no-previous-prototype-for-hwa742_update_window_async
|-- arm64-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- h8300-allyesconfig
| |-- Makefile:arch-h8300-Makefile:No-such-file-or-directory
| |-- arch-Kconfig:can-t-open-file-arch-h8300-Kconfig
| `-- make:No-rule-to-make-target-arch-h8300-Makefile-.
|-- h8300-randconfig-r001-20220516
| |-- Makefile:arch-h8300-Makefile:No-such-file-or-directory
| |-- arch-Kconfig:can-t-open-file-arch-h8300-Kconfig
| `-- make:No-rule-to-make-target-arch-h8300-Makefile-.
|-- i386-allyesconfig
| |-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| |-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
| |-- drivers-gpu-drm-bridge-adv7511-adv7511.h:warning:ADV7511_REG_CEC_RX_FRAME_HDR-defined-but-not-used
| |-- drivers-gpu-drm-bridge-adv7511-adv7511.h:warning:ADV7511_REG_CEC_RX_FRAME_LEN-defined-but-not-used
| `-- drivers-gpu-drm-solomon-ssd13-spi.c:warning:ssd13_spi_table-defined-but-not-used
|-- i386-debian-10.3
| `-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
|-- i386-debian-10.3-kselftests
| `-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
|-- i386-randconfig-a011-20220516
| |-- drivers-gpu-drm-bridge-adv7511-adv7511.h:warning:ADV7511_REG_CEC_RX_FRAME_HDR-defined-but-not-used
| `-- drivers-gpu-drm-bridge-adv7511-adv7511.h:warning:ADV7511_REG_CEC_RX_FRAME_LEN-defined-but-not-used
|-- i386-randconfig-m021-20220516
| |-- kernel-bpf-verifier.c-process_kptr_func()-warn:passing-zero-to-PTR_ERR
| `-- mm-shmem.c-shmem_getpage_gfp()-warn:should-((()-)-)-folio_order(folio)-be-a-bit-type
|-- ia64-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- ia64-randconfig-r005-20220516
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- microblaze-randconfig-s031-20220516
| |-- kernel-trace-fgraph.c:warning:no-previous-prototype-for-ftrace_disable_ftrace_graph_caller
| `-- kernel-trace-fgraph.c:warning:no-previous-prototype-for-ftrace_enable_ftrace_graph_caller
|-- mips-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- mips-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- parisc-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- powerpc-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- powerpc-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- powerpc-randconfig-c004-20220516
| `-- command-line:fatal-error:.-include-generated-utsrelease.h:No-such-file-or-directory
|-- powerpc64-randconfig-r011-20220516
| `-- Error:Section-.bss-not-empty-in-prom_init.c
|-- riscv-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- riscv-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- s390-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- sh-allmodconfig
| `-- standard-input:Error:unknown-pseudo-op:lc
|-- sparc-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
|-- x86_64-allyesconfig
| |-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| |-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
| |-- drivers-gpu-drm-bridge-adv7511-adv7511.h:warning:ADV7511_REG_CEC_RX_FRAME_HDR-defined-but-not-used
| |-- drivers-gpu-drm-bridge-adv7511-adv7511.h:warning:ADV7511_REG_CEC_RX_FRAME_LEN-defined-but-not-used
| `-- drivers-gpu-drm-solomon-ssd13-spi.c:warning:ssd13_spi_table-defined-but-not-used
|-- x86_64-kexec
| `-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
|-- x86_64-randconfig-a012-20220516
| |-- drivers-gpu-drm-bridge-adv7511-adv7511.h:warning:ADV7511_REG_CEC_RX_FRAME_HDR-defined-but-not-used
| `-- drivers-gpu-drm-bridge-adv7511-adv7511.h:warning:ADV7511_REG_CEC_RX_FRAME_LEN-defined-but-not-used
|-- x86_64-randconfig-a014-20220516
| `-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
|-- x86_64-randconfig-c002-20220516
| `-- command-line:fatal-error:.-include-generated-utsrelease.h:No-such-file-or-directory
|-- x86_64-randconfig-m001-20220516
| |-- drivers-gpu-drm-i915-gt-intel_gt_sysfs_pm.c-sysfs_gt_attribute_w_func()-error:uninitialized-symbol-ret-.
| `-- kernel-bpf-verifier.c-process_kptr_func()-warn:passing-zero-to-PTR_ERR
|-- x86_64-rhel-8.3
| `-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
|-- x86_64-rhel-8.3-func
| `-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
|-- x86_64-rhel-8.3-kselftests
| `-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
|-- x86_64-rhel-8.3-kunit
| `-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
|-- x86_64-rhel-8.3-syz
| `-- arch-x86-kvm-pmu.h:warning:vmx_icl_pebs_cpu-defined-but-not-used
|-- xtensa-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:no-previous-prototype-for-dp_parse_lttpr_mode
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:variable-allow_lttpr_non_transparent_mode-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_discovery.c:warning:no-previous-prototype-for-amdgpu_discovery_get_mall_info
| `-- drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-soc21_grbm_select
`-- xtensa-randconfig-p002-20220516
|-- drivers-opp-core.c:warning:Uninitialized-variable:iter-rate-uninitvar
|-- drivers-opp-core.c:warning:Uninitialized-variable:opp-available-uninitvar
|-- drivers-opp-core.c:warning:Uninitialized-variable:temp-removed-uninitvar
|-- drivers-opp-core.c:warning:Uninitialized-variable:temp_opp-available-uninitvar
|-- drivers-opp-core.c:warning:Uninitialized-variable:temp_opp-level-uninitvar
|-- drivers-opp-core.c:warning:Uninitialized-variable:tmp_opp-rate-uninitvar
`-- drivers-opp-core.c:warning:Uninitialized-variables:opp_table.node-opp_table.lazy-opp_table.head-opp_table.dev_list-opp_table.opp_list-opp_table.kref-opp_table.lock-opp_table.np-opp_table.clock_latency
clang_recent_errors
|-- arm64-randconfig-r001-20220516
| `-- arch-arm64-kvm-pmu.c:warning:tentative-definition-of-variable-with-internal-linkage-has-incomplete-non-array-type-typeof(struct-kvm_pmu_events)-(aka-struct-kvm_pmu_events-)
|-- hexagon-randconfig-r045-20220516
| |-- fs-buffer.c:warning:stack-frame-size-()-exceeds-limit-()-in-block_read_full_folio
| `-- fs-ntfs-aops.c:warning:stack-frame-size-()-exceeds-limit-()-in-ntfs_read_folio
|-- i386-randconfig-r004-20220516
| `-- ERROR:__udivdi3-drivers-mtd-parsers-scpart.ko-undefined
`-- riscv-randconfig-r036-20220516
`-- arch-riscv-include-asm-tlbflush.h:error:expected-assembly-time-absolute-expression
elapsed time: 728m
configs tested: 104
configs skipped: 3
gcc tested configs:
arm allmodconfig
arm allyesconfig
arm defconfig
arm64 defconfig
arm64 allyesconfig
i386 randconfig-c001-20220516
ia64 tiger_defconfig
mips gpr_defconfig
mips bmips_be_defconfig
arm spear6xx_defconfig
powerpc maple_defconfig
sh kfr2r09-romimage_defconfig
mips db1xxx_defconfig
powerpc cm5200_defconfig
sh se7619_defconfig
xtensa audio_kc705_defconfig
sh se7780_defconfig
sh se7705_defconfig
powerpc sequoia_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allyesconfig
m68k allmodconfig
m68k defconfig
alpha defconfig
csky defconfig
alpha allyesconfig
nios2 allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
xtensa allyesconfig
parisc defconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
s390 allyesconfig
parisc64 defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
i386 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
nios2 defconfig
arc allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allnoconfig
powerpc allmodconfig
powerpc allyesconfig
x86_64 randconfig-a012-20220516
x86_64 randconfig-a011-20220516
x86_64 randconfig-a013-20220516
x86_64 randconfig-a014-20220516
x86_64 randconfig-a016-20220516
x86_64 randconfig-a015-20220516
i386 randconfig-a011-20220516
i386 randconfig-a013-20220516
i386 randconfig-a015-20220516
i386 randconfig-a012-20220516
i386 randconfig-a016-20220516
i386 randconfig-a014-20220516
arc randconfig-r043-20220516
riscv randconfig-r042-20220516
s390 randconfig-r044-20220516
riscv allnoconfig
riscv allyesconfig
riscv allmodconfig
riscv nommu_k210_defconfig
riscv rv32_defconfig
riscv nommu_virt_defconfig
riscv defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 kexec
x86_64 rhel-8.3-syz
x86_64 rhel-8.3-func
x86_64 rhel-8.3
x86_64 rhel-8.3-kunit
clang tested configs:
arm orion5x_defconfig
arm aspeed_g4_defconfig
powerpc katmai_defconfig
powerpc microwatt_defconfig
powerpc akebono_defconfig
powerpc mvme5100_defconfig
i386 randconfig-a003-20220516
i386 randconfig-a001-20220516
i386 randconfig-a004-20220516
i386 randconfig-a006-20220516
i386 randconfig-a002-20220516
i386 randconfig-a005-20220516
x86_64 randconfig-a002-20220516
x86_64 randconfig-a001-20220516
x86_64 randconfig-a003-20220516
x86_64 randconfig-a005-20220516
x86_64 randconfig-a004-20220516
x86_64 randconfig-a006-20220516
hexagon randconfig-r045-20220516
hexagon randconfig-r041-20220516
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply
* linux-next: build warning after merge of the net-next tree
From: Stephen Rothwell @ 2022-05-17 1:03 UTC (permalink / raw)
To: David Miller, Networking
Cc: Florian Westphal, Pablo Neira Ayuso, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
net/netfilter/nf_conntrack_netlink.c:1717:12: warning: 'ctnetlink_dump_one_entry' defined but not used [-Wunused-function]
1717 | static int ctnetlink_dump_one_entry(struct sk_buff *skb,
| ^~~~~~~~~~~~~~~~~~~~~~~~
Introduced by commit
8a75a2c17410 ("netfilter: conntrack: remove unconfirmed list")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next v4 1/7] bpf: add bpf_skc_to_mptcp_sock_proto
From: Martin KaFai Lau @ 2022-05-17 1:07 UTC (permalink / raw)
To: Geliang Tang, Mat Martineau
Cc: netdev, bpf, ast, daniel, andrii, mptcp, Nicolas Rybowski,
Matthieu Baerts
In-Reply-To: <20220513224827.662254-2-mathew.j.martineau@linux.intel.com>
On Fri, May 13, 2022 at 03:48:21PM -0700, Mat Martineau wrote:
[ ... ]
> diff --git a/include/net/mptcp.h b/include/net/mptcp.h
> index 8b1afd6f5cc4..2ba09de955c7 100644
> --- a/include/net/mptcp.h
> +++ b/include/net/mptcp.h
> @@ -284,4 +284,10 @@ static inline int mptcpv6_init(void) { return 0; }
> static inline void mptcpv6_handle_mapped(struct sock *sk, bool mapped) { }
> #endif
>
> +#if defined(CONFIG_MPTCP) && defined(CONFIG_BPF_SYSCALL)
> +struct mptcp_sock *bpf_mptcp_sock_from_subflow(struct sock *sk);
Can this be inline ?
> +#else
> +static inline struct mptcp_sock *bpf_mptcp_sock_from_subflow(struct sock *sk) { return NULL; }
> +#endif
> +
> #endif /* __NET_MPTCP_H */
[ ... ]
> diff --git a/net/mptcp/bpf.c b/net/mptcp/bpf.c
> new file mode 100644
> index 000000000000..535602ba2582
> --- /dev/null
> +++ b/net/mptcp/bpf.c
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Multipath TCP
> + *
> + * Copyright (c) 2020, Tessares SA.
> + * Copyright (c) 2022, SUSE.
> + *
> + * Author: Nicolas Rybowski <nicolas.rybowski@tessares.net>
> + */
> +
> +#define pr_fmt(fmt) "MPTCP: " fmt
> +
> +#include <linux/bpf.h>
> +#include "protocol.h"
> +
> +struct mptcp_sock *bpf_mptcp_sock_from_subflow(struct sock *sk)
> +{
> + if (sk && sk_fullsock(sk) && sk->sk_protocol == IPPROTO_TCP && sk_is_mptcp(sk))
> + return mptcp_sk(mptcp_subflow_ctx(sk)->conn);
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL(bpf_mptcp_sock_from_subflow);
Is EXPORT_SYMBOL needed ?
^ permalink raw reply
* Re: Re: [PATCH net] NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc
From: duoming @ 2022-05-17 1:10 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, krzysztof.kozlowski, linux-kernel, davem, edumazet,
pabeni, gregkh, alexander.deucher, broonie
In-Reply-To: <20220516130705.2d51a6cf@kernel.org>
Hello,
On Mon, 16 May 2022 13:07:05 -0700 Jakub Kicinski wrote:
> On Fri, 13 May 2022 21:33:55 +0800 Duoming Zhou wrote:
> > Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation ")
> > Fixes: 11f54f228643 ("NFC: nci: Add HCI over NCI protocol support")
>
> Are there more bad callers? If st_nci_se_wt_timeout is the only source
> of trouble then the fixes tag should point to when it was added, rather
> than when the callee was added.
The st_nci_se_wt_timeout is the only source of trouble, it was added in
ed06aeefdac3 ("nfc: st-nci: Rename st21nfcb to st-nci"). I will send
patch v2.
Best regards,
Duoming Zhou
^ permalink raw reply
* Re: [PATCH RESEND net] bonding: fix missed rcu protection
From: Jakub Kicinski @ 2022-05-17 1:10 UTC (permalink / raw)
To: Hangbin Liu
Cc: netdev, Jay Vosburgh, Veaceslav Falico, Andy Gospodarek,
David S . Miller, David Ahern, Jonathan Toppins, Eric Dumazet,
Paolo Abeni, syzbot+92beb3d46aab498710fa, Vladimir Oltean
In-Reply-To: <20220513103350.384771-1-liuhangbin@gmail.com>
On Fri, 13 May 2022 18:33:50 +0800 Hangbin Liu wrote:
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 38e152548126..3a6f879ad7a9 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -5591,16 +5591,20 @@ static int bond_ethtool_get_ts_info(struct net_device *bond_dev,
> const struct ethtool_ops *ops;
> struct net_device *real_dev;
> struct phy_device *phydev;
> + int ret = 0;
>
> + rcu_read_lock();
> real_dev = bond_option_active_slave_get_rcu(bond);
> if (real_dev) {
> ops = real_dev->ethtool_ops;
> phydev = real_dev->phydev;
>
> if (phy_has_tsinfo(phydev)) {
> - return phy_ts_info(phydev, info);
> + ret = phy_ts_info(phydev, info);
> + goto out;
> } else if (ops->get_ts_info) {
> - return ops->get_ts_info(real_dev, info);
> + ret = ops->get_ts_info(real_dev, info);
> + goto out;
> }
> }
Can't ->get_ts_info sleep now? It'd be a little sad to force it
to be atomic just because of one upper dev trying to be fancy.
Maybe all we need to do is to take a ref on the real_dev?
Also please add a Link: to the previous discussion, it'd have been
useful to get the context in which Vladimir suggested this.
^ permalink raw reply
* Re: [PATCH bpf 1/4] bpf_trace: check size for overflow in bpf_kprobe_multi_link_attach
From: Alexei Starovoitov @ 2022-05-17 1:14 UTC (permalink / raw)
To: Eugene Syromiatnikov
Cc: Jiri Olsa, Masami Hiramatsu, Steven Rostedt, Ingo Molnar,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, netdev, bpf, linux-kernel, Shuah Khan, linux-kselftest
In-Reply-To: <20220516224934.GA5013@asgard.redhat.com>
On Tue, May 17, 2022 at 12:49:34AM +0200, Eugene Syromiatnikov wrote:
> On Mon, May 16, 2022 at 11:34:45PM +0200, Jiri Olsa wrote:
> > On Mon, May 16, 2022 at 08:27:08PM +0200, Eugene Syromiatnikov wrote:
> > > + if (check_mul_overflow(cnt, sizeof(*syms), &size))
> > > + return -EOVERFLOW;
> >
> > there was an update already:
> >
> > 0236fec57a15 bpf: Resolve symbols with ftrace_lookup_symbols for kprobe multi link
> >
> > so this won't apply anymore, could you please rebase on top of the latest bpf-next/master?
>
> The issue that this specific check has to go in 4.18, as it covers
> possible out-of-bounds write, I'm not sure how to handle it, have
> a branch where it is merged manually?
As Jiri said, please use bpf-next.
^ permalink raw reply
* Re: [PATCH bpf-next v4 3/7] selftests/bpf: add MPTCP test base
From: Martin KaFai Lau @ 2022-05-17 1:18 UTC (permalink / raw)
To: Mat Martineau
Cc: netdev, bpf, Nicolas Rybowski, ast, daniel, andrii, mptcp,
Matthieu Baerts, Geliang Tang
In-Reply-To: <20220513224827.662254-4-mathew.j.martineau@linux.intel.com>
On Fri, May 13, 2022 at 03:48:23PM -0700, Mat Martineau wrote:
[ ... ]
> @@ -265,7 +282,7 @@ int connect_to_fd_opts(int server_fd, const struct network_helper_opts *opts)
> }
>
> addr_in = (struct sockaddr_in *)&addr;
> - fd = socket(addr_in->sin_family, type, 0);
> + fd = socket(addr_in->sin_family, type, opts->protocol);
ops->protocol is the same as the server_fd's protocol ?
Can that be learned from getsockopt(server_fd, SOL_SOCKET, SO_PROTOCOL, ....) ?
Then the ops->protocol additions and related changes are not needed.
connect_to_fd_opts() has already obtained the SO_TYPE in similar way.
> if (fd < 0) {
> log_err("Failed to create client socket");
> return -1;
> @@ -298,6 +315,16 @@ int connect_to_fd(int server_fd, int timeout_ms)
> return connect_to_fd_opts(server_fd, &opts);
> }
>
> +int connect_to_mptcp_fd(int server_fd, int timeout_ms)
> +{
> + struct network_helper_opts opts = {
> + .timeout_ms = timeout_ms,
> + .protocol = IPPROTO_MPTCP,
> + };
> +
> + return connect_to_fd_opts(server_fd, &opts);
> +}
> +
> int connect_fd_to_fd(int client_fd, int server_fd, int timeout_ms)
> {
> struct sockaddr_storage addr;
> diff --git a/tools/testing/selftests/bpf/network_helpers.h b/tools/testing/selftests/bpf/network_helpers.h
> index a4b3b2f9877b..e0feb115b2ae 100644
> --- a/tools/testing/selftests/bpf/network_helpers.h
> +++ b/tools/testing/selftests/bpf/network_helpers.h
> @@ -21,6 +21,7 @@ struct network_helper_opts {
> const char *cc;
> int timeout_ms;
> bool must_fail;
> + int protocol;
> };
>
> /* ipv4 test vector */
> @@ -42,11 +43,14 @@ extern struct ipv6_packet pkt_v6;
> int settimeo(int fd, int timeout_ms);
> int start_server(int family, int type, const char *addr, __u16 port,
> int timeout_ms);
> +int start_mptcp_server(int family, const char *addr, __u16 port,
> + int timeout_ms);
> int *start_reuseport_server(int family, int type, const char *addr_str,
> __u16 port, int timeout_ms,
> unsigned int nr_listens);
> void free_fds(int *fds, unsigned int nr_close_fds);
> int connect_to_fd(int server_fd, int timeout_ms);
> +int connect_to_mptcp_fd(int server_fd, int timeout_ms);
> int connect_to_fd_opts(int server_fd, const struct network_helper_opts *opts);
> int connect_fd_to_fd(int client_fd, int server_fd, int timeout_ms);
> int fastopen_connect(int server_fd, const char *data, unsigned int data_len,
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: Fix unmet direct dependencies detected for NVMEM_SUNPLUS_OCOTP
From: patchwork-bot+netdevbpf @ 2022-05-17 1:20 UTC (permalink / raw)
To: Wells Lu; +Cc: davem, edumazet, kuba, pabeni, netdev, linux-kernel, wells.lu
In-Reply-To: <1652443036-24731-1-git-send-email-wellslutw@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 13 May 2022 19:57:16 +0800 you wrote:
> Removed unnecessary:
>
> select COMMON_CLK_SP7021
> select RESET_SUNPLUS
> select NVMEM_SUNPLUS_OCOTP
>
> from Kconfig.
>
> [...]
Here is the summary with links:
- [net-next] net: ethernet: Fix unmet direct dependencies detected for NVMEM_SUNPLUS_OCOTP
https://git.kernel.org/netdev/net-next/c/6251264fedde
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH bpf-next v4 4/7] selftests/bpf: test bpf_skc_to_mptcp_sock
From: Martin KaFai Lau @ 2022-05-17 1:20 UTC (permalink / raw)
To: Geliang Tang, Mat Martineau
Cc: netdev, bpf, ast, daniel, andrii, mptcp, Matthieu Baerts
In-Reply-To: <20220513224827.662254-5-mathew.j.martineau@linux.intel.com>
On Fri, May 13, 2022 at 03:48:24PM -0700, Mat Martineau wrote:
[ ... ]
> diff --git a/tools/testing/selftests/bpf/progs/mptcp_sock.c b/tools/testing/selftests/bpf/progs/mptcp_sock.c
> index bc09dba0b078..3feb7ff578e2 100644
> --- a/tools/testing/selftests/bpf/progs/mptcp_sock.c
> +++ b/tools/testing/selftests/bpf/progs/mptcp_sock.c
> @@ -7,6 +7,7 @@
> #include "bpf_tcp_helpers.h"
>
> char _license[] SEC("license") = "GPL";
> +extern bool CONFIG_MPTCP __kconfig;
>
> struct mptcp_storage {
> __u32 invoked;
> @@ -24,6 +25,7 @@ SEC("sockops")
> int _sockops(struct bpf_sock_ops *ctx)
> {
> struct mptcp_storage *storage;
> + struct mptcp_sock *msk;
> int op = (int)ctx->op;
> struct tcp_sock *tsk;
> struct bpf_sock *sk;
> @@ -41,11 +43,24 @@ int _sockops(struct bpf_sock_ops *ctx)
> return 1;
>
> is_mptcp = bpf_core_field_exists(tsk->is_mptcp) ? tsk->is_mptcp : 0;
> - storage = bpf_sk_storage_get(&socket_storage_map, sk, 0,
> - BPF_SK_STORAGE_GET_F_CREATE);
> - if (!storage)
> - return 1;
> + if (!is_mptcp) {
> + storage = bpf_sk_storage_get(&socket_storage_map, sk, 0,
> + BPF_SK_STORAGE_GET_F_CREATE);
> + if (!storage)
> + return 1;
> + } else {
> + if (!CONFIG_MPTCP)
hmm... how is it possible ? The above just tested "!is_mptcp".
> + return 1;
> +
> + msk = bpf_skc_to_mptcp_sock(sk);
> + if (!msk)
> + return 1;
>
> + storage = bpf_sk_storage_get(&socket_storage_map, msk, 0,
> + BPF_SK_STORAGE_GET_F_CREATE);
> + if (!storage)
> + return 1;
> + }
> storage->invoked++;
> storage->is_mptcp = is_mptcp;
>
> --
> 2.36.1
>
^ permalink raw reply
* [PATCH net v2] NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc
From: Duoming Zhou @ 2022-05-17 1:25 UTC (permalink / raw)
To: linux-kernel, kuba
Cc: krzysztof.kozlowski, davem, edumazet, pabeni, gregkh,
alexander.deucher, broonie, netdev, Duoming Zhou
There are sleep in atomic context bugs when the request to secure
element of st-nci is timeout. The root cause is that nci_skb_alloc
with GFP_KERNEL parameter is called in st_nci_se_wt_timeout which is
a timer handler. The call paths that could trigger bugs are shown below:
(interrupt context 1)
st_nci_se_wt_timeout
nci_hci_send_event
nci_hci_send_data
nci_skb_alloc(..., GFP_KERNEL) //may sleep
(interrupt context 2)
st_nci_se_wt_timeout
nci_hci_send_event
nci_hci_send_data
nci_send_data
nci_queue_tx_data_frags
nci_skb_alloc(..., GFP_KERNEL) //may sleep
This patch changes allocation mode of nci_skb_alloc from GFP_KERNEL to
GFP_ATOMIC in order to prevent atomic context sleeping. The GFP_ATOMIC
flag makes memory allocation operation could be used in atomic context.
Fixes: ed06aeefdac3 ("nfc: st-nci: Rename st21nfcb to st-nci")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
---
Changes in v2:
- Change the Fixes tag to commit st_nci_se_wt_timeout was added.
net/nfc/nci/data.c | 2 +-
net/nfc/nci/hci.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index 6055dc9a82a..aa5e712adf0 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -118,7 +118,7 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
skb_frag = nci_skb_alloc(ndev,
(NCI_DATA_HDR_SIZE + frag_len),
- GFP_KERNEL);
+ GFP_ATOMIC);
if (skb_frag == NULL) {
rc = -ENOMEM;
goto free_exit;
diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
index 19703a649b5..78c4b6addf1 100644
--- a/net/nfc/nci/hci.c
+++ b/net/nfc/nci/hci.c
@@ -153,7 +153,7 @@ static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe,
i = 0;
skb = nci_skb_alloc(ndev, conn_info->max_pkt_payload_len +
- NCI_DATA_HDR_SIZE, GFP_KERNEL);
+ NCI_DATA_HDR_SIZE, GFP_ATOMIC);
if (!skb)
return -ENOMEM;
@@ -184,7 +184,7 @@ static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe,
if (i < data_len) {
skb = nci_skb_alloc(ndev,
conn_info->max_pkt_payload_len +
- NCI_DATA_HDR_SIZE, GFP_KERNEL);
+ NCI_DATA_HDR_SIZE, GFP_ATOMIC);
if (!skb)
return -ENOMEM;
--
2.17.1
^ permalink raw reply related
* [PATCH] sfc/siena: fix driver suspend/resume methods
From: Peng Wu @ 2022-05-17 1:23 UTC (permalink / raw)
To: davem, edumazet, kuba, hkallweit1, bhelgaas
Cc: netdev, linux-kernel, liwei391, wupeng58
Fix the missing pci_disable_device() before return
from efx_pm_resume() in the error handling case.
Meanwhile, drivers should do this:
.resume()
pci_enable_device()
.suspend()
pci_disable_device()
Signed-off-by: Peng Wu <wupeng58@huawei.com>
---
drivers/net/ethernet/sfc/siena/efx.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/siena/efx.c b/drivers/net/ethernet/sfc/siena/efx.c
index 63d999e63960..4c0ab91914f2 100644
--- a/drivers/net/ethernet/sfc/siena/efx.c
+++ b/drivers/net/ethernet/sfc/siena/efx.c
@@ -1216,21 +1216,26 @@ static int efx_pm_resume(struct device *dev)
pci_set_master(efx->pci_dev);
rc = efx->type->reset(efx, RESET_TYPE_ALL);
if (rc)
- return rc;
+ goto out;
down_write(&efx->filter_sem);
rc = efx->type->init(efx);
up_write(&efx->filter_sem);
if (rc)
- return rc;
+ goto out;
rc = efx_pm_thaw(dev);
return rc;
+out:
+ pci_disable_device(pci_dev);
+ return rc;
}
static int efx_pm_suspend(struct device *dev)
{
+ struct pci_dev *pci_dev = to_pci_dev(dev);
int rc;
efx_pm_freeze(dev);
+ pci_disable_device(pci_dev);
rc = efx_pm_poweroff(dev);
if (rc)
efx_pm_resume(dev);
--
2.17.1
^ permalink raw reply related
* [PATCHv2 net-next] dn_route: set rt neigh to blackhole_netdev instead of loopback_dev in ifdown
From: Xin Long @ 2022-05-17 1:30 UTC (permalink / raw)
To: network dev; +Cc: davem, kuba, Eric Dumazet
Like other places in ipv4/6 dst ifdown, change to use blackhole_netdev
instead of pernet loopback_dev in dn dst ifdown.
v1->v2:
- remove the improper fixes tag as Eric noticed.
- aim at net-next.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/decnet/dn_route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index d1d78a463a06..552a53f1d5d0 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -159,7 +159,7 @@ static void dn_dst_ifdown(struct dst_entry *dst, struct net_device *dev, int how
struct neighbour *n = rt->n;
if (n && n->dev == dev) {
- n->dev = dev_net(dev)->loopback_dev;
+ n->dev = blackhole_netdev;
dev_hold(n->dev);
dev_put(dev);
}
--
2.31.1
^ permalink raw reply related
* Re: [PATCH bpf-next v4 5/7] selftests/bpf: verify token of struct mptcp_sock
From: Martin KaFai Lau @ 2022-05-17 1:32 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang
Cc: netdev, bpf, ast, daniel, andrii, mptcp, Matthieu Baerts
In-Reply-To: <20220513224827.662254-6-mathew.j.martineau@linux.intel.com>
On Fri, May 13, 2022 at 03:48:25PM -0700, Mat Martineau wrote:
[ ... ]
> +/*
> + * Parse the token from the output of 'ip mptcp monitor':
> + *
> + * [ CREATED] token=3ca933d3 remid=0 locid=0 saddr4=127.0.0.1 ...
> + * [ CREATED] token=2ab57040 remid=0 locid=0 saddr4=127.0.0.1 ...
How stable is the string format ?
If it happens to have some unrelated mptcp connection going on, will the test
break ?
> + */
> +static __u32 get_msk_token(void)
> +{
> + char *prefix = "[ CREATED] token=";
> + char buf[BUFSIZ] = {};
> + __u32 token = 0;
> + ssize_t len;
> + int fd;
> +
> + sync();
> +
> + fd = open(monitor_log_path, O_RDONLY);
> + if (!ASSERT_GE(fd, 0, "Failed to open monitor_log_path"))
> + return token;
> +
> + len = read(fd, buf, sizeof(buf));
> + if (!ASSERT_GT(len, 0, "Failed to read monitor_log_path"))
> + goto err;
> +
> + if (strncmp(buf, prefix, strlen(prefix))) {
> + log_err("Invalid prefix %s", buf);
> + goto err;
> + }
> +
> + token = strtol(buf + strlen(prefix), NULL, 16);
> +
> +err:
> + close(fd);
> + return token;
> +}
> +
^ permalink raw reply
* [PATCH] st/cw1200: cleanup the code a bit
From: Bernard Zhao @ 2022-05-17 1:41 UTC (permalink / raw)
To: Solomon Peachy, Kalle Valo, David S. Miller, Jakub Kicinski,
Paolo Abeni, linux-wireless, netdev, linux-kernel
Cc: zhaojunkui2008, Bernard Zhao
Delete if NULL check before dev_kfree_skb call.
This change is to cleanup the code a bit.
Signed-off-by: Bernard Zhao <bernard@vivo.com>
---
drivers/net/wireless/st/cw1200/bh.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/st/cw1200/bh.c b/drivers/net/wireless/st/cw1200/bh.c
index 10e019cddcc6..3b4ded2ac801 100644
--- a/drivers/net/wireless/st/cw1200/bh.c
+++ b/drivers/net/wireless/st/cw1200/bh.c
@@ -327,18 +327,12 @@ static int cw1200_bh_rx_helper(struct cw1200_common *priv,
if (WARN_ON(wsm_handle_rx(priv, wsm_id, wsm, &skb_rx)))
goto err;
- if (skb_rx) {
- dev_kfree_skb(skb_rx);
- skb_rx = NULL;
- }
+ dev_kfree_skb(skb_rx);
return 0;
err:
- if (skb_rx) {
- dev_kfree_skb(skb_rx);
- skb_rx = NULL;
- }
+ dev_kfree_skb(skb_rx);
return -1;
}
--
2.33.1
^ permalink raw reply related
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c
From: Vincent MAILHOL @ 2022-05-17 1:50 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Marc Kleine-Budde, linux-can, linux-kernel, Max Staudt, netdev
In-Reply-To: <7b1644ad-c117-881e-a64f-35b8d8b40ef7@hartkopp.net>
Hi Oliver,
On Mon. 16 May 2022 at 04:17, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Hi Vincent,
>
> On 14.05.22 16:16, Vincent Mailhol wrote:
> > The functions can_dropped_invalid_skb() and can_skb_headroom_valid()
> > grew a lot over the years to a point which it does not make much sense
> > to have them defined as static inline in header files. Move those two
> > functions to the .c counterpart of skb.h.
> >
> > can_skb_headroom_valid() only caller being can_dropped_invalid_skb(),
> > the declaration is removed from the header. Only
> > can_dropped_invalid_skb() gets its symbol exported.
>
> I can see your point but the need for can-dev was always given for
> hardware specific stuff like bitrates, TDC, transceivers, whatever.
I also see your point :)
Actually, I raised the exact same idea in a previous message:
https://lore.kernel.org/linux-can/CAMZ6RqLU-Wg0Cau3cM=QsU-t-7Lyzmo1nJ_VAA4Mbw3u0jnNtw@mail.gmail.com/
But you were not in CC and it seems that there is a lot of congestion
recently on the mailing list so I wouldn’t be surprised if you tell me
you did not receive it.
> As there would be more things in slcan (e.g. dev_alloc_skb() could be
> unified with alloc_can_skb())
And also the can_{put,get}_echo_skb() I guess.
> would it probably make sense to
> introduce a new can-skb module that could be used by all CAN
> virtual/software interfaces?
>
> Or some other split-up ... any idea?
My concern is: what would be the merrit? If we do not split, the users
of slcan and v(x)can would have to load the can-dev module which will
be slightly bloated for their use, but is this really an issue? I do
not see how this can become a performance bottleneck, so what is the
problem?
I could also argue that most of the devices do not depend on
rx-offload.o. So should we also split this one out of can-dev on the
same basis and add another module dependency?
The benefit (not having to load a bloated module for three drivers)
does not outweigh the added complexity: all hardware modules will have
one additional modprobe dependency on the tiny can-skb module.
But as said above, I am not fully opposed to the split, I am just
strongly divided. If we go for the split, creating a can-skb module is
the natural and only option I see.
If the above argument does not convince you, I will send a v3 with that split.
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH net-next v3 02/10] ptp: ocp: add Celestica timecard PCI ids
From: Jonathan Lemon @ 2022-05-17 1:46 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, richardcochran, davem, pabeni, edumazet, kernel-team
In-Reply-To: <20220516174303.73de08ae@kernel.org>
On Mon, May 16, 2022 at 05:43:03PM -0700, Jakub Kicinski wrote:
> On Fri, 13 May 2022 15:59:16 -0700 Jonathan Lemon wrote:
> > +#ifndef PCI_VENDOR_ID_CELESTICA
> > +#define PCI_VENDOR_ID_CELESTICA 0x18d4
> > +#endif
> > +
> > +#ifndef PCI_DEVICE_ID_CELESTICA_TIMECARD
> > +#define PCI_DEVICE_ID_CELESTICA_TIMECARD 0x1008
> > +#endif
>
> The ifdefs are unnecessary, these kind of constructs are often used out
> of tree when one does not control the headers, but not sure what purpose
> they'd serve upstream?
include/linux/pci_ids.h says:
* Do not add new entries to this file unless the definitions
* are shared between multiple drivers.
Neither FACEBOOK (0x1d9b) nor CELESTICA (0x18d4) are present
in this file. This seems to a common idiom in several other
drivers. Picking one at random:
gve.h:#define PCI_VENDOR_ID_GOOGLE 0x1ae0
So these #defines are needed.
--
Jonathan
^ permalink raw reply
* Re: [PATCH net-next v3 08/10] ptp: ocp: fix PPS source selector reporting
From: Jonathan Lemon @ 2022-05-17 1:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, richardcochran, davem, pabeni, edumazet, kernel-team
In-Reply-To: <20220516174317.457ec2d1@kernel.org>
On Mon, May 16, 2022 at 05:43:17PM -0700, Jakub Kicinski wrote:
> On Fri, 13 May 2022 15:59:22 -0700 Jonathan Lemon wrote:
> > The NTL timecard design has a PPS1 selector which selects the
> > the PPS source automatically, according to Section 1.9 of the
> > documentation.
> >
> > If there is a SMA PPS input detected:
> > - send signal to MAC and PPS slave selector.
> >
> > If there is a MAC PPS input detected:
> > - send GNSS1 to the MAC
> > - send MAC to the PPS slave
> >
> > If there is a GNSS1 input detected:
> > - send GNSS1 to the MAC
> > - send GNSS1 to the PPS slave.MAC
> >
> > Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
>
> This one and patch 10 need Fixes tags
This is for a debugfs entry. I disagree that a Fixes: tag
is needed here.
I'll do it for patch 10 if you insist, but this only happens
if ptp_clock_register() fails, which not normally seen.
--
Jonathan
^ permalink raw reply
* 答复: 答复: [PATCH bpf-next] samples/bpf: check detach prog exist or not in xdp_fwd
From: shaozhengchao @ 2022-05-17 2:00 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, bpf@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
ast@kernel.org, daniel@iogearbox.net, davem@davemloft.net,
kuba@kernel.org, hawk@kernel.org, john.fastabend@gmail.com,
andrii@kernel.org, kafai@fb.com, songliubraving@fb.com,
yhs@fb.com, kpsingh@kernel.org
Cc: weiyongjun (A), yuehaibing
In-Reply-To: <87h75zynz2.fsf@toke.dk>
-----邮件原件-----
发件人: Toke Høiland-Jørgensen [mailto:toke@kernel.org]
发送时间: 2022年5月9日 18:55
收件人: shaozhengchao <shaozhengchao@huawei.com>; bpf@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; ast@kernel.org; daniel@iogearbox.net; davem@davemloft.net; kuba@kernel.org; hawk@kernel.org; john.fastabend@gmail.com; andrii@kernel.org; kafai@fb.com; songliubraving@fb.com; yhs@fb.com; kpsingh@kernel.org
抄送: weiyongjun (A) <weiyongjun1@huawei.com>; yuehaibing <yuehaibing@huawei.com>
主题: Re: 答复: [PATCH bpf-next] samples/bpf: check detach prog exist or not in xdp_fwd
shaozhengchao <shaozhengchao@huawei.com> writes:
> -----邮件原件-----
> 发件人: Toke Høiland-Jørgensen [mailto:toke@kernel.org]
> 发送时间: 2022年5月9日 17:46
> 收件人: shaozhengchao <shaozhengchao@huawei.com>; bpf@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; ast@kernel.org;
> daniel@iogearbox.net; davem@davemloft.net; kuba@kernel.org;
> hawk@kernel.org; john.fastabend@gmail.com; andrii@kernel.org;
> kafai@fb.com; songliubraving@fb.com; yhs@fb.com; kpsingh@kernel.org
> 抄送: weiyongjun (A) <weiyongjun1@huawei.com>; shaozhengchao
> <shaozhengchao@huawei.com>; yuehaibing <yuehaibing@huawei.com>
> 主题: Re: [PATCH bpf-next] samples/bpf: check detach prog exist or not
> in xdp_fwd
>
> Zhengchao Shao <shaozhengchao@huawei.com> writes:
>
>> Before detach the prog, we should check detach prog exist or not.
>
> If we're adding such a check we should also check that it's the *right* program. I.e., query the ID for the program name and check that it matches what the program attached, then obtain an fd and pass that as XDP_EXPECTED_FD on detach to make sure it wasn't swapped out in the meantime...
>
> -Toke
>
> Thank you for your reply. When finish running xdp_fwd to attatch prog,
> the program will exit and can't store fd as XDP_EXPECTED_FD.
>
> I think the sample xdp_fwd -d is just detach prog and don't care if
> the fd is expected.
So why are you adding the check? Either keep it the way it is, or add a proper check that examines the program type; you're right that it doesn't store the prog FD, but you can still check the program name and see if it matches to get some idea that it's not a totally separate program that's loaded. I think doing so would be an improvement to the sample, but just adding a check if a program is loaded is not, really...
-Toke
Could I add helper function to implement this function which can check the program name and see if it attach to the device.
-Zhengchao Shao
^ permalink raw reply
* Re: [RFC PATCH bpf-next v2 2/7] cgroup: bpf: flush bpf stats on rstat flush
From: Alexei Starovoitov @ 2022-05-17 2:08 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Hao Luo, Tejun Heo, Zefan Li, Johannes Weiner,
Shuah Khan, Roman Gushchin, Michal Hocko, Stanislav Fomichev,
David Rientjes, Greg Thelen, Shakeel Butt, linux-kernel, netdev,
bpf, cgroups
In-Reply-To: <20220515023504.1823463-3-yosryahmed@google.com>
On Sun, May 15, 2022 at 02:34:59AM +0000, Yosry Ahmed wrote:
> +
> +void bpf_rstat_flush(struct cgroup *cgrp, int cpu)
> +{
> + struct bpf_rstat_flusher *flusher;
> + struct bpf_rstat_flush_ctx ctx = {
> + .cgrp = cgrp,
> + .parent = cgroup_parent(cgrp),
> + .cpu = cpu,
> + };
> +
> + rcu_read_lock();
> + migrate_disable();
> + spin_lock(&bpf_rstat_flushers_lock);
> +
> + list_for_each_entry(flusher, &bpf_rstat_flushers, list)
> + (void) bpf_prog_run(flusher->prog, &ctx);
> +
> + spin_unlock(&bpf_rstat_flushers_lock);
> + migrate_enable();
> + rcu_read_unlock();
> +}
> diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c
> index 24b5c2ab5598..0285d496e807 100644
> --- a/kernel/cgroup/rstat.c
> +++ b/kernel/cgroup/rstat.c
> @@ -2,6 +2,7 @@
> #include "cgroup-internal.h"
>
> #include <linux/sched/cputime.h>
> +#include <linux/bpf-rstat.h>
>
> static DEFINE_SPINLOCK(cgroup_rstat_lock);
> static DEFINE_PER_CPU(raw_spinlock_t, cgroup_rstat_cpu_lock);
> @@ -168,6 +169,7 @@ static void cgroup_rstat_flush_locked(struct cgroup *cgrp, bool may_sleep)
> struct cgroup_subsys_state *css;
>
> cgroup_base_stat_flush(pos, cpu);
> + bpf_rstat_flush(pos, cpu);
Please use the following approach instead:
__weak noinline void bpf_rstat_flush(struct cgroup *cgrp, struct cgroup *parent, int cpu)
{
}
and change above line to:
bpf_rstat_flush(pos, cgroup_parent(pos), cpu);
Then tracing bpf fentry progs will be able to attach to bpf_rstat_flush.
Pretty much the patches 1, 2, 3 are not necessary.
In patch 4 add bpf_cgroup_rstat_updated/flush as two kfuncs instead of stable helpers.
This way patches 1,2,3,4 will become 2 trivial patches and we will be
able to extend the interface between cgroup rstat and bpf whenever we need
without worrying about uapi stability.
We had similar discusison with HID subsystem that plans to use bpf in HID
with the same approach.
See this patch set:
https://lore.kernel.org/bpf/20220421140740.459558-2-benjamin.tissoires@redhat.com/
You'd need patch 1 from it to enable kfuncs for tracing.
Your patch 5 is needed as-is.
Yonghong,
please review it.
Different approach for patch 1-4 won't affect patch 5.
Patches 6 and 7 look good.
With this approach that patch 7 will mostly stay as-is. Instead of:
+SEC("rstat/flush")
+int vmscan_flush(struct bpf_rstat_flush_ctx *ctx)
+{
+ struct vmscan_percpu *pcpu_stat;
+ struct vmscan *total_stat, *parent_stat;
+ struct cgroup *cgrp = ctx->cgrp, *parent = ctx->parent;
it will become
SEC("fentry/bpf_rstat_flush")
int BPF_PROG(vmscan_flush, struct cgroup *cgrp, struct cgroup *parent, int cpu)
^ permalink raw reply
* Re: [PATCH net-next] net: ifdefy the wireless pointers in struct net_device
From: Florian Fainelli @ 2022-05-17 2:12 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, johannes, alex.aring, stefan,
mareklindner, sw, a, sven, linux-wireless, linux-wpan
In-Reply-To: <20220516215638.1787257-1-kuba@kernel.org>
On 5/16/2022 2:56 PM, Jakub Kicinski wrote:
> Most protocol-specific pointers in struct net_device are under
> a respective ifdef. Wireless is the notable exception. Since
> there's a sizable number of custom-built kernels for datacenter
> workloads which don't build wireless it seems reasonable to
> ifdefy those pointers as well.
>
> While at it move IPv4 and IPv6 pointers up, those are special
> for obvious reasons.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Could not we move to an union of pointers in the future since in many
cases a network device can only have one of those pointers at any given
time?
--
Florian
^ permalink raw reply
* [PATCH v3 3/3] igb_main: Assign random MAC address instead of fail in case of invalid one
From: lixue liang @ 2022-05-17 2:25 UTC (permalink / raw)
To: jesse.brandeburg, anthony.l.nguyen, kuba, davem, pabeni
Cc: netdev, linux-kernel, lixue liang
In some cases, when the user uses igb_set_eeprom to modify the MAC
address to be invalid, the igb driver will fail to load. If there is no
network card device, the user must modify it to a valid MAC address by
other means.
Since the MAC address can be modified, then add a random valid MAC address
to replace the invalid MAC address in the driver can be workable, it can
continue to finish the loading, and output the relevant log reminder.
Signed-off-by: lixue liang <lianglixue@greatwall.com.cn>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 746233befade..40f43534a3af 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3362,7 +3362,7 @@ static int igb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
eth_hw_addr_random(netdev);
ether_addr_copy(hw->mac.addr, netdev->dev_addr);
dev_err(&pdev->dev,
- "Invalid MAC Address, already assigned random MAC Address\n");
+ "Invalid MAC address, already assigned random MAC address\n");
}
igb_set_default_mac_filter(adapter);
--
2.27.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox