Re: [PATCH] tools/virtio:Fix the wrong format specifier
On Wed, Jul 24, 2024 at 12:41:08AM -0700, Zhu Jun wrote: > The unsigned int should use "%u" instead of "%d". > > Signed-off-by: Zhu Jun which matters why? > --- > tools/virtio/ringtest/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/virtio/ringtest/main.c b/tools/virtio/ringtest/main.c > index 5a18b2301a63..e471d8e7cfaa 100644 > --- a/tools/virtio/ringtest/main.c > +++ b/tools/virtio/ringtest/main.c > @@ -276,7 +276,7 @@ static void help(void) > fprintf(stderr, "Usage: [--help]" > " [--host-affinity H]" > " [--guest-affinity G]" > - " [--ring-size R (default: %d)]" > + " [--ring-size R (default: %u)]" > " [--run-cycles C (default: %d)]" > " [--batch b]" > " [--outstanding o]" > -- > 2.17.1 > >
Re: [PATCH] tools/virtio:Fix the wrong format specifier
On Wed, Jul 24, 2024 at 9:44 AM Zhu Jun wrote: > > The unsigned int should use "%u" instead of "%d". > > Signed-off-by: Zhu Jun Reviewed-by: Eugenio Pérez Thanks! > --- > tools/virtio/ringtest/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/virtio/ringtest/main.c b/tools/virtio/ringtest/main.c > index 5a18b2301a63..e471d8e7cfaa 100644 > --- a/tools/virtio/ringtest/main.c > +++ b/tools/virtio/ringtest/main.c > @@ -276,7 +276,7 @@ static void help(void) > fprintf(stderr, "Usage: [--help]" > " [--host-affinity H]" > " [--guest-affinity G]" > - " [--ring-size R (default: %d)]" > + " [--ring-size R (default: %u)]" > " [--run-cycles C (default: %d)]" > " [--batch b]" > " [--outstanding o]" > -- > 2.17.1 > > >
Re: [PATCH 1/2] uprobe: Change uretprobe syscall scope and number
On Wed, Jul 24, 2024, at 09:46, Dmitry V. Levin wrote: > On Fri, Jul 12, 2024 at 03:52:27PM +0200, Jiri Olsa wrote: >> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl >> b/arch/x86/entry/syscalls/syscall_64.tbl >> index 6452c2ec469a..dabf1982de6d 100644 >> --- a/arch/x86/entry/syscalls/syscall_64.tbl >> +++ b/arch/x86/entry/syscalls/syscall_64.tbl >> @@ -384,7 +384,7 @@ >> 460 common lsm_set_self_attr sys_lsm_set_self_attr >> 461 common lsm_list_modulessys_lsm_list_modules >> 462 common mseal sys_mseal >> -463 64 uretprobe sys_uretprobe >> +467 common uretprobe sys_uretprobe >> >> # >> # Due to a historical design error, certain syscalls are numbered >> differently > > Isn't include/uapi/asm-generic/unistd.h expected to be updated as well? > As of mainline commit v6.10-12246-g786c8248dbd3, it still contains > > #define __NR_uretprobe 463 The file is currently unused and replaced with scripts/syscall.tbl, my plan was to remove the old file in the 6.12 syscall cleanups. The number in scripts/syscall.tbl is now 467, so its users (arc, arm64, csky, hegagon, loongarch, nios2 openrisc and riscv) have the same number as on x86. However, the corresponding change did not make it into the other syscall.tbl files (alpha, arm, m68k, microblaze, parisc, powerpc, s390, sh, sparc and xtensa), which is rather inconsistent. I think we should definitely make all non-x86 architectures behave the same way, either with or without an entry for uretprobe. There are three ways do do this: a) remove it from both include/uapi/asm/unistd.h and scripts/syscall.tbl, and change the x86-64 system call to a private number such as 335 b) remove it from both include/uapi/asm/unistd.h and scripts/syscall.tbl, but leave the number at 467 c) add the syscall to all other architectures for consistency, but continue to have it return -ENOSYS. >From Linus' earlier comments, I would guess that a) would be the least bad of those. I'm also unsure about the status of the xattrat patches, which were the reason for changing uretprobe from 463 to 467. Those patches are still not merged either, and disappeared from linux-next between Friday and Monday. Arnd
Re: [PATCH 1/2] uprobe: Change uretprobe syscall scope and number
On Fri, Jul 12, 2024 at 03:52:27PM +0200, Jiri Olsa wrote:
> After discussing with Arnd [1] it's preferable to change uretprobe
> syscall number to 467 to omit the merge conflict with xattrat syscalls.
>
> Also changing the ABI to 'common' which will ease up the global
> scripts/syscall.tbl management. One consequence is we generate uretprobe
> syscall numbers for ABIs that do not support uretprobe syscall, but the
> syscall still returns -ENOSYS when called in that ABI.
>
> [1]
> https://lore.kernel.org/lkml/784a34e5-4654-44c9-9c07-f9f4ffd95...@app.fastmail.com/
>
> Fixes: 190fec72df4a ("uprobe: Wire up uretprobe system call")
> Suggested-by: Arnd Bergmann
> Signed-off-by: Jiri Olsa
> ---
> arch/x86/entry/syscalls/syscall_64.tbl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl
> b/arch/x86/entry/syscalls/syscall_64.tbl
> index 6452c2ec469a..dabf1982de6d 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -384,7 +384,7 @@
> 460 common lsm_set_self_attr sys_lsm_set_self_attr
> 461 common lsm_list_modulessys_lsm_list_modules
> 462 common mseal sys_mseal
> -463 64 uretprobe sys_uretprobe
> +467 common uretprobe sys_uretprobe
>
> #
> # Due to a historical design error, certain syscalls are numbered differently
Isn't include/uapi/asm-generic/unistd.h expected to be updated as well?
As of mainline commit v6.10-12246-g786c8248dbd3, it still contains
#define __NR_uretprobe 463
--
ldv
Re: [PATCH v2 1/5] kallsyms: Emit symbol at the holes in the text
Hi Zheng, kernel test robot noticed the following build warnings: [auto build test WARNING on linus/master] [also build test WARNING on v6.10] [cannot apply to mcgrof/modules-next masahiroy-kbuild/for-next masahiroy-kbuild/fixes powerpc/next powerpc/fixes tip/x86/core next-20240723] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Zheng-Yejian/kallsyms-Emit-symbol-at-the-holes-in-the-text/20240723-152513 base: linus/master patch link: https://lore.kernel.org/r/20240723063258.2240610-2-zhengyejian%40huaweicloud.com patch subject: [PATCH v2 1/5] kallsyms: Emit symbol at the holes in the text config: i386-randconfig-003-20240724 (https://download.01.org/0day-ci/archive/20240724/202407241240.rurwmbzm-...@intel.com/config) compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240724/202407241240.rurwmbzm-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202407241240.rurwmbzm-...@intel.com/ All warnings (new ones prefixed by >>): >> depmod: WARNING: >> /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko >> needs unknown symbol __fentry__ depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol strcmp depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol _printk depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol strlen depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol strncmp depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol pcpu_hot depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol __kmalloc_noprof depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol call_rcu depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol sched_set_fifo depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol torture_sched_setaffinity depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol kfree depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol kernel_power_off depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol rcu_barrier depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol bitmap_parselist depmod: WARNING: /tmp/kernel/i386-randconfig-003-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol sprintf >> depmod: WARNING: >>
Re: [PATCH 2/2] LoongArch: KVM: Add paravirt qspinlock in guest side
Hi Bibo, kernel test robot noticed the following build warnings: [auto build test WARNING on 7846b618e0a4c3e0099d1d4512722b39ca99] url: https://github.com/intel-lab-lkp/linux/commits/Bibo-Mao/LoongArch-KVM-Add-paravirt-qspinlock-in-kvm-side/20240723-160536 base: 7846b618e0a4c3e0099d1d4512722b39ca99 patch link: https://lore.kernel.org/r/20240723073825.1811600-3-maobibo%40loongson.cn patch subject: [PATCH 2/2] LoongArch: KVM: Add paravirt qspinlock in guest side config: loongarch-kismet-CONFIG_PARAVIRT-CONFIG_PARAVIRT_SPINLOCKS-0-0 (https://download.01.org/0day-ci/archive/20240724/202407241016.ntamveag-...@intel.com/config) reproduce: (https://download.01.org/0day-ci/archive/20240724/202407241016.ntamveag-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202407241016.ntamveag-...@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for PARAVIRT when >> selected by PARAVIRT_SPINLOCKS -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATH v5 1/3] vdpa: support set mac address from vdpa tool
On Wed, 24 Jul 2024 at 02:48, Andrew Lunn wrote:
>
> On Tue, Jul 23, 2024 at 01:39:20PM +0800, Cindy Lu wrote:
> > Add new UAPI to support the mac address from vdpa tool
> > Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> > new MAC address from the vdpa tool and then set it to the device.
> >
> > The usage is: vdpa dev set name vdpa_name mac **:**:**:**:**:**
> >
> > Here is example:
> > root@L1# vdpa -jp dev config show vdpa0
> > {
> > "config": {
> > "vdpa0": {
> > "mac": "82:4d:e9:5d:d7:e6",
> > "link ": "up",
> > "link_announce ": false,
> > "mtu": 1500
> > }
> > }
> > }
> >
> > root@L1# vdpa dev set name vdpa0 mac 00:11:22:33:44:55
> >
> > root@L1# vdpa -jp dev config show vdpa0
> > {
> > "config": {
> > "vdpa0": {
> > "mac": "00:11:22:33:44:55",
> > "link ": "up",
> > "link_announce ": false,
> > "mtu": 1500
> > }
> > }
> > }
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/vdpa.c | 84 +++
> > include/linux/vdpa.h | 9 +
> > include/uapi/linux/vdpa.h | 1 +
> > 3 files changed, 94 insertions(+)
> >
> > diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> > index 8d391947eb8d..07d61ee62839 100644
> > --- a/drivers/vdpa/vdpa.c
> > +++ b/drivers/vdpa/vdpa.c
> > @@ -1361,6 +1361,85 @@ static int vdpa_nl_cmd_dev_config_get_doit(struct
> > sk_buff *skb, struct genl_info
> > return err;
> > }
> >
> > +static int vdpa_dev_net_device_attr_set(struct vdpa_device *vdev,
> > + struct genl_info *info)
> > +{
> > + struct vdpa_dev_set_config set_config = {};
> > + const u8 *macaddr;
> > + struct vdpa_mgmt_dev *mdev = vdev->mdev;
> > + struct nlattr **nl_attrs = info->attrs;
> > + int err = -EINVAL;
> > +
> > + if (!vdev->mdev)
> > + return -EINVAL;
> > +
> > + down_write(>cf_lock);
> > + if ((mdev->supported_features & BIT_ULL(VIRTIO_NET_F_MAC)) &&
> > + nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]) {
> > + set_config.mask |= BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MACADDR);
> > + macaddr = nla_data(nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]);
> > +
> > + if (is_valid_ether_addr(macaddr)) {
> > + memcpy(set_config.net.mac, macaddr, ETH_ALEN);
> > + if (mdev->ops->dev_set_attr) {
> > + err = mdev->ops->dev_set_attr(mdev, vdev,
> > + _config);
> > + } else {
> > + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> > +"device not
> > supported");
> > + }
> > + } else {
> > + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> > +"Invalid MAC address");
> > + }
> > + }
> > + up_write(>cf_lock);
> > + return err;
> > +}
> > +static int vdpa_nl_cmd_dev_attr_set_doit(struct sk_buff *skb,
> > + struct genl_info *info)
> > +{
> > + const char *name;
> > + int err = 0;
> > + struct device *dev;
> > + struct vdpa_device *vdev;
> > + u64 classes;
> > +
> > + if (!info->attrs[VDPA_ATTR_DEV_NAME])
> > + return -EINVAL;
> > +
> > + name = nla_data(info->attrs[VDPA_ATTR_DEV_NAME]);
> > +
> > + down_write(_dev_lock);
> > + dev = bus_find_device(_bus, NULL, name, vdpa_name_match);
> > + if (!dev) {
> > + NL_SET_ERR_MSG_MOD(info->extack, "device not found");
> > + err = -ENODEV;
> > + goto dev_err;
> > + }
> > + vdev = container_of(dev, struct vdpa_device, dev);
> > + if (!vdev->mdev) {
> > + NL_SET_ERR_MSG_MOD(
> > + info->extack,
> > + "Fail to find the specified management device");
> > + err = -EINVAL;
> > + goto mdev_err;
> > + }
> > + classes = vdpa_mgmtdev_get_classes(vdev->mdev, NULL);
> > + if (classes & BIT_ULL(VIRTIO_ID_NET)) {
> > + err = vdpa_dev_net_device_attr_set(vdev, info);
> > + } else {
> > + NL_SET_ERR_MSG_FMT_MOD(info->extack, "%s device not
> > supported",
> > +name);
> > + }
> > +
> > +mdev_err:
> > + put_device(dev);
> > +dev_err:
> > + up_write(_dev_lock);
> > + return err;
> > +}
> > +
> > static int vdpa_dev_config_dump(struct device *dev, void *data)
> > {
> > struct vdpa_device *vdev = container_of(dev, struct vdpa_device, dev);
> > @@ -1497,6 +1576,11 @@ static const struct genl_ops vdpa_nl_ops[] = {
> > .doit = vdpa_nl_cmd_dev_stats_get_doit,
> > .flags = GENL_ADMIN_PERM,
> > },
> > + {
> > + .cmd =
Re: [PATH v5 3/3] vdpa/mlx5: Add the support of set mac address
On Tue, 23 Jul 2024 at 19:29, Michael S. Tsirkin wrote:
>
> On Tue, Jul 23, 2024 at 07:49:44AM +, Dragos Tatulea wrote:
> > On Tue, 2024-07-23 at 13:39 +0800, Cindy Lu wrote:
> > > Add the function to support setting the MAC address.
> > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > to set the mac address
> > >
> > > Tested in ConnectX-6 Dx device
> > >
> > > Signed-off-by: Cindy Lu
> > > ---
> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 28
> > > 1 file changed, 28 insertions(+)
> > >
> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > index ecfc16151d61..7fce952d650f 100644
> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > @@ -3785,10 +3785,38 @@ static void mlx5_vdpa_dev_del(struct
> > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > destroy_workqueue(wq);
> > > mgtdev->ndev = NULL;
> > > }
> > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > + struct vdpa_device *dev,
> > > + const struct vdpa_dev_set_config *add_config)
> > > +{
> > > + struct virtio_net_config *config;
> > > + struct mlx5_core_dev *pfmdev;
> > > + struct mlx5_vdpa_dev *mvdev;
> > > + struct mlx5_vdpa_net *ndev;
> > > + struct mlx5_core_dev *mdev;
> > > + int err = -EINVAL;
> > > +
> > > + mvdev = to_mvdev(dev);
> > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > + mdev = mvdev->mdev;
> > > + config = >config;
> > > +
> > > + down_write(>reslock);
> > > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > + if (0 == err)
> > if (!err) would be nicer. Not a deal breaker though.
>
> yes, no yodda style please. It, I can not stand.
>
sure， Will fix this
Thanks
cindy
>
> > Reviewed-by: Dragos Tatulea
> >
> > > + memcpy(config->mac, add_config->net.mac, ETH_ALEN);
> > > + }
> > > +
> > > + up_write(>reslock);
> > > + return err;
> > > +}
> > >
> > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > .dev_add = mlx5_vdpa_dev_add,
> > > .dev_del = mlx5_vdpa_dev_del,
> > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > };
> > >
> > > static struct virtio_device_id id_table[] = {
> >
>
Re: [PATH v5 0/3] vdpa: support set mac address from vdpa tool
On Wed, 24 Jul 2024 at 02:45, Andrew Lunn wrote: > > On Tue, Jul 23, 2024 at 01:39:19PM +0800, Cindy Lu wrote: > > Add support for setting the MAC address using the VDPA tool. > > This feature will allow setting the MAC address using the VDPA tool. > > For example, in vdpa_sim_net, the implementation sets the MAC address > > to the config space. However, for other drivers, they can implement their > > own function, not limited to the config space. > > > > Changelog v2 > > - Changed the function name to prevent misunderstanding > > - Added check for blk device > > - Addressed the comments > > Changelog v3 > > - Split the function of the net device from vdpa_nl_cmd_dev_attr_set_doit > > - Add a lock for the network device's dev_set_attr operation > > - Address the comments > > Changelog v4 > > - Address the comments > > - Add a lock for the vdap_sim?_net device's dev_set_attr operation > > Changelog v5 > > - Address the comments > > This history is to help reviewers of previous versions know if there > comments have been addressed. Just saying 'Address the comments' is > not useful. Please give a one line summary of each of the comment > which has been addressed, maybe including how it was addressed. > > Andrew > will change this Thanks cindy
Re: [PATCH v2 1/5] kallsyms: Emit symbol at the holes in the text
Hi Zheng, kernel test robot noticed the following build warnings: [auto build test WARNING on linus/master] [also build test WARNING on v6.10] [cannot apply to mcgrof/modules-next masahiroy-kbuild/for-next masahiroy-kbuild/fixes powerpc/next powerpc/fixes tip/x86/core next-20240723] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Zheng-Yejian/kallsyms-Emit-symbol-at-the-holes-in-the-text/20240723-152513 base: linus/master patch link: https://lore.kernel.org/r/20240723063258.2240610-2-zhengyejian%40huaweicloud.com patch subject: [PATCH v2 1/5] kallsyms: Emit symbol at the holes in the text config: i386-randconfig-002-20240724 (https://download.01.org/0day-ci/archive/20240724/202407240921.tumlfzka-...@intel.com/config) compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240724/202407240921.tumlfzka-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202407240921.tumlfzka-...@intel.com/ All warnings (new ones prefixed by >>): depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol strcmp depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol _printk depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol strlen depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol strncmp depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol __kmalloc_noprof depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol call_rcu depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol sched_set_fifo depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol torture_sched_setaffinity depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol kfree depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol kernel_power_off depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol rcu_barrier depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol bitmap_parselist depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol sprintf depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol pcpu_hot depmod: WARNING: /tmp/kernel/i386-randconfig-002-20240724/clang-18/dbae13ff5e8d04476cede99ca67c4be77c2a7886/lib/modules/6.10.0-12031-gdbae13ff5e8d/kernel/kernel/locking/locktorture.ko needs unknown symbol set_user_nice depmod: WARNING:
Re: [PATCH 2/2] LoongArch: KVM: Add paravirt qspinlock in guest side
On 2024/7/24 上午3:57, kernel test robot wrote:
Hi Bibo,
kernel test robot noticed the following build errors:
yes, forgot to mention, it depends on this patch
https://lore.kernel.org/lkml/20240721164552.50175-1-ubiz...@gmail.com/
Regards
Bibo Mao
[auto build test ERROR on 7846b618e0a4c3e0099d1d4512722b39ca99]
url:
https://github.com/intel-lab-lkp/linux/commits/Bibo-Mao/LoongArch-KVM-Add-paravirt-qspinlock-in-kvm-side/20240723-160536
base: 7846b618e0a4c3e0099d1d4512722b39ca99
patch link:
https://lore.kernel.org/r/20240723073825.1811600-3-maobibo%40loongson.cn
patch subject: [PATCH 2/2] LoongArch: KVM: Add paravirt qspinlock in guest side
config: loongarch-allmodconfig
(https://download.01.org/0day-ci/archive/20240724/202407240320.qqd1uwie-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240724/202407240320.qqd1uwie-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202407240320.qqd1uwie-...@intel.com/
All error/warnings (new ones prefixed by >>):
arch/loongarch/kernel/paravirt.c:309: warning: expecting prototype for
queued_spin_unlock(). Prototype was for native_queued_spin_unlock() instead
--
In file included from include/linux/atomic.h:80,
from include/asm-generic/bitops/atomic.h:5,
from arch/loongarch/include/asm/bitops.h:27,
from include/linux/bitops.h:63,
from include/linux/kernel.h:23,
from include/linux/cpumask.h:11,
from include/linux/smp.h:13,
from kernel/locking/qspinlock.c:16:
kernel/locking/qspinlock_paravirt.h: In function 'pv_kick_node':
include/linux/atomic/atomic-arch-fallback.h:242:34: error: initialization of
'u8 *' {aka 'unsigned char *'} from incompatible pointer type 'enum vcpu_state
*' [-Wincompatible-pointer-types]
242 | typeof(*(_ptr)) *___op = (_oldp), ___o = *___op, ___r; \
| ^
include/linux/atomic/atomic-instrumented.h:4908:9: note: in expansion of
macro 'raw_try_cmpxchg_relaxed'
4908 | raw_try_cmpxchg_relaxed(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~
kernel/locking/qspinlock_paravirt.h:377:14: note: in expansion of macro
'try_cmpxchg_relaxed'
377 | if (!try_cmpxchg_relaxed(>state, , vcpu_hashed))
| ^~~
vim +309 arch/loongarch/kernel/paravirt.c
303
304 /**
305 * queued_spin_unlock - release a queued spinlock
306 * @lock : Pointer to queued spinlock structure
307 */
308 static void native_queued_spin_unlock(struct qspinlock *lock)
> 309 {
310 /*
311 * unlock() needs release semantics:
312 */
313 smp_store_release(>locked, 0);
314 }
315
Re: [PATCH] eventfs: Use SRCU for freeing eventfs_inodes
On Tue, 23 Jul 2024 23:07:53 +0200
Mathias Krause wrote:
> To mirror the SRCU lock held in eventfs_iterate() when iterating over
> eventfs inodes, use call_srcu() to free them too.
>
> This was accidentally(?) degraded to RCU in commit 43aa6f97c2d0
> ("eventfs: Get rid of dentry pointers without refcounts").
Yeah, I missed that. Linus cleaned up the code code quite a bit, but
missed the subtleties of the RCU clean ups. I should have caught that
in my review.
Thanks for sending this.
-- Steve
Re: [GIT PULL] rpmsg updates for v6.11
The pull request you sent on Tue, 23 Jul 2024 12:17:49 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git > tags/rpmsg-v6.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/643af93f15be901982b2b08f241263934201c99f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] hwspinlock updates for v6.11
The pull request you sent on Tue, 23 Jul 2024 10:20:47 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git > tags/hwlock-v6.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/58bffbac533d4526cb4922b8563d1963a90729be Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] remoteproc updates for v6.11
The pull request you sent on Tue, 23 Jul 2024 11:30:41 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git > tags/rproc-v6.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/60c6119cadba52bee86b3e88011495483e26eb43 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: tracing: user events UAF crash report
On 23.07.24 16:43, Steven Rostedt wrote:
> On Fri, 19 Jul 2024 22:47:01 +0200
> Mathias Krause wrote:
>
>> Beside the obvious bug, I noticed the following (not fixing the issue,
>> tho):
>>
>> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
>> index 5d88c184f0fc..687ad0a26458 100644
>> --- a/fs/tracefs/event_inode.c
>> +++ b/fs/tracefs/event_inode.c
>> @@ -112,7 +112,7 @@ static void release_ei(struct kref *ref)
>> entry->release(entry->name, ei->data);
>> }
>>
>> -call_rcu(>rcu, free_ei_rcu);
>> +call_srcu(_srcu, >rcu, free_ei_rcu);
>> }
>
> This should be fixed too. Care to send a patch for this as well?
Sure, will do.
>
> It use to need RCU but then everything was switched over to SRCU. This was
> just leftover.
SRCU usage came up with commit 63940449555e ("eventfs: Implement eventfs
lookup, read, open functions") and following, was further extended just
to get almost completely nuked by [1] earlier this year.
[1]
https://lore.kernel.org/linux-trace-kernel/20240131184918.945345...@goodmis.org/
>
>>
>> static inline void put_ei(struct eventfs_inode *ei)
>> @@ -735,7 +735,9 @@ struct eventfs_inode *eventfs_create_dir(const char
>> *name, struct eventfs_inode
>>
>> /* Was the parent freed? */
>> if (list_empty(>list)) {
>> +mutex_lock(_mutex);
>> cleanup_ei(ei);
>> +mutex_unlock(_mutex);
>
> Why do you think this is needed? The ei is not on the list and has not been
> made visible. It was just allocated but the parent it was going to be
> attached to is about to be freed.
I have no strong understanding of the code, just reading into what the
context told me the rules should be, which would be on one hand the
following comment...:
/*
* The eventfs_inode (ei) itself is protected by SRCU. It is released from
* its parent's list and will have is_freed set (under eventfs_mutex).
* After the SRCU grace period is over and the last dput() is called
* the ei is freed.
*/
...and on the other the common pattern, mostly complying to the rule of
first taking the eventfs_mutex, then checking 'is_freed' for a given ei
-- supposedly implying, it can only be set under that very same mutex.
As cleanup_ei() is just a glorified free_ei() which sets ei->is_freed to
1, I was implying the lack of taking eventfs_mutex is a bug. But looking
further for the precondition, getting 'ei' unchained again after it was
put to the parent's children list, I can find eventfs_remove_rec() which
is only ever called under eventfs_mutex and does:
list_del(>list);
free_ei(ei);
So you're right and I wasn't paying close enough attention and got
mislead by cleanup_ei() also setting ei->is_freed. But as it should
already be 1 at that point, no bug here.
Thanks,
Mathias
Re: [PATCH 2/2] LoongArch: KVM: Add paravirt qspinlock in guest side
Hi Bibo,
kernel test robot noticed the following build errors:
[auto build test ERROR on 7846b618e0a4c3e0099d1d4512722b39ca99]
url:
https://github.com/intel-lab-lkp/linux/commits/Bibo-Mao/LoongArch-KVM-Add-paravirt-qspinlock-in-kvm-side/20240723-160536
base: 7846b618e0a4c3e0099d1d4512722b39ca99
patch link:
https://lore.kernel.org/r/20240723073825.1811600-3-maobibo%40loongson.cn
patch subject: [PATCH 2/2] LoongArch: KVM: Add paravirt qspinlock in guest side
config: loongarch-allmodconfig
(https://download.01.org/0day-ci/archive/20240724/202407240320.qqd1uwie-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240724/202407240320.qqd1uwie-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202407240320.qqd1uwie-...@intel.com/
All error/warnings (new ones prefixed by >>):
>> arch/loongarch/kernel/paravirt.c:309: warning: expecting prototype for
>> queued_spin_unlock(). Prototype was for native_queued_spin_unlock() instead
--
In file included from include/linux/atomic.h:80,
from include/asm-generic/bitops/atomic.h:5,
from arch/loongarch/include/asm/bitops.h:27,
from include/linux/bitops.h:63,
from include/linux/kernel.h:23,
from include/linux/cpumask.h:11,
from include/linux/smp.h:13,
from kernel/locking/qspinlock.c:16:
kernel/locking/qspinlock_paravirt.h: In function 'pv_kick_node':
>> include/linux/atomic/atomic-arch-fallback.h:242:34: error: initialization of
>> 'u8 *' {aka 'unsigned char *'} from incompatible pointer type 'enum
>> vcpu_state *' [-Wincompatible-pointer-types]
242 | typeof(*(_ptr)) *___op = (_oldp), ___o = *___op, ___r; \
| ^
include/linux/atomic/atomic-instrumented.h:4908:9: note: in expansion of
macro 'raw_try_cmpxchg_relaxed'
4908 | raw_try_cmpxchg_relaxed(__ai_ptr, __ai_oldp, __VA_ARGS__); \
| ^~~
kernel/locking/qspinlock_paravirt.h:377:14: note: in expansion of macro
'try_cmpxchg_relaxed'
377 | if (!try_cmpxchg_relaxed(>state, , vcpu_hashed))
| ^~~
vim +309 arch/loongarch/kernel/paravirt.c
303
304 /**
305 * queued_spin_unlock - release a queued spinlock
306 * @lock : Pointer to queued spinlock structure
307 */
308 static void native_queued_spin_unlock(struct qspinlock *lock)
> 309 {
310 /*
311 * unlock() needs release semantics:
312 */
313 smp_store_release(>locked, 0);
314 }
315
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [GIT PULL] livepatching for 6.11
The pull request you sent on Tue, 23 Jul 2024 17:46:20 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching > tags/livepatching-for-6.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d2d721e2eb1337c67f0c5bba303f8a013b622bed Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Modules changes for v6.11-rc1
The pull request you sent on Tue, 23 Jul 2024 10:14:01 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/ > tags/modules-6.11-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f488790059fe7be6b2b059ddee10835b2500b603 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v2] lib: test_objpool: add missing MODULE_DESCRIPTION() macro
On 7/15/2024 7:18 AM, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/test_objpool.o
>
> Add the missing invocation of the MODULE_DESCRIPTION() macro.
>
> Reviewed-by: Matt Wu
> Signed-off-by: Jeff Johnson
> ---
> Changes in v2:
> - No changes to actual patch, just rebased, picked up Matt's Reviewed-by
> tag, and added Masami & linux-trace-kernel
> - Link to v1:
> https://lore.kernel.org/r/20240531-md-lib-test_objpool-v1-1-516efee92...@quicinc.com
> ---
> lib/test_objpool.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/test_objpool.c b/lib/test_objpool.c
> index bfdb81599832..5a3f6961a70f 100644
> --- a/lib/test_objpool.c
> +++ b/lib/test_objpool.c
> @@ -687,4 +687,5 @@ static void __exit ot_mod_exit(void)
> module_init(ot_mod_init);
> module_exit(ot_mod_exit);
>
> -MODULE_LICENSE("GPL");
> \ No newline at end of file
> +MODULE_DESCRIPTION("Test module for lockless object pool");
> +MODULE_LICENSE("GPL");
>
> ---
> base-commit: 0c3836482481200ead7b416ca80c68a29cfdaabd
> change-id: 20240531-md-lib-test_objpool-338d937f8666
>
Hi Andrew & Masami,
I see this landed in linux-next, but is not currently in Linus' tree for 6.11.
Will you be able to have this pulled during the merge window?
I'm trying to eradicate all of these warnings before 6.11 rc-final.
Thanks!
/jeff
Re: [PATH v5 2/3] vdpa_sim_net: Add the support of set mac address
> +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *config)
> +{
> + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> + struct virtio_net_config *vio_config = vdpasim->config;
> +
> + mutex_lock(>mutex);
> +
> + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
ether_addr_copy()
Andrew
Re: [PATH v5 1/3] vdpa: support set mac address from vdpa tool
On Tue, Jul 23, 2024 at 01:39:20PM +0800, Cindy Lu wrote:
> Add new UAPI to support the mac address from vdpa tool
> Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> new MAC address from the vdpa tool and then set it to the device.
>
> The usage is: vdpa dev set name vdpa_name mac **:**:**:**:**:**
>
> Here is example:
> root@L1# vdpa -jp dev config show vdpa0
> {
> "config": {
> "vdpa0": {
> "mac": "82:4d:e9:5d:d7:e6",
> "link ": "up",
> "link_announce ": false,
> "mtu": 1500
> }
> }
> }
>
> root@L1# vdpa dev set name vdpa0 mac 00:11:22:33:44:55
>
> root@L1# vdpa -jp dev config show vdpa0
> {
> "config": {
> "vdpa0": {
> "mac": "00:11:22:33:44:55",
> "link ": "up",
> "link_announce ": false,
> "mtu": 1500
> }
> }
> }
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/vdpa.c | 84 +++
> include/linux/vdpa.h | 9 +
> include/uapi/linux/vdpa.h | 1 +
> 3 files changed, 94 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> index 8d391947eb8d..07d61ee62839 100644
> --- a/drivers/vdpa/vdpa.c
> +++ b/drivers/vdpa/vdpa.c
> @@ -1361,6 +1361,85 @@ static int vdpa_nl_cmd_dev_config_get_doit(struct
> sk_buff *skb, struct genl_info
> return err;
> }
>
> +static int vdpa_dev_net_device_attr_set(struct vdpa_device *vdev,
> + struct genl_info *info)
> +{
> + struct vdpa_dev_set_config set_config = {};
> + const u8 *macaddr;
> + struct vdpa_mgmt_dev *mdev = vdev->mdev;
> + struct nlattr **nl_attrs = info->attrs;
> + int err = -EINVAL;
> +
> + if (!vdev->mdev)
> + return -EINVAL;
> +
> + down_write(>cf_lock);
> + if ((mdev->supported_features & BIT_ULL(VIRTIO_NET_F_MAC)) &&
> + nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]) {
> + set_config.mask |= BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MACADDR);
> + macaddr = nla_data(nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]);
> +
> + if (is_valid_ether_addr(macaddr)) {
> + memcpy(set_config.net.mac, macaddr, ETH_ALEN);
> + if (mdev->ops->dev_set_attr) {
> + err = mdev->ops->dev_set_attr(mdev, vdev,
> + _config);
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> +"device not supported");
> + }
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> +"Invalid MAC address");
> + }
> + }
> + up_write(>cf_lock);
> + return err;
> +}
> +static int vdpa_nl_cmd_dev_attr_set_doit(struct sk_buff *skb,
> + struct genl_info *info)
> +{
> + const char *name;
> + int err = 0;
> + struct device *dev;
> + struct vdpa_device *vdev;
> + u64 classes;
> +
> + if (!info->attrs[VDPA_ATTR_DEV_NAME])
> + return -EINVAL;
> +
> + name = nla_data(info->attrs[VDPA_ATTR_DEV_NAME]);
> +
> + down_write(_dev_lock);
> + dev = bus_find_device(_bus, NULL, name, vdpa_name_match);
> + if (!dev) {
> + NL_SET_ERR_MSG_MOD(info->extack, "device not found");
> + err = -ENODEV;
> + goto dev_err;
> + }
> + vdev = container_of(dev, struct vdpa_device, dev);
> + if (!vdev->mdev) {
> + NL_SET_ERR_MSG_MOD(
> + info->extack,
> + "Fail to find the specified management device");
> + err = -EINVAL;
> + goto mdev_err;
> + }
> + classes = vdpa_mgmtdev_get_classes(vdev->mdev, NULL);
> + if (classes & BIT_ULL(VIRTIO_ID_NET)) {
> + err = vdpa_dev_net_device_attr_set(vdev, info);
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack, "%s device not supported",
> +name);
> + }
> +
> +mdev_err:
> + put_device(dev);
> +dev_err:
> + up_write(_dev_lock);
> + return err;
> +}
> +
> static int vdpa_dev_config_dump(struct device *dev, void *data)
> {
> struct vdpa_device *vdev = container_of(dev, struct vdpa_device, dev);
> @@ -1497,6 +1576,11 @@ static const struct genl_ops vdpa_nl_ops[] = {
> .doit = vdpa_nl_cmd_dev_stats_get_doit,
> .flags = GENL_ADMIN_PERM,
> },
> + {
> + .cmd = VDPA_CMD_DEV_ATTR_SET,
> + .doit = vdpa_nl_cmd_dev_attr_set_doit,
> + .flags = GENL_ADMIN_PERM,
> + },
> };
>
> static struct genl_family vdpa_nl_family __ro_after_init = {
> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> index 7977ca03ac7a..3511156c10db 100644
> ---
Re: [PATH v5 0/3] vdpa: support set mac address from vdpa tool
On Tue, Jul 23, 2024 at 01:39:19PM +0800, Cindy Lu wrote: > Add support for setting the MAC address using the VDPA tool. > This feature will allow setting the MAC address using the VDPA tool. > For example, in vdpa_sim_net, the implementation sets the MAC address > to the config space. However, for other drivers, they can implement their > own function, not limited to the config space. > > Changelog v2 > - Changed the function name to prevent misunderstanding > - Added check for blk device > - Addressed the comments > Changelog v3 > - Split the function of the net device from vdpa_nl_cmd_dev_attr_set_doit > - Add a lock for the network device's dev_set_attr operation > - Address the comments > Changelog v4 > - Address the comments > - Add a lock for the vdap_sim?_net device's dev_set_attr operation > Changelog v5 > - Address the comments This history is to help reviewers of previous versions know if there comments have been addressed. Just saying 'Address the comments' is not useful. Please give a one line summary of each of the comment which has been addressed, maybe including how it was addressed. Andrew
Re: [PATCH] rpmsg: char: add missing MODULE_DESCRIPTION() macro
On 6/10/2024 10:25 AM, Mathieu Poirier wrote:
> On Tue, Jun 04, 2024 at 06:53:44PM -0700, Jeff Johnson wrote:
>> make allmodconfig && make W=1 C=1 reports:
>> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/rpmsg/rpmsg_char.o
>>
>> Add the missing invocation of the MODULE_DESCRIPTION() macro.
>>
>> Signed-off-by: Jeff Johnson
>> ---
>> drivers/rpmsg/rpmsg_char.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
>> index d7a342510902..73b9fa113b34 100644
>> --- a/drivers/rpmsg/rpmsg_char.c
>> +++ b/drivers/rpmsg/rpmsg_char.c
>> @@ -566,4 +566,5 @@ static void rpmsg_chrdev_exit(void)
>> module_exit(rpmsg_chrdev_exit);
>>
>> MODULE_ALIAS("rpmsg:rpmsg_chrdev");
>> +MODULE_DESCRIPTION("RPMSG device interface");
>> MODULE_LICENSE("GPL v2");
>>
>
> Applied
>
> Thanks,
> Mathieu
Hi,
I see this landed in linux-next, but is not currently in Linus' tree for 6.11.
Will you be able to have this pulled during the merge window?
I'm trying to eradicate all of these warnings before 6.11 rc-final.
Thanks!
/jeff
Re: tracing: user events UAF crash report
On Fri, 19 Jul 2024 22:47:01 +0200
Mathias Krause wrote:
> Beside the obvious bug, I noticed the following (not fixing the issue,
> tho):
>
> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
> index 5d88c184f0fc..687ad0a26458 100644
> --- a/fs/tracefs/event_inode.c
> +++ b/fs/tracefs/event_inode.c
> @@ -112,7 +112,7 @@ static void release_ei(struct kref *ref)
> entry->release(entry->name, ei->data);
> }
>
> - call_rcu(>rcu, free_ei_rcu);
> + call_srcu(_srcu, >rcu, free_ei_rcu);
> }
This should be fixed too. Care to send a patch for this as well?
It use to need RCU but then everything was switched over to SRCU. This was
just leftover.
>
> static inline void put_ei(struct eventfs_inode *ei)
> @@ -735,7 +735,9 @@ struct eventfs_inode *eventfs_create_dir(const char
> *name, struct eventfs_inode
>
> /* Was the parent freed? */
> if (list_empty(>list)) {
> + mutex_lock(_mutex);
> cleanup_ei(ei);
> + mutex_unlock(_mutex);
Why do you think this is needed? The ei is not on the list and has not been
made visible. It was just allocated but the parent it was going to be
attached to is about to be freed.
> ei = NULL;
> }
> return ei;
Thanks,
-- Steve
Re: [PATCH] arm64: dts: qcom: msm8916-samsung-fortuna: Enable the touchkeys
On 23.07.2024 3:39 PM, Raymond Hackley wrote: >> Fixes? >> >> Konrad > > Hi Konrad, > > the issue is not reported or discussed on lkml, so there is no thread to fix? See the "In case your patch fixes a bug.." paragraph in: https://docs.kernel.org/process/submitting-patches.html > > Regards, > Raymond >
Re: [PATCH] arm64: dts: qcom: msm8916-samsung-fortuna: Enable the touchkeys
> Fixes? > > Konrad Hi Konrad, the issue is not reported or discussed on lkml, so there is no thread to fix? Regards, Raymond
Re: [PATCH] arm64: dts: qcom: msm8916-samsung-rossa: Add touchscreen
On 23.07.2024 3:15 PM, Raymond Hackley wrote: > Core Prime uses an Imagis IST3038 touchscreen that is connected to > blsp_i2c5. Add it to the device tree. > > Signed-off-by: Raymond Hackley > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH] arm64: dts: qcom: msm8916-samsung-rossa: Add touchscreen
Tested-by: Juan-Rafael Fernandez Regards, Raymond
Re: [PATCH] arm64: dts: qcom: msm8916-samsung-fortuna: Enable the touchkeys
On 23.07.2024 3:12 PM, Raymond Hackley wrote: > The phone needs the touchkeys to be enabled so the sense lines of the > touch controller are mapped properly. Otherwise the touchscreen is not > mapped to the display properly. > > Signed-off-by: Raymond Hackley > --- Fixes? Konrad
Re: [PATCH v3 7/9] dt-bindings: interconnect: qcom: msm8939: Fix example
On 9.07.2024 12:22 PM, Adam Skladowski wrote: > For now example list snoc_mm as children of bimc which is obviously > not valid, drop bimc and move snoc_mm into snoc. > > Signed-off-by: Adam Skladowski > --- loool, thanks Reviewed-by: Konrad Dybcio Konrad
Re: [PATH v5 3/3] vdpa/mlx5: Add the support of set mac address
On Tue, Jul 23, 2024 at 07:49:44AM +, Dragos Tatulea wrote:
> On Tue, 2024-07-23 at 13:39 +0800, Cindy Lu wrote:
> > Add the function to support setting the MAC address.
> > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > to set the mac address
> >
> > Tested in ConnectX-6 Dx device
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/mlx5/net/mlx5_vnet.c | 28
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index ecfc16151d61..7fce952d650f 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -3785,10 +3785,38 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
> > *v_mdev, struct vdpa_device *
> > destroy_workqueue(wq);
> > mgtdev->ndev = NULL;
> > }
> > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > + struct vdpa_device *dev,
> > + const struct vdpa_dev_set_config *add_config)
> > +{
> > + struct virtio_net_config *config;
> > + struct mlx5_core_dev *pfmdev;
> > + struct mlx5_vdpa_dev *mvdev;
> > + struct mlx5_vdpa_net *ndev;
> > + struct mlx5_core_dev *mdev;
> > + int err = -EINVAL;
> > +
> > + mvdev = to_mvdev(dev);
> > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > + mdev = mvdev->mdev;
> > + config = >config;
> > +
> > + down_write(>reslock);
> > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > + if (0 == err)
> if (!err) would be nicer. Not a deal breaker though.
yes, no yodda style please. It, I can not stand.
> Reviewed-by: Dragos Tatulea
>
> > + memcpy(config->mac, add_config->net.mac, ETH_ALEN);
> > + }
> > +
> > + up_write(>reslock);
> > + return err;
> > +}
> >
> > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > .dev_add = mlx5_vdpa_dev_add,
> > .dev_del = mlx5_vdpa_dev_del,
> > + .dev_set_attr = mlx5_vdpa_set_attr,
> > };
> >
> > static struct virtio_device_id id_table[] = {
>
Re: [PATCH 1/2] x86/tdx: Add prctl to allow userlevel TDX hypercalls
On Mon, Jul 22, 2024 at 10:04:40PM -0700, Tim Merrifield wrote: > > Thanks for the review, Kirill. > > On Mon, Jul 08, 2024 at 03:19:54PM +0300, Kirill A . Shutemov wrote: > > Hm. Per-thread flag is odd. I think it should be per-process. > > This is the only point I might need some clarification on. I agree > there doesn't seem to be much value in allowing per-thread control, > but I don't see any precedence for setting per-process flags through > arch_prctl or similar interfaces. Am I missing something? LAM is per-process. But it can only be enabled while the process has only one thread and locks on second thread spawn. See MM_CONTEXT_LOCK_LAM. -- Kiryl Shutsemau / Kirill A. Shutemov
Re: [PATCH 3/4] ASoC: dt-bindings: qcom,sm8250: Add msm8953/msm8976-qdsp6-sndcard
On 23/07/2024 10:19, Krzysztof Kozlowski wrote: > On 22/07/2024 11:51, Adam Skladowski wrote: >> Document MSM8953/MSM8976 QDSP6 cards. >> >> Signed-off-by: Adam Skladowski > > ... > >> +then: >>properties: >> -reg: false >> -reg-names: false >> +reg: >> + items: >> +- description: Microphone I/O mux register address >> +- description: Speaker I/O mux register address >> +- description: Quinary Mi2S I/O mux register address >> +reg-names: >> + items: >> +- const: mic-iomux >> +- const: spkr-iomux >> +- const: quin-iomux >> + required: >> +- compatible >> +- model > > Don't duplicate. It's already required. I suggest to rebase on top of my patch. Optionally, take it into your patchset. Best regards, Krzysztof
Re: [PATCH 3/4] ASoC: dt-bindings: qcom,sm8250: Add msm8953/msm8976-qdsp6-sndcard
On 22/07/2024 11:51, Adam Skladowski wrote: > Document MSM8953/MSM8976 QDSP6 cards. > > Signed-off-by: Adam Skladowski ... > +then: >properties: > -reg: false > -reg-names: false > +reg: > + items: > +- description: Microphone I/O mux register address > +- description: Speaker I/O mux register address > +- description: Quinary Mi2S I/O mux register address > +reg-names: > + items: > +- const: mic-iomux > +- const: spkr-iomux > +- const: quin-iomux > + required: > +- compatible > +- model Don't duplicate. It's already required. > +- reg > +- reg-names And what happened with all other variants? Why do you affect them? > > additionalProperties: false > Best regards, Krzysztof
Re: [PATH v5 3/3] vdpa/mlx5: Add the support of set mac address
On Tue, 2024-07-23 at 13:39 +0800, Cindy Lu wrote:
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index ecfc16151d61..7fce952d650f 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -3785,10 +3785,38 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
> *v_mdev, struct vdpa_device *
> destroy_workqueue(wq);
> mgtdev->ndev = NULL;
> }
> +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *add_config)
> +{
> + struct virtio_net_config *config;
> + struct mlx5_core_dev *pfmdev;
> + struct mlx5_vdpa_dev *mvdev;
> + struct mlx5_vdpa_net *ndev;
> + struct mlx5_core_dev *mdev;
> + int err = -EINVAL;
> +
> + mvdev = to_mvdev(dev);
> + ndev = to_mlx5_vdpa_ndev(mvdev);
> + mdev = mvdev->mdev;
> + config = >config;
> +
> + down_write(>reslock);
> + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> + if (0 == err)
if (!err) would be nicer. Not a deal breaker though.
Reviewed-by: Dragos Tatulea
> + memcpy(config->mac, add_config->net.mac, ETH_ALEN);
> + }
> +
> + up_write(>reslock);
> + return err;
> +}
>
> static const struct vdpa_mgmtdev_ops mdev_ops = {
> .dev_add = mlx5_vdpa_dev_add,
> .dev_del = mlx5_vdpa_dev_del,
> + .dev_set_attr = mlx5_vdpa_set_attr,
> };
>
> static struct virtio_device_id id_table[] = {
Re: [PATH v5 1/3] vdpa: support set mac address from vdpa tool
On Tue, 23 Jul 2024 at 14:01, Jason Wang wrote:
>
> On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote:
> >
> > Add new UAPI to support the mac address from vdpa tool
> > Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> > new MAC address from the vdpa tool and then set it to the device.
> >
> > The usage is: vdpa dev set name vdpa_name mac **:**:**:**:**:**
> >
> > Here is example:
> > root@L1# vdpa -jp dev config show vdpa0
> > {
> > "config": {
> > "vdpa0": {
> > "mac": "82:4d:e9:5d:d7:e6",
> > "link ": "up",
> > "link_announce ": false,
> > "mtu": 1500
> > }
> > }
> > }
> >
> > root@L1# vdpa dev set name vdpa0 mac 00:11:22:33:44:55
> >
> > root@L1# vdpa -jp dev config show vdpa0
> > {
> > "config": {
> > "vdpa0": {
> > "mac": "00:11:22:33:44:55",
> > "link ": "up",
> > "link_announce ": false,
> > "mtu": 1500
> > }
> > }
> > }
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/vdpa.c | 84 +++
> > include/linux/vdpa.h | 9 +
> > include/uapi/linux/vdpa.h | 1 +
> > 3 files changed, 94 insertions(+)
> >
> > diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> > index 8d391947eb8d..07d61ee62839 100644
> > --- a/drivers/vdpa/vdpa.c
> > +++ b/drivers/vdpa/vdpa.c
> > @@ -1361,6 +1361,85 @@ static int vdpa_nl_cmd_dev_config_get_doit(struct
> > sk_buff *skb, struct genl_info
> > return err;
> > }
> >
> > +static int vdpa_dev_net_device_attr_set(struct vdpa_device *vdev,
> > + struct genl_info *info)
> > +{
> > + struct vdpa_dev_set_config set_config = {};
> > + const u8 *macaddr;
> > + struct vdpa_mgmt_dev *mdev = vdev->mdev;
> > + struct nlattr **nl_attrs = info->attrs;
> > + int err = -EINVAL;
> > +
> > + if (!vdev->mdev)
> > + return -EINVAL;
>
> It looks like the caller has already done this check?
>
sure, will remove this
> > +
> > + down_write(>cf_lock);
> > + if ((mdev->supported_features & BIT_ULL(VIRTIO_NET_F_MAC)) &&
>
> This is not a virtio feature, so I don't get why we need to check
> VIRTIO_NET_F_MAC.
>
will remove this
> > + nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]) {
> > + set_config.mask |= BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MACADDR);
> > + macaddr = nla_data(nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]);
> > +
> > + if (is_valid_ether_addr(macaddr)) {
> > + memcpy(set_config.net.mac, macaddr, ETH_ALEN);
> > + if (mdev->ops->dev_set_attr) {
> > + err = mdev->ops->dev_set_attr(mdev, vdev,
> > + _config);
> > + } else {
> > + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> > + "device not
> > supported");
>
> "Device does not support setting mac address" ?
>
sure, will change this
Thanks
cindy
> > + }
> > + } else {
> > + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> > + "Invalid MAC address");
> > + }
> > + }
> > + up_write(>cf_lock);
> > + return err;
> > +}
> > +static int vdpa_nl_cmd_dev_attr_set_doit(struct sk_buff *skb,
> > +struct genl_info *info)
> > +{
> > + const char *name;
> > + int err = 0;
> > + struct device *dev;
> > + struct vdpa_device *vdev;
> > + u64 classes;
> > +
> > + if (!info->attrs[VDPA_ATTR_DEV_NAME])
> > + return -EINVAL;
> > +
> > + name = nla_data(info->attrs[VDPA_ATTR_DEV_NAME]);
> > +
> > + down_write(_dev_lock);
> > + dev = bus_find_device(_bus, NULL, name, vdpa_name_match);
> > + if (!dev) {
> > + NL_SET_ERR_MSG_MOD(info->extack, "device not found");
> > + err = -ENODEV;
> > + goto dev_err;
> > + }
> > + vdev = container_of(dev, struct vdpa_device, dev);
> > + if (!vdev->mdev) {
> > + NL_SET_ERR_MSG_MOD(
> > + info->extack,
> > + "Fail to find the specified management device");
> > + err = -EINVAL;
> > + goto mdev_err;
> > + }
> > + classes = vdpa_mgmtdev_get_classes(vdev->mdev, NULL);
> > + if (classes & BIT_ULL(VIRTIO_ID_NET)) {
> > + err = vdpa_dev_net_device_attr_set(vdev, info);
> > + } else {
> > + NL_SET_ERR_MSG_FMT_MOD(info->extack, "%s device not
> > supported",
> > + name);
> > + }
> > +
> > +mdev_err:
> > + put_device(dev);
> > +dev_err:
> > + up_write(_dev_lock);
> > +
Re: [PATH v5 3/3] vdpa/mlx5: Add the support of set mac address
On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote: > > Add the function to support setting the MAC address. > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac > to set the mac address > > Tested in ConnectX-6 Dx device > > Signed-off-by: Cindy Lu Acked-by: Jason Wang Thanks
Re: [PATH v5 2/3] vdpa_sim_net: Add the support of set mac address
On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote: > > Add the function to support setting the MAC address. > For vdpa_sim_net, the driver will write the MAC address > to the config space, and other devices can implement > their own functions to support this. > > Signed-off-by: Cindy Lu Acked-by: Jason Wang Thanks
Re: [PATH v5 1/3] vdpa: support set mac address from vdpa tool
On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote:
>
> Add new UAPI to support the mac address from vdpa tool
> Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> new MAC address from the vdpa tool and then set it to the device.
>
> The usage is: vdpa dev set name vdpa_name mac **:**:**:**:**:**
>
> Here is example:
> root@L1# vdpa -jp dev config show vdpa0
> {
> "config": {
> "vdpa0": {
> "mac": "82:4d:e9:5d:d7:e6",
> "link ": "up",
> "link_announce ": false,
> "mtu": 1500
> }
> }
> }
>
> root@L1# vdpa dev set name vdpa0 mac 00:11:22:33:44:55
>
> root@L1# vdpa -jp dev config show vdpa0
> {
> "config": {
> "vdpa0": {
> "mac": "00:11:22:33:44:55",
> "link ": "up",
> "link_announce ": false,
> "mtu": 1500
> }
> }
> }
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/vdpa.c | 84 +++
> include/linux/vdpa.h | 9 +
> include/uapi/linux/vdpa.h | 1 +
> 3 files changed, 94 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> index 8d391947eb8d..07d61ee62839 100644
> --- a/drivers/vdpa/vdpa.c
> +++ b/drivers/vdpa/vdpa.c
> @@ -1361,6 +1361,85 @@ static int vdpa_nl_cmd_dev_config_get_doit(struct
> sk_buff *skb, struct genl_info
> return err;
> }
>
> +static int vdpa_dev_net_device_attr_set(struct vdpa_device *vdev,
> + struct genl_info *info)
> +{
> + struct vdpa_dev_set_config set_config = {};
> + const u8 *macaddr;
> + struct vdpa_mgmt_dev *mdev = vdev->mdev;
> + struct nlattr **nl_attrs = info->attrs;
> + int err = -EINVAL;
> +
> + if (!vdev->mdev)
> + return -EINVAL;
It looks like the caller has already done this check?
> +
> + down_write(>cf_lock);
> + if ((mdev->supported_features & BIT_ULL(VIRTIO_NET_F_MAC)) &&
This is not a virtio feature, so I don't get why we need to check
VIRTIO_NET_F_MAC.
> + nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]) {
> + set_config.mask |= BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MACADDR);
> + macaddr = nla_data(nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]);
> +
> + if (is_valid_ether_addr(macaddr)) {
> + memcpy(set_config.net.mac, macaddr, ETH_ALEN);
> + if (mdev->ops->dev_set_attr) {
> + err = mdev->ops->dev_set_attr(mdev, vdev,
> + _config);
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> + "device not
> supported");
"Device does not support setting mac address" ?
> + }
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> + "Invalid MAC address");
> + }
> + }
> + up_write(>cf_lock);
> + return err;
> +}
> +static int vdpa_nl_cmd_dev_attr_set_doit(struct sk_buff *skb,
> +struct genl_info *info)
> +{
> + const char *name;
> + int err = 0;
> + struct device *dev;
> + struct vdpa_device *vdev;
> + u64 classes;
> +
> + if (!info->attrs[VDPA_ATTR_DEV_NAME])
> + return -EINVAL;
> +
> + name = nla_data(info->attrs[VDPA_ATTR_DEV_NAME]);
> +
> + down_write(_dev_lock);
> + dev = bus_find_device(_bus, NULL, name, vdpa_name_match);
> + if (!dev) {
> + NL_SET_ERR_MSG_MOD(info->extack, "device not found");
> + err = -ENODEV;
> + goto dev_err;
> + }
> + vdev = container_of(dev, struct vdpa_device, dev);
> + if (!vdev->mdev) {
> + NL_SET_ERR_MSG_MOD(
> + info->extack,
> + "Fail to find the specified management device");
> + err = -EINVAL;
> + goto mdev_err;
> + }
> + classes = vdpa_mgmtdev_get_classes(vdev->mdev, NULL);
> + if (classes & BIT_ULL(VIRTIO_ID_NET)) {
> + err = vdpa_dev_net_device_attr_set(vdev, info);
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack, "%s device not
> supported",
> + name);
> + }
> +
> +mdev_err:
> + put_device(dev);
> +dev_err:
> + up_write(_dev_lock);
> + return err;
> +}
> +
> static int vdpa_dev_config_dump(struct device *dev, void *data)
> {
> struct vdpa_device *vdev = container_of(dev, struct vdpa_device, dev);
> @@ -1497,6 +1576,11 @@ static const struct genl_ops vdpa_nl_ops[] = {
> .doit = vdpa_nl_cmd_dev_stats_get_doit,
> .flags = GENL_ADMIN_PERM,
> },
> + {
> + .cmd =
Re: [PATCH 04/17] arch, mm: move definition of node_data to generic code
On Tue, 16 Jul 2024, Mike Rapoport wrote:\n From: "Mike Rapoport (Microsoft)" Every architecture that supports NUMA defines node_data in the same way: struct pglist_data *node_data[MAX_NUMNODES]; No reason to keep multiple copies of this definition and its forward declarations, especially when such forward declaration is the only thing in include/asm/mmzone.h for many architectures. Add definition and declaration of node_data to generic code and drop architecture-specific versions. Signed-off-by: Mike Rapoport (Microsoft) Nice cleanup. Acked-by: Davidlohr Bueso
Re: [PATCH 1/2] x86/tdx: Add prctl to allow userlevel TDX hypercalls
Thanks for the review, Kirill. On Mon, Jul 08, 2024 at 03:19:54PM +0300, Kirill A . Shutemov wrote: > Hm. Per-thread flag is odd. I think it should be per-process. This is the only point I might need some clarification on. I agree there doesn't seem to be much value in allowing per-thread control, but I don't see any precedence for setting per-process flags through arch_prctl or similar interfaces. Am I missing something?
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Tue, 23 Jul 2024 at 09:28, Jason Wang wrote:
>
> On Mon, Jul 22, 2024 at 10:48 PM Cindy Lu wrote:
> >
> > On Mon, 22 Jul 2024 at 20:55, Cindy Lu wrote:
> > >
> > > On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
> > > >
> > > > On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > > > > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > > > > >
> > > > > > Add the function to support setting the MAC address.
> > > > > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > > > > to set the mac address
> > > > > >
> > > > > > Tested in ConnectX-6 Dx device
> > > > > >
> > > > > > Signed-off-by: Cindy Lu
> > > > > > ---
> > > > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > > > > 1 file changed, 25 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > index ecfc16151d61..415b527a9c72 100644
> > > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > > > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > > > > destroy_workqueue(wq);
> > > > > > mgtdev->ndev = NULL;
> > > > > > }
> > > > > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > > > > + struct vdpa_device *dev,
> > > > > > + const struct vdpa_dev_set_config
> > > > > > *add_config)
> > > > > > +{
> > > > > > + struct mlx5_vdpa_dev *mvdev;
> > > > > > + struct mlx5_vdpa_net *ndev;
> > > > > > + struct mlx5_core_dev *mdev;
> > > > > > + struct virtio_net_config *config;
> > > > > > + struct mlx5_core_dev *pfmdev;
> > > > Reverse xmas tree?
> > > >
> > > will fix this
> > > > > > + int err = -EOPNOTSUPP;
> > > > > > +
> > > > > > + mvdev = to_mvdev(dev);
> > > > > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > > > > + mdev = mvdev->mdev;
> > > > > > + config = >config;
> > > > > > +
> > > > You still need to take the ndev->reslock.
> > > >
> > > sure, will do
> > > > > > + if (add_config->mask & (1 <<
> > > > > > VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > > > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > > > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > > > > + if (!err)
> > > > > > + memcpy(config->mac, add_config->net.mac,
> > > > > > ETH_ALEN);
> > > > What is the expected behaviour when the device is in use?
> > > >
> > > if the err is 0 then copy the Mac address to config
> > > will change this code to make it more clear
> > > Thanks
> > > Cindy
> > sorry for the misunderstanding. The VDPA tool does not support
> > changing the MAC address after the guest is loaded. I think I can add
> > a check for VIRTIO_CONFIG_S_DRIVER_OK here?
>
> Still racy, and I think we probably don't worry about that case. It's
> the fault of the mgmt layer not us.
>
> Thanks
>
Sure, Thanks Jason. will send a new version soon
Thanks
cindy
> > Thanks
> > cindy
> > > > > > + }
> > > > > > + return err;
> > > > >
> > > > > Similar to net simulator, how could be serialize the modification to
> > > > > mac address:
> > > > >
> > > > > 1) from vdpa tool
> > > > > 2) via control virtqueue
> > > > >
> > > > > Thanks
> > > > >
> > > > > > +}
> > > > > >
> > > > > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > > > > .dev_add = mlx5_vdpa_dev_add,
> > > > > > .dev_del = mlx5_vdpa_dev_del,
> > > > > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > > > > };
> > > > > >
> > > > > > static struct virtio_device_id id_table[] = {
> > > > > > --
> > > > > > 2.45.0
> > > > > >
> > > > >
> > > > Thanks,
> > > > Dragos
> >
>
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, Jul 22, 2024 at 5:45 PM Dragos Tatulea wrote:
>
> On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > to set the mac address
> > >
> > > Tested in ConnectX-6 Dx device
> > >
> > > Signed-off-by: Cindy Lu
> > > ---
> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > 1 file changed, 25 insertions(+)
> > >
> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > index ecfc16151d61..415b527a9c72 100644
> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > destroy_workqueue(wq);
> > > mgtdev->ndev = NULL;
> > > }
> > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > + struct vdpa_device *dev,
> > > + const struct vdpa_dev_set_config
> > > *add_config)
> > > +{
> > > + struct mlx5_vdpa_dev *mvdev;
> > > + struct mlx5_vdpa_net *ndev;
> > > + struct mlx5_core_dev *mdev;
> > > + struct virtio_net_config *config;
> > > + struct mlx5_core_dev *pfmdev;
> Reverse xmas tree?
>
> > > + int err = -EOPNOTSUPP;
> > > +
> > > + mvdev = to_mvdev(dev);
> > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > + mdev = mvdev->mdev;
> > > + config = >config;
> > > +
> You still need to take the ndev->reslock.
>
> > > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > + if (!err)
> > > + memcpy(config->mac, add_config->net.mac,
> > > ETH_ALEN);
> What is the expected behaviour when the device is in use?
Should be a fault of the mgmt layer, so I think we probably don't need
to worry about that.
Thanks
>
> > > + }
> > > + return err;
> >
> > Similar to net simulator, how could be serialize the modification to
> > mac address:
> >
> > 1) from vdpa tool
> > 2) via control virtqueue
> >
> > Thanks
> >
> > > +}
> > >
> > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > .dev_add = mlx5_vdpa_dev_add,
> > > .dev_del = mlx5_vdpa_dev_del,
> > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > };
> > >
> > > static struct virtio_device_id id_table[] = {
> > > --
> > > 2.45.0
> > >
> >
> Thanks,
> Dragos
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, Jul 22, 2024 at 10:48 PM Cindy Lu wrote:
>
> On Mon, 22 Jul 2024 at 20:55, Cindy Lu wrote:
> >
> > On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
> > >
> > > On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > > > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > > > >
> > > > > Add the function to support setting the MAC address.
> > > > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > > > to set the mac address
> > > > >
> > > > > Tested in ConnectX-6 Dx device
> > > > >
> > > > > Signed-off-by: Cindy Lu
> > > > > ---
> > > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > > > 1 file changed, 25 insertions(+)
> > > > >
> > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > index ecfc16151d61..415b527a9c72 100644
> > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > > > destroy_workqueue(wq);
> > > > > mgtdev->ndev = NULL;
> > > > > }
> > > > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > > > + struct vdpa_device *dev,
> > > > > + const struct vdpa_dev_set_config
> > > > > *add_config)
> > > > > +{
> > > > > + struct mlx5_vdpa_dev *mvdev;
> > > > > + struct mlx5_vdpa_net *ndev;
> > > > > + struct mlx5_core_dev *mdev;
> > > > > + struct virtio_net_config *config;
> > > > > + struct mlx5_core_dev *pfmdev;
> > > Reverse xmas tree?
> > >
> > will fix this
> > > > > + int err = -EOPNOTSUPP;
> > > > > +
> > > > > + mvdev = to_mvdev(dev);
> > > > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > > > + mdev = mvdev->mdev;
> > > > > + config = >config;
> > > > > +
> > > You still need to take the ndev->reslock.
> > >
> > sure, will do
> > > > > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > > > + if (!err)
> > > > > + memcpy(config->mac, add_config->net.mac,
> > > > > ETH_ALEN);
> > > What is the expected behaviour when the device is in use?
> > >
> > if the err is 0 then copy the Mac address to config
> > will change this code to make it more clear
> > Thanks
> > Cindy
> sorry for the misunderstanding. The VDPA tool does not support
> changing the MAC address after the guest is loaded. I think I can add
> a check for VIRTIO_CONFIG_S_DRIVER_OK here?
Still racy, and I think we probably don't worry about that case. It's
the fault of the mgmt layer not us.
Thanks
> Thanks
> cindy
> > > > > + }
> > > > > + return err;
> > > >
> > > > Similar to net simulator, how could be serialize the modification to
> > > > mac address:
> > > >
> > > > 1) from vdpa tool
> > > > 2) via control virtqueue
> > > >
> > > > Thanks
> > > >
> > > > > +}
> > > > >
> > > > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > > > .dev_add = mlx5_vdpa_dev_add,
> > > > > .dev_del = mlx5_vdpa_dev_del,
> > > > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > > > };
> > > > >
> > > > > static struct virtio_device_id id_table[] = {
> > > > > --
> > > > > 2.45.0
> > > > >
> > > >
> > > Thanks,
> > > Dragos
>
Re: tracing: user events UAF crash report
On Fri, 19 Jul 2024 22:47:01 +0200
Mathias Krause wrote:
> Subject: [PATCH] eventfs: Don't return NULL in eventfs_create_dir()
>
> Commit 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing
> ei->dentry") added another check, testing if the parent was freed after
> we released the mutex. If so, the function returns NULL. However, all
> callers expect it to either return a valid pointer or an error pointer,
> at least since commit 5264a2f4bb3b ("tracing: Fix a NULL vs IS_ERR() bug
> in event_subsystem_dir()"). Returning NULL will therefore fail the error
> condition check in the caller.
>
> Fix this by substituting the NULL return value with a fitting error
> pointer.
>
> Fixes: 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing
> ei->dentry")
> Cc: Dan Carpenter
> Signed-off-by: Mathias Krause
This will not get into the workflow without being sent as a normal patch.
Please send it and Cc those listed in MAINTAINERS (see get_maintainers.pl).
-- Steve
> ---
> fs/tracefs/event_inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
> index 5d88c184f0fc..a9c28a1d5dc8 100644
> --- a/fs/tracefs/event_inode.c
> +++ b/fs/tracefs/event_inode.c
> @@ -736,7 +736,7 @@ struct eventfs_inode *eventfs_create_dir(const char
> *name, struct eventfs_inode
> /* Was the parent freed? */
> if (list_empty(>list)) {
> cleanup_ei(ei);
> - ei = NULL;
> + ei = ERR_PTR(-EBUSY);
> }
> return ei;
Re: [PATCH bpf-next] bpf: allow bpf_current_task_under_cgroup() with BPF_CGROUP_*
On Mon, Jul 22, 2024 at 11:21 AM wrote:
>
> From: Matteo Croce
>
> The helper bpf_current_task_under_cgroup() currently is only allowed for
> tracing programs.
> Allow its usage also in the BPF_CGROUP_* program types.
> Move the code from kernel/trace/bpf_trace.c to kernel/bpf/cgroup.c,
> so it compiles also without CONFIG_BPF_EVENTS.
>
> Signed-off-by: Matteo Croce
> ---
> include/linux/bpf.h | 1 +
> kernel/bpf/cgroup.c | 25 +
> kernel/trace/bpf_trace.c | 27 ++-
> 3 files changed, 28 insertions(+), 25 deletions(-)
>
It seems fine to allow this, but also note that we have
bpf_task_under_cgroup() kfunc, which you might want to check if it is
allowed where you need it as well.
And the latter one is defined in kernel/bpf/helpers.c, so I'd move
this one next to it to keep them close.
pw-bot: cr
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 4f1d4a97b9d1..4000fd161dda 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -3188,6 +3188,7 @@ extern const struct bpf_func_proto
> bpf_sock_hash_update_proto;
> extern const struct bpf_func_proto bpf_get_current_cgroup_id_proto;
> extern const struct bpf_func_proto bpf_get_current_ancestor_cgroup_id_proto;
> extern const struct bpf_func_proto bpf_get_cgroup_classid_curr_proto;
> +extern const struct bpf_func_proto bpf_current_task_under_cgroup_proto;
> extern const struct bpf_func_proto bpf_msg_redirect_hash_proto;
> extern const struct bpf_func_proto bpf_msg_redirect_map_proto;
> extern const struct bpf_func_proto bpf_sk_redirect_hash_proto;
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 8ba73042a239..b99add9570e6 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -2308,6 +2308,29 @@ static const struct bpf_func_proto
> bpf_get_netns_cookie_sockopt_proto = {
> };
> #endif
>
> +BPF_CALL_2(bpf_current_task_under_cgroup, struct bpf_map *, map, u32, idx)
> +{
> + struct bpf_array *array = container_of(map, struct bpf_array, map);
> + struct cgroup *cgrp;
> +
> + if (unlikely(idx >= array->map.max_entries))
> + return -E2BIG;
> +
> + cgrp = READ_ONCE(array->ptrs[idx]);
> + if (unlikely(!cgrp))
> + return -EAGAIN;
> +
> + return task_under_cgroup_hierarchy(current, cgrp);
> +}
> +
> +const struct bpf_func_proto bpf_current_task_under_cgroup_proto = {
> + .func = bpf_current_task_under_cgroup,
> + .gpl_only = false,
> + .ret_type = RET_INTEGER,
> + .arg1_type = ARG_CONST_MAP_PTR,
> + .arg2_type = ARG_ANYTHING,
> +};
> +
> static const struct bpf_func_proto *
> cg_sockopt_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> {
> @@ -2581,6 +2604,8 @@ cgroup_current_func_proto(enum bpf_func_id func_id,
> const struct bpf_prog *prog)
> case BPF_FUNC_get_cgroup_classid:
> return _get_cgroup_classid_curr_proto;
> #endif
> + case BPF_FUNC_current_task_under_cgroup:
> + return _current_task_under_cgroup_proto;
> default:
> return NULL;
> }
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index cd098846e251..ea5cdd122024 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -798,29 +798,6 @@ const struct bpf_func_proto bpf_task_pt_regs_proto = {
> .ret_btf_id = _task_pt_regs_ids[0],
> };
>
> -BPF_CALL_2(bpf_current_task_under_cgroup, struct bpf_map *, map, u32, idx)
> -{
> - struct bpf_array *array = container_of(map, struct bpf_array, map);
> - struct cgroup *cgrp;
> -
> - if (unlikely(idx >= array->map.max_entries))
> - return -E2BIG;
> -
> - cgrp = READ_ONCE(array->ptrs[idx]);
> - if (unlikely(!cgrp))
> - return -EAGAIN;
> -
> - return task_under_cgroup_hierarchy(current, cgrp);
> -}
> -
> -static const struct bpf_func_proto bpf_current_task_under_cgroup_proto = {
> - .func = bpf_current_task_under_cgroup,
> - .gpl_only = false,
> - .ret_type = RET_INTEGER,
> - .arg1_type = ARG_CONST_MAP_PTR,
> - .arg2_type = ARG_ANYTHING,
> -};
> -
> struct send_signal_irq_work {
> struct irq_work irq_work;
> struct task_struct *task;
> @@ -1548,8 +1525,6 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const
> struct bpf_prog *prog)
> return _get_numa_node_id_proto;
> case BPF_FUNC_perf_event_read:
> return _perf_event_read_proto;
> - case BPF_FUNC_current_task_under_cgroup:
> - return _current_task_under_cgroup_proto;
> case BPF_FUNC_get_prandom_u32:
> return _get_prandom_u32_proto;
> case BPF_FUNC_probe_write_user:
> @@ -1578,6 +1553,8 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const
> struct bpf_prog *prog)
>
Re: [PATCH v2] remoteproc: xlnx: add sram support
Good morning,
On Mon, Jul 15, 2024 at 06:39:54PM -0700, Tanmay Shah wrote:
> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> R5 cores can access OCM and access is faster than DDR memory but slower
> than TCM memories available. Sram region can have optional multiple
> power-domains. Platform management firmware is responsible
> to operate these power-domains.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v2:
> - Expand commit message with power-domains related information.
>
> drivers/remoteproc/xlnx_r5_remoteproc.c | 131
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 596f3ffb8935..52ddd42b09e0 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -56,6 +56,17 @@ struct mem_bank_data {
> char *bank_name;
> };
>
> +/**
> + * struct zynqmp_sram_bank - sram bank description
> + *
> + * @sram_res: sram address region information
> + * @da: device address of sram
> + */
> +struct zynqmp_sram_bank {
> + struct resource sram_res;
> + u32 da;
> +};
> +
> /**
> * struct mbox_info
> *
> @@ -120,6 +131,8 @@ static const struct mem_bank_data
> zynqmp_tcm_banks_lockstep[] = {
> * struct zynqmp_r5_core
> *
> * @rsc_tbl_va: resource table virtual address
> + * @sram: Array of sram memories assigned to this core
> + * @num_sram: number of sram for this core
> * @dev: device of RPU instance
> * @np: device node of RPU instance
> * @tcm_bank_count: number TCM banks accessible to this RPU
> @@ -131,6 +144,8 @@ static const struct mem_bank_data
> zynqmp_tcm_banks_lockstep[] = {
> */
> struct zynqmp_r5_core {
> void __iomem *rsc_tbl_va;
> + struct zynqmp_sram_bank **sram;
I suggest making @sram an array rather than an array of pointers - it would
simplify function zynqmp_r5_get_sram_banks().
> + int num_sram;
> struct device *dev;
> struct device_node *np;
> int tcm_bank_count;
> @@ -494,6 +509,40 @@ static int add_mem_regions_carveout(struct rproc *rproc)
> return 0;
> }
>
> +static int add_sram_carveouts(struct rproc *rproc)
> +{
> + struct zynqmp_r5_core *r5_core = rproc->priv;
> + struct rproc_mem_entry *rproc_mem;
> + struct zynqmp_sram_bank *sram;
> + dma_addr_t dma_addr;
> + size_t len;
> + int da, i;
> +
> + for (i = 0; i < r5_core->num_sram; i++) {
> + sram = r5_core->sram[i];
> +
> + dma_addr = (dma_addr_t)sram->sram_res.start;
> + len = resource_size(>sram_res);
> + da = sram->da;
> +
> + /* Register associated reserved memory regions */
> + rproc_mem = rproc_mem_entry_init(>dev, NULL,
> + (dma_addr_t)dma_addr,
> + len, da,
> + zynqmp_r5_mem_region_map,
> + zynqmp_r5_mem_region_unmap,
> + sram->sram_res.name);
> +
> + rproc_add_carveout(rproc, rproc_mem);
> + rproc_coredump_add_segment(rproc, da, len);
> +
> + dev_dbg(>dev, "sram carveout %s addr=%llx, da=0x%x,
> size=0x%lx",
> + sram->sram_res.name, dma_addr, da, len);
> + }
> +
> + return 0;
> +}
> +
> /*
> * tcm_mem_unmap()
> * @rproc: single R5 core's corresponding rproc instance
> @@ -669,6 +718,12 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
> return ret;
> }
>
> + ret = add_sram_carveouts(rproc);
> + if (ret) {
> + dev_err(>dev, "failed to get sram carveout %d\n", ret);
> + return ret;
> + }
> +
> return 0;
> }
>
> @@ -881,6 +936,78 @@ static struct zynqmp_r5_core
> *zynqmp_r5_add_rproc_core(struct device *cdev)
> return ERR_PTR(ret);
> }
>
> +static int zynqmp_r5_get_sram_banks(struct zynqmp_r5_core *r5_core)
> +{
> + struct zynqmp_sram_bank **sram, *sram_data;
> + struct device_node *np = r5_core->np;
> + struct device *dev = r5_core->dev;
> + struct device_node *sram_np;
> + int num_sram, i, ret;
> + u64 abs_addr, size;
> +
> + /* "sram" is optional proprty. Do not fail, if unavailable. */
s/proprty/property
> + if (!of_find_property(r5_core->np, "sram", NULL))
> + return 0;
> +
> + num_sram = of_property_count_elems_of_size(np, "sram", sizeof(phandle));
> + if (num_sram <= 0) {
Any reason this is "<" rather than "<=" ?
> + dev_err(dev, "Invalid sram property, ret = %d\n",
> + num_sram);
> + return -EINVAL;
> + }
> +
> + sram = devm_kcalloc(dev, num_sram,
> + sizeof(struct zynqmp_sram_bank *), GFP_KERNEL);
> + if (!sram)
> + return -ENOMEM;
> +
Re: [PATCH 4/4] ASoC: qcom: apq8016_sbc: Add support for msm8953/msm8976 SoC
Hi Adam,
kernel test robot noticed the following build warnings:
[auto build test WARNING on v6.10]
[also build test WARNING on linus/master next-20240722]
[cannot apply to broonie-sound/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Adam-Skladowski/ASoC-qcom-apq8016_sbc-c-Add-Quinary-support/20240722-181331
base: v6.10
patch link:
https://lore.kernel.org/r/20240722095147.3372-5-a39.skl%40gmail.com
patch subject: [PATCH 4/4] ASoC: qcom: apq8016_sbc: Add support for
msm8953/msm8976 SoC
config: s390-allmodconfig
(https://download.01.org/0day-ci/archive/20240722/20240718.nkjhmm5n-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
ad154281230d83ee551e12d5be48bb956ef47ed3)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240722/20240718.nkjhmm5n-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/20240718.nkjhmm5n-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from sound/soc/qcom/apq8016_sbc.c:6:
In file included from include/linux/device.h:32:
In file included from include/linux/device/driver.h:21:
In file included from include/linux/module.h:19:
In file included from include/linux/elf.h:6:
In file included from arch/s390/include/asm/elf.h:173:
In file included from arch/s390/include/asm/mmu_context.h:11:
In file included from arch/s390/include/asm/pgalloc.h:18:
In file included from include/linux/mm.h:2258:
include/linux/vmstat.h:500:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
500 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
501 |item];
|
include/linux/vmstat.h:507:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
507 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
508 |NR_VM_NUMA_EVENT_ITEMS +
|~~
include/linux/vmstat.h:514:36: warning: arithmetic between different
enumeration types ('enum node_stat_item' and 'enum lru_list')
[-Wenum-enum-conversion]
514 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
| ~~~ ^ ~~~
include/linux/vmstat.h:519:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
519 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
520 |NR_VM_NUMA_EVENT_ITEMS +
|~~
include/linux/vmstat.h:528:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
528 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
529 |NR_VM_NUMA_EVENT_ITEMS +
|~~
In file included from sound/soc/qcom/apq8016_sbc.c:9:
In file included from include/linux/io.h:14:
In file included from arch/s390/include/asm/io.h:93:
include/asm-generic/io.h:548:31: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
548 | val = __raw_readb(PCI_IOBASE + addr);
| ~~ ^
include/asm-generic/io.h:561:61: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
561 | val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE +
addr));
| ~~ ^
include/uapi/linux/byteorder/big_endian.h:37:59: note: expanded from macro
'__le16_to_cpu'
37 | #define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x))
| ^
include/uapi/linux/swab.h:102:54: note: expanded from macro '__swab16'
102 | #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))
| ^
In file
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, 22 Jul 2024 at 20:55, Cindy Lu wrote:
>
> On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
> >
> > On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > > >
> > > > Add the function to support setting the MAC address.
> > > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > > to set the mac address
> > > >
> > > > Tested in ConnectX-6 Dx device
> > > >
> > > > Signed-off-by: Cindy Lu
> > > > ---
> > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > > 1 file changed, 25 insertions(+)
> > > >
> > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > index ecfc16151d61..415b527a9c72 100644
> > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > > destroy_workqueue(wq);
> > > > mgtdev->ndev = NULL;
> > > > }
> > > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > > + struct vdpa_device *dev,
> > > > + const struct vdpa_dev_set_config
> > > > *add_config)
> > > > +{
> > > > + struct mlx5_vdpa_dev *mvdev;
> > > > + struct mlx5_vdpa_net *ndev;
> > > > + struct mlx5_core_dev *mdev;
> > > > + struct virtio_net_config *config;
> > > > + struct mlx5_core_dev *pfmdev;
> > Reverse xmas tree?
> >
> will fix this
> > > > + int err = -EOPNOTSUPP;
> > > > +
> > > > + mvdev = to_mvdev(dev);
> > > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > > + mdev = mvdev->mdev;
> > > > + config = >config;
> > > > +
> > You still need to take the ndev->reslock.
> >
> sure, will do
> > > > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > > + if (!err)
> > > > + memcpy(config->mac, add_config->net.mac,
> > > > ETH_ALEN);
> > What is the expected behaviour when the device is in use?
> >
> if the err is 0 then copy the Mac address to config
> will change this code to make it more clear
> Thanks
> Cindy
sorry for the misunderstanding. The VDPA tool does not support
changing the MAC address after the guest is loaded. I think I can add
a check for VIRTIO_CONFIG_S_DRIVER_OK here?
Thanks
cindy
> > > > + }
> > > > + return err;
> > >
> > > Similar to net simulator, how could be serialize the modification to
> > > mac address:
> > >
> > > 1) from vdpa tool
> > > 2) via control virtqueue
> > >
> > > Thanks
> > >
> > > > +}
> > > >
> > > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > > .dev_add = mlx5_vdpa_dev_add,
> > > > .dev_del = mlx5_vdpa_dev_del,
> > > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > > };
> > > >
> > > > static struct virtio_device_id id_table[] = {
> > > > --
> > > > 2.45.0
> > > >
> > >
> > Thanks,
> > Dragos
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
>
> On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > to set the mac address
> > >
> > > Tested in ConnectX-6 Dx device
> > >
> > > Signed-off-by: Cindy Lu
> > > ---
> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > 1 file changed, 25 insertions(+)
> > >
> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > index ecfc16151d61..415b527a9c72 100644
> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > destroy_workqueue(wq);
> > > mgtdev->ndev = NULL;
> > > }
> > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > + struct vdpa_device *dev,
> > > + const struct vdpa_dev_set_config
> > > *add_config)
> > > +{
> > > + struct mlx5_vdpa_dev *mvdev;
> > > + struct mlx5_vdpa_net *ndev;
> > > + struct mlx5_core_dev *mdev;
> > > + struct virtio_net_config *config;
> > > + struct mlx5_core_dev *pfmdev;
> Reverse xmas tree?
>
will fix this
> > > + int err = -EOPNOTSUPP;
> > > +
> > > + mvdev = to_mvdev(dev);
> > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > + mdev = mvdev->mdev;
> > > + config = >config;
> > > +
> You still need to take the ndev->reslock.
>
sure, will do
> > > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > + if (!err)
> > > + memcpy(config->mac, add_config->net.mac,
> > > ETH_ALEN);
> What is the expected behaviour when the device is in use?
>
if the err is 0 then copy the Mac address to config
will change this code to make it more clear
Thanks
Cindy
> > > + }
> > > + return err;
> >
> > Similar to net simulator, how could be serialize the modification to
> > mac address:
> >
> > 1) from vdpa tool
> > 2) via control virtqueue
> >
> > Thanks
> >
> > > +}
> > >
> > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > .dev_add = mlx5_vdpa_dev_add,
> > > .dev_del = mlx5_vdpa_dev_del,
> > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > };
> > >
> > > static struct virtio_device_id id_table[] = {
> > > --
> > > 2.45.0
> > >
> >
> Thanks,
> Dragos
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, 22 Jul 2024 at 15:49, Jason Wang wrote:
>
> On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > to set the mac address
> >
> > Tested in ConnectX-6 Dx device
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index ecfc16151d61..415b527a9c72 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
> > *v_mdev, struct vdpa_device *
> > destroy_workqueue(wq);
> > mgtdev->ndev = NULL;
> > }
> > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > + struct vdpa_device *dev,
> > + const struct vdpa_dev_set_config *add_config)
> > +{
> > + struct mlx5_vdpa_dev *mvdev;
> > + struct mlx5_vdpa_net *ndev;
> > + struct mlx5_core_dev *mdev;
> > + struct virtio_net_config *config;
> > + struct mlx5_core_dev *pfmdev;
> > + int err = -EOPNOTSUPP;
> > +
> > + mvdev = to_mvdev(dev);
> > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > + mdev = mvdev->mdev;
> > + config = >config;
> > +
> > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > + if (!err)
> > + memcpy(config->mac, add_config->net.mac, ETH_ALEN);
> > + }
> > + return err;
>
> Similar to net simulator, how could be serialize the modification to
> mac address:
>
> 1) from vdpa tool
> 2) via control virtqueue
>
> Thanks
>
sure. Wiil do
thanks
cindy
> > +}
> >
> > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > .dev_add = mlx5_vdpa_dev_add,
> > .dev_del = mlx5_vdpa_dev_del,
> > + .dev_set_attr = mlx5_vdpa_set_attr,
> > };
> >
> > static struct virtio_device_id id_table[] = {
> > --
> > 2.45.0
> >
>
Re: [PATCH 1/4] ASoC: qcom: apq8016_sbc.c: Add Quinary support
On Mon, Jul 22, 2024 at 11:51:05AM GMT, Adam Skladowski wrote: > From: Vladimir Lypak > > Add support for configuring Quinary Mi2S interface > it will be used on MSM8953 and MSM8976 platform. > > Signed-off-by: Vladimir Lypak > [Adam: Split from MSM8953 support patch,add msg] > Signed-off-by: Adam Skladowski > --- > sound/soc/qcom/apq8016_sbc.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/qcom/apq8016_sbc.c b/sound/soc/qcom/apq8016_sbc.c > index 3023cf180a75..8971f4f5d339 100644 > --- a/sound/soc/qcom/apq8016_sbc.c > +++ b/sound/soc/qcom/apq8016_sbc.c > @@ -320,6 +330,10 @@ static int apq8016_sbc_platform_probe(struct > platform_device *pdev) > if (IS_ERR(data->spkr_iomux)) > return PTR_ERR(data->spkr_iomux); > > + data->quin_iomux = devm_platform_ioremap_resource_byname(pdev, > "quin-iomux"); This should probably handle -ENOENT (or -ENODEV?) case and set the pointer to NULL. > + if (IS_ERR(data->quin_iomux)) > + return PTR_ERR(data->quin_iomux); > + > snd_soc_card_set_drvdata(card, data); > > add_ops(card); > -- > 2.45.2 > -- With best wishes Dmitry
Re: tracing: user events UAF crash report
On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause wrote: > > Hi Steven, Ajay, > > [ @Cc list: I found out issues with tracefs have been reported / > attempted to get fixed in the past, so you may be interested. ] > > I noticed, the user events ftrace selftest is crashing every now and > then in our automated tests. Digging into, I found that the following > is triggering the issue very reliable: > > - in one shell, as root: > # while true; do ./kselftest/user_events/ftrace_test; done > > - in a second shell, again as root: > # cd /sys/kernel/tracing > # while true; do cat events/user_events/__test_event/format; done > 2>/dev/null > Tried to reproduced on 6.10.0-rc7-100.ph5+, only getting repeated output as: # while true; do cat events/user_events/__test_event/format; done 2>/dev/null print fmt: "" name: __test_event ID: 2390 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; # while true; do ./kselftest/user_events/ftrace_test; done TAP version 13 1..6 # Starting 6 tests from 1 test cases. # RUN user.register_events ... #OK user.register_events ok 1 user.register_events # RUN user.write_events ... #OK user.write_events ok 2 user.write_events # RUN user.write_empty_events ... #OK user.write_empty_events ok 3 user.write_empty_events # RUN user.write_fault ... #OK user.write_fault ok 4 user.write_fault # RUN user.write_validator ... #OK user.write_validator ok 5 user.write_validator # RUN user.print_fmt ... #OK user.print_fmt ok 6 user.print_fmt # PASSED: 6 / 6 tests passed. # Totals: pass:6 fail:0 xfail:0 xpass:0 skip:0 error:0 Am I missing any step? > Ignoring that the selftest fails for half of its tests -- which is a > regression and therefore yet another bug, I guess -- this triggers an > access fault (GFP/PF/NULL deref) after a few iterations, usually within > a minute, mostly mere seconds. With KASAN enabled it generates a splat > almost instantly, like following: > > [ 23.790955] > == > [ 23.791692] BUG: KASAN: slab-use-after-free in f_show+0x43b/0x470 > [ 23.792244] Read of size 8 at addr 888007076878 by task cat/755 > [ 23.792753] > [ 23.792947] CPU: 1 PID: 755 Comm: cat Tainted: G D N > 6.10.0-vanilla-dirty #30 > [ 23.793563] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 > [ 23.794280] Call Trace: > [ 23.794470] > [ 23.794642] dump_stack_lvl+0x66/0xa0 > [ 23.794909] print_report+0xd0/0x630 > [ 23.795180] ? f_show+0x43b/0x470 > [ 23.795415] ? __virt_addr_valid+0x208/0x3f0 > [ 23.795700] ? f_show+0x43b/0x470 > [ 23.795935] kasan_report+0xd8/0x110 > [ 23.796183] ? f_show+0x43b/0x470 > [ 23.796418] f_show+0x43b/0x470 > [ 23.796645] seq_read_iter+0x418/0x11e0 > [ 23.796907] ? __page_table_check_ptes_set+0x166/0x1a0 > [ 23.797280] seq_read+0x261/0x350 > [ 23.797537] ? lock_release+0x453/0x600 > [ 23.797819] ? __pfx_seq_read+0x10/0x10 > [ 23.798103] ? set_ptes.isra.0+0x11b/0x150 > [ 23.798402] vfs_read+0x171/0x9e0 > [ 23.798657] ? lock_acquire+0x408/0x4b0 > [ 23.798970] ? __pfx_vfs_read+0x10/0x10 > [ 23.799267] ? lock_release+0x453/0x600 > [ 23.799549] ? do_user_addr_fault+0x45b/0x8b0 > [ 23.799862] ? __pfx_lock_release+0x10/0x10 > [ 23.800162] ? __pfx___up_read+0x10/0x10 > [ 23.800448] ksys_read+0xdd/0x1a0 > [ 23.800704] ? __pfx_ksys_read+0x10/0x10 > [ 23.801007] ? do_user_addr_fault+0x465/0x8b0 > [ 23.801341] do_syscall_64+0x66/0x130 > [ 23.801615] entry_SYSCALL_64_after_hwframe+0x71/0x79 > [ 23.801959] RIP: 0033:0x7f1fdb9df40e > [ 23.802230] Code: c0 e9 b6 fe ff ff 50 48 8d 3d 2e 08 0b 00 e8 69 01 02 00 > 66 0f 1f 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d > 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28 > [ 23.803352] RSP: 002b:7fff86d62658 EFLAGS: 0246 ORIG_RAX: > > [ 23.803848] RAX: ffda RBX: 0002 RCX: > 7f1fdb9df40e > [ 23.804302] RDX: 0002 RSI: 7f1fdb8d3000 RDI: > 0003 > [ 23.804753] RBP: 7f1fdb8d3000 R08: 7f1fdb8d2010 R09: > > [ 23.805239] R10: fbc5 R11: 0246 R12: > > [ 23.805694] R13: 0003 R14: 0002 R15: > 0002 > [ 23.806153] > [ 23.806352] > [ 23.806518] Allocated by task 753: > [ 23.806781] kasan_save_stack+0x20/0x40 > [ 23.807094] kasan_save_track+0x14/0x30 > [ 23.807377] __kasan_kmalloc+0x8f/0xa0 > [ 23.807656]
Re: [PATCH 11/12] arm64: dts: qcom: sm6115-pro1x: Enable remoteprocs
On 22.07.2024 9:10 AM, Dang Huynh wrote: > Enable [A,C]DSP and MPSS remote processor on this device. > > Signed-off-by: Dang Huynh > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 09/12] arm64: dts: qcom: sm6115-pro1x: Add PMI632 Type-C property
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The USB-C port is used for powering external devices and transfer
> data from/to them.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konradqmpphy_out {
> + remote-endpoint = <_ss_in>;
> +};
> +
> _board {
> clock-frequency = <1920>;
> };
>
Re: [PATCH 07/12] arm64: dts: qcom: sm6115-pro1x: Hook up USB3 SS
On 22.07.2024 9:10 AM, Dang Huynh wrote: > The F(x)tec Pro1X supports USB 3.0 through it's USB-C port. > > Signed-off-by: Dang Huynh > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 1/2] module: Split modules_install compression and in-kernel decompression
On Mon, Jul 22, 2024 at 6:07 PM Petr Pavlu wrote: > > The kernel configuration allows specifying a module compression mode. If > one is selected then each module gets compressed during > 'make modules_install' and additionally one can also enable support for > a respective direct in-kernel decompression support. This means that the > decompression support cannot be enabled without the automatic compression. > > Some distributions, such as the (open)SUSE family, use a signer service for > modules. A build runs on a worker machine but signing is done by a separate > locked-down server that is in possession of the signing key. The build > invokes 'make modules_install' to create a modules tree, collects > information about the modules, asks the signer service for their signature, > appends each signature to the respective module and compresses all modules. > > When using this arrangment, the 'make modules_install' step produces > unsigned+uncompressed modules and the distribution's own build recipe takes > care of signing and compression later. > > The signing support can be currently enabled without automatically signing > modules during 'make modules_install'. However, the in-kernel decompression > support can be selected only after first enabling automatic compression > during this step. > > To allow only enabling the in-kernel decompression support without the > automatic compression during 'make modules_install', separate the > compression options similarly to the signing options, as follows: > > > Enable loadable module support > [*] Module compression > Module compression type (GZIP) ---> > [*] Automatically compress all modules > [ ] Support in-kernel module decompression > > * "Module compression" (MODULE_COMPRESS) is a new main switch for the > compression/decompression support. It replaces MODULE_COMPRESS_NONE. > * "Module compression type" (MODULE_COMPRESS_) chooses the > compression type, one of GZ, XZ, ZSTD. > * "Automatically compress all modules" (MODULE_COMPRESS_ALL) is a new > option to enable module compression during 'make modules_install'. It > defaults to Y. > * "Support in-kernel module decompression" (MODULE_DECOMPRESS) enables > in-kernel decompression. > > Signed-off-by: Petr Pavlu > --- My preference is to add CONFIG_MODULE_DECOMPRESS_GZIP CONFIG_MODULE_DECOMPRESS_XZ CONFIG_MODULE_DECOMPRESS_ZSTD instead of CONFIG_MODULE_COMPRESS_ALL. For example, if MODULE_DECOMPRESS config MODULE_DECOMPRESS_GZIP bool "Support in-kernel GZIP decompression for module" default MODULE_COMPRESS_GZIP config MODULE_DECOMPRESS_XZ bool "Support in-kernel XZ decompression for module" default MODULE_COMPRESS_XZ config MODULE_DECOMPRESS_ZSTD bool "Support in-kernel ZSTD decompression for module" default MODULE_COMPRESS_ZSTD endif OR, maybe config MODULE_DECOMPRESS_GZIP bool "Support in-kernel GZIP decompression for module" select MODULE_DECOMPRESS config MODULE_DECOMPRESS_XZ bool "Support in-kernel XZ decompression for module" select MODULE_DECOMPRESS config MODULE_DECOMPRESS_ZSTD bool "Support in-kernel ZSTD decompression for module" select MODULE_DECOMPRESS config MODULE_DECOMPRESS bool You can toggle MODULE_COMPRESS_GZIP and MODULE_DECOMPRESS_GZIP independently Of course, the current kernel/module/decompress.c does not work when multiple (or zero) CONFIG_MODULE_DECOMPRESS_* is enabled. It needs a little modification. I will wait for Lius's comment. > kernel/module/Kconfig| 61 > scripts/Makefile.modinst | 2 ++ > 2 files changed, 33 insertions(+), 30 deletions(-) > > diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig > index 4047b6d48255..bb7f7930fef6 100644 > --- a/kernel/module/Kconfig > +++ b/kernel/module/Kconfig > @@ -278,64 +278,65 @@ config MODULE_SIG_HASH > default "sha3-384" if MODULE_SIG_SHA3_384 > default "sha3-512" if MODULE_SIG_SHA3_512 > > -choice > - prompt "Module compression mode" > +config MODULE_COMPRESS > + bool "Module compression" > help > - This option allows you to choose the algorithm which will be used to > - compress modules when 'make modules_install' is run. (or, you can > - choose to not compress modules at all.) > - > - External modules will also be compressed in the same way during the > - installation. > - > - For modules inside an initrd or initramfs, it's more efficient to > - compress the whole initrd or initramfs instead. > - > + Enable module compression to reduce on-disk size of module binaries. > This is fully compatible with signed modules. > > - Please note that the tool used to load modules needs to support the > - corresponding algorithm. module-init-tools MAY support gzip, and > kmod > - MAY support gzip, xz and zstd. >
Re: [PATCH 06/12] arm64: dts: qcom: sm6115-pro1x: Enable MDSS and GPU
On 22.07.2024 11:17 AM, Dang Huynh wrote:
>>> +_dsi0_phy {
>>> + status = "okay";
>>
>> No power supplies?
>>
>> Konrad
>
> Doesn't seem to be defined anywhere on downstream, may be hardware controlled.
my downstream suggests L1b
Konrad
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > to set the mac address
> >
> > Tested in ConnectX-6 Dx device
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index ecfc16151d61..415b527a9c72 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
> > *v_mdev, struct vdpa_device *
> > destroy_workqueue(wq);
> > mgtdev->ndev = NULL;
> > }
> > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > + struct vdpa_device *dev,
> > + const struct vdpa_dev_set_config *add_config)
> > +{
> > + struct mlx5_vdpa_dev *mvdev;
> > + struct mlx5_vdpa_net *ndev;
> > + struct mlx5_core_dev *mdev;
> > + struct virtio_net_config *config;
> > + struct mlx5_core_dev *pfmdev;
Reverse xmas tree?
> > + int err = -EOPNOTSUPP;
> > +
> > + mvdev = to_mvdev(dev);
> > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > + mdev = mvdev->mdev;
> > + config = >config;
> > +
You still need to take the ndev->reslock.
> > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > + if (!err)
> > + memcpy(config->mac, add_config->net.mac, ETH_ALEN);
What is the expected behaviour when the device is in use?
> > + }
> > + return err;
>
> Similar to net simulator, how could be serialize the modification to
> mac address:
>
> 1) from vdpa tool
> 2) via control virtqueue
>
> Thanks
>
> > +}
> >
> > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > .dev_add = mlx5_vdpa_dev_add,
> > .dev_del = mlx5_vdpa_dev_del,
> > + .dev_set_attr = mlx5_vdpa_set_attr,
> > };
> >
> > static struct virtio_device_id id_table[] = {
> > --
> > 2.45.0
> >
>
Thanks,
Dragos
Re: [PATCH 06/12] arm64: dts: qcom: sm6115-pro1x: Enable MDSS and GPU
> > +_dsi0_phy {
> > + status = "okay";
>
> No power supplies?
>
> Konrad
Doesn't seem to be defined anywhere on downstream, may be hardware controlled.
Re: [PATCH 12/12] arm64: dts: qcom: sm6115-pro1x: Enable ATH10K WLAN
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> Enable onboard Wi-Fi on the F(x)tec Pro1X.
>
> For reference, HW/SW identifies as:
> qmi chip_id 0x120 chip_family 0x4007 board_id 0xff soc_id 0x4067
> qmi fw_version 0x324103d6 fw_build_timestamp 2021-12-02 08:20
> fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.4-00982-QCAHLSWMTPLZ-1
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> index 14d4f533f741..c148ebd1c8b4 100644
> --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> @@ -531,6 +531,17 @@ _qmpphy_out {
> remote-endpoint = <_ss_in>;
> };
>
> + {
> + status = "okay";
status goes last
Konrad
Re: [PATCH 10/12] arm64: dts: qcom: sm6115-pro1x: Enable RGB LED
On 22.07.2024 9:10 AM, Dang Huynh wrote: > This device has an RGB LED. It is used for notifications. > > Signed-off-by: Dang Huynh > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 06/12] arm64: dts: qcom: sm6115-pro1x: Enable MDSS and GPU
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> Fxtec Pro1x uses the same display (BOE BF060Y8M-AJ0) as Pro1.
>
> Signed-off-by: Dang Huynh
> ---
[...]
> + panel: panel@0 {
> + compatible = "boe,bf060y8m-aj0";
> + reg = <0>;
> +
> + reset-gpios = < 82 GPIO_ACTIVE_LOW>;
> +
> + vddio-supply = <_l9a>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_dsi_n _en_n>;
pinctrl-n
pinctrl-names
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_dsi0_out>;
> + };
> + };
> + };
> +};
> +
> +_dsi0_out {
> + data-lanes = <0 1 2 3>;
> + remote-endpoint = <_in>;
> +};
> +
> +_dsi0_phy {
> + status = "okay";
No power supplies?
Konrad
Re: [PATCH 03/12] arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen
> On 22.07.2024 9:10 AM, Dang Huynh wrote:
> > +
> > + ts_vdd_supply: ts-vdd-supply {
> > + compatible = "regulator-fixed";
> > + regulator-name = "ts_vdd_supply";
> > + gpio = < 3 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > + ts_vddio_supply: ts-vddio-supply {
> > + compatible = "regulator-fixed";
> > + regulator-name = "ts_vddio_supply";
> > + gpio = < 2 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
>
> I suppose you don't know the voltages for these?
>
Nope, no schematics to verify.
Re: [PATCH 04/12] arm64: dts: qcom: sm6115-pro1x: Add Caps Lock LED
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The Pro1X has a caps lock LED on the keyboard.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> index d91d31646b29..60c046fe8e52 100644
> --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> @@ -8,6 +8,7 @@
> #include "sm6115.dtsi"
> #include "pm6125.dtsi"
> #include
> +#include
>
> / {
> model = "F(x)tec Pro1X (QX1050)";
> @@ -63,6 +64,16 @@ key-volume-up {
> };
> };
>
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + capslock-led {
> + color = ;
> + function = LED_FUNCTION_CAPSLOCK;
> + gpios = < 1 GPIO_ACTIVE_HIGH>;
You may want to take a look at msm8998-fxtec-pro1.dts which has a
bit more properties describing it
Konrad
Re: [PATCH 03/12] arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The Fxtec Pro1X touchscreen uses Goodix GT9286 chip.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 49
> +
> 1 file changed, 49 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> index 43b4bee72dd8..d91d31646b29 100644
> --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> @@ -62,6 +62,20 @@ key-volume-up {
> wakeup-source;
> };
> };
> +
> + ts_vdd_supply: ts-vdd-supply {
> + compatible = "regulator-fixed";
> + regulator-name = "ts_vdd_supply";
> + gpio = < 3 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + ts_vddio_supply: ts-vddio-supply {
> + compatible = "regulator-fixed";
> + regulator-name = "ts_vddio_supply";
> + gpio = < 2 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
I suppose you don't know the voltages for these?
> };
>
> {
> @@ -86,6 +100,27 @@ pca9534: gpio@21 {
> };
> };
>
> + {
> + status = "okay";
> + /* Clock frequency was not specified downstream, let's park it to 100
> KHz */
> + clock-frequency = <10>;
> +
> + touchscreen@14 {
> + compatible = "goodix,gt9286";
> + reg = <0x14>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_int_n>, <_rst_n>;
reverse order, shift these down below supplies
> +
> + interrupt-parent = <>;
> + interrupts = <80 IRQ_TYPE_LEVEL_LOW>;
interrupts-extended
Konrad
Re: [PATCH 02/12] arm64: dts: qcom: sm6115-pro1x: Add PCA9534 IO Expander
On 22.07.2024 9:10 AM, Dang Huynh wrote: > F(x)tec Pro1X comes with PCA9534 IO Expander, it is used for enabling > touch screen VDD/VDDIO and keyboard's caps lock LED. > > Signed-off-by: Dang Huynh > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 01/12] arm64: dts: qcom: sm6115-pro1x: Add Hall Switch and Camera Button
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The Pro1X has a flip keyboard and a single-state camera button.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 33
> +++--
> 1 file changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> index 4a30024aa48f..5b7dd54be6b6 100644
> --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> @@ -34,9 +34,24 @@ framebuffer0: framebuffer@5c00 {
>
> gpio-keys {
> compatible = "gpio-keys";
> -
> - pinctrl-0 = <_up_n>;
> pinctrl-names = "default";
> + pinctrl-0 = <_sensor_n>, <_camera_n>, <_up_n>;
Please don't reorder these
looks good otherwise
Konrad
Re: [PATCH 00/15] Implement MODVERSIONS for Rust
On 7/15/24 22:39, Sami Tolvanen wrote:
> On Wed, Jul 10, 2024 at 7:30 AM Petr Pavlu wrote:
>> On 6/17/24 19:58, Sami Tolvanen wrote:
>>> The first 12 patches of this series add a small tool for computing
>>> symbol versions from DWARF, called gendwarfksyms. When passed a list
>>> of exported symbols, the tool generates an expanded type string
>>> for each symbol, and computes symbol CRCs similarly to genksyms.
>>> gendwarfksyms is written in C and uses libdw to process DWARF, mainly
>>> because of the existing support for C host tools that use elfutils
>>> (e.g., objtool).
>>
>> In addition to calculating CRCs of exported symbols, genksyms has other
>> features which I think are important.
>>
>> Firstly, the genksyms tool has a human-readable storage format for input
>> data used in the calculation of symbol CRCs. Setting the make variable
>> KBUILD_SYMTYPES enables dumping this data and storing it in *.symtypes
>> files.
>>
>> When a developer later modifies the kernel and wants to check if some
>> symbols have changed, they can take these files and feed them as
>> *.symref back to genksyms. This allows the tool to provide an actual
>> reason why some symbols have changed, instead of just printing that
>> their CRCs are different.
>>
>> Is there any plan to add the same functionality to gendwarfksyms, or do
>> you envison that people will use libabigail, Symbol-Type Graph, or
>> another tool for making this type of comparison?
>
> gendwarfksyms also uses human-readable input for the CRC calculations,
> and it prints out the input strings with the --debug option. I plan to
> hook this up to KBUILD_SYMTYPES in v2. It should be convenient enough
> to simply compare the pretty-printed output with diff, so I'm not sure
> if a built-in comparison option is needed. Any other DWARF analysis
> tool can be used to spot the differences too, as you mentioned.
>From my perspective, I'm okay if gendwarfksyms doesn't provide
functionality to compare a new object file with its reference symtypes
file.
As mentioned, genksyms has this functionality but I actually think the
way it works is not ideal. Its design is to operate on one compilation
unit at the time. This has the advantage that a comparison of each file
is performed in parallel during the build, simply because of the make
job system. On the other hand, it has two problems.
The first one is that genksyms doesn't provide a comparison of the
kernel as a whole. This means that the tool gives rather scattered and
duplicated output about changed structs in the build log. Ideally, one
would like to see a single compact report about what changed at the end
of the build.
The second problem is the handling of symtypes files. This data is large
and if one wants to store them in a Git repository together with the
kernel source, it is advisable to first compress/consolidate it in some
way. This is trivial because these files typically contain many
duplicates. However, the issue is that to feed the data back to
genksyms, they need to be unpacked during each build which can take some
time.
I think a better approach is to have a tool that can be given
a consolidated symtypes file as one input and can compare it with all
new symtypes files produced during a kernel build. An example of a tool
that takes this approach is the kabi Python script in UEK [1].
A few months ago, I also started working on a tool inspired by this
script. The goal is to have similar functionality but hopefully with
a much faster implementation. Hence, this tool is written in a compiled
language (Rust at the moment) and should also become multi-threaded. I'm
hoping to find some time to make progress on it and make the code
public. It could later be added to the upstream kernel to replace the
comparison functionality implemented by genksyms, if there is interest.
So as mentioned, I'm fine if gendwarfksyms doesn't have this
functionality. However, for distributions that rely on the symtypes
format, I'd be interested in having gendwarfksyms output its dump data
in this format as well.
For example, instead of producing:
gendwarfksyms: process_exported_symbols: _some_mangled_func_name (@ XYZ)
subprogram(
[formal parameters...]
)
-> structure_type core::result::Result<(), core::fmt::Error> {
[a description of the structure...]
};
.. the output could be something like this:
S#'core::result::Result<(), core::fmt::Error>' structure_type
core::result::Result<(), core::fmt::Error> { [a description of the
structure...] }
_some_mangled_func_name subprogram _some_mangled_func_name ( [formal
parameters...] ) -> S#'core::result::Result<(), core::fmt::Error>'
>> Secondly, when distributions want to maintain stable kABI, they need to
>> be able to deal with patch backports that add new members to structures.
>> One common approach is to have placeholders in important structures
>> which can be later replaced by the new members as needed. __GENKSYMS__
>> ifdefs are then used at the C source level to
Re: [PATCH 00/17] mm: introduce numa_memblks
On Fri, Jul 19, 2024 at 02:33:47PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:29 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Hi,
> >
> > Following the discussion about handling of CXL fixed memory windows on
> > arm64 [1] I decided to bite the bullet and move numa_memblks from x86 to
> > the generic code so they will be available on arm64/riscv and maybe on
> > loongarch sometime later.
> >
> > While it could be possible to use memblock to describe CXL memory windows,
> > it currently lacks notion of unpopulated memory ranges and numa_memblks
> > does implement this.
> >
> > Another reason to make numa_memblks generic is that both arch_numa (arm64
> > and riscv) and loongarch use trimmed copy of x86 code although there is no
> > fundamental reason why the same code cannot be used on all these platforms.
> > Having numa_memblks in mm/ will make it's interaction with ACPI and FDT
> > more consistent and I believe will reduce maintenance burden.
> >
> > And with generic numa_memblks it is (almost) straightforward to enable NUMA
> > emulation on arm64 and riscv.
> >
> > The first 5 commits in this series are cleanups that are not strictly
> > related to numa_memblks.
> >
> > Commits 6-11 slightly reorder code in x86 to allow extracting numa_memblks
> > and NUMA emulation to the generic code.
> >
> > Commits 12-14 actually move the code from arch/x86/ to mm/ and commit 15
> > does some aftermath cleanups.
> >
> > Commit 16 switches arch_numa to numa_memblks.
> >
> > Commit 17 enables usage of phys_to_target_node() and
> > memory_add_physaddr_to_nid() with numa_memblks.
>
> Hi Mike,
>
> I've lightly tested with emulated CXL + Generic Ports and Generic
> Initiators as well as more normal cpus and memory via qemu on arm64 and it's
> looking good.
>
> From my earlier series, patch 4 is probably still needed to avoid
> presenting nodes with nothing in them at boot (but not if we hotplug
> memory then remove it again in which case they disappear)
> https://lore.kernel.org/all/20240529171236.32002-5-jonathan.came...@huawei.com/
> However that was broken/inconsistent before your rework so I can send that
> patch separately.
I'd appreciate it :)
> Thanks for getting this sorted! I should get time to do more extensive
> testing and review in next week or so.
Thanks, you may want to wait for v2, I'm planning to send it this week.
> Jonathan
>
> >
> > [1]
> > https://lore.kernel.org/all/20240529171236.32002-1-jonathan.came...@huawei.com/
> >
> > Mike Rapoport (Microsoft) (17):
> > mm: move kernel/numa.c to mm/
> > MIPS: sgi-ip27: make NODE_DATA() the same as on all other
> > architectures
> > MIPS: loongson64: rename __node_data to node_data
> > arch, mm: move definition of node_data to generic code
> > arch, mm: pull out allocation of NODE_DATA to generic code
> > x86/numa: simplify numa_distance allocation
> > x86/numa: move FAKE_NODE_* defines to numa_emu
> > x86/numa_emu: simplify allocation of phys_dist
> > x86/numa_emu: split __apicid_to_node update to a helper function
> > x86/numa_emu: use a helper function to get MAX_DMA32_PFN
> > x86/numa: numa_{add,remove}_cpu: make cpu parameter unsigned
> > mm: introduce numa_memblks
> > mm: move numa_distance and related code from x86 to numa_memblks
> > mm: introduce numa_emulation
> > mm: make numa_memblks more self-contained
> > arch_numa: switch over to numa_memblks
> > mm: make range-to-target_node lookup facility a part of numa_memblks
> >
> > arch/arm64/include/asm/Kbuild | 1 +
> > arch/arm64/include/asm/mmzone.h | 13 -
> > arch/arm64/include/asm/topology.h | 1 +
> > arch/loongarch/include/asm/Kbuild | 1 +
> > arch/loongarch/include/asm/mmzone.h | 16 -
> > arch/loongarch/include/asm/topology.h | 1 +
> > arch/loongarch/kernel/numa.c | 21 -
> > arch/mips/include/asm/mach-ip27/mmzone.h | 1 -
> > .../mips/include/asm/mach-loongson64/mmzone.h | 4 -
> > arch/mips/loongson64/numa.c | 20 +-
> > arch/mips/sgi-ip27/ip27-memory.c | 2 +-
> > arch/powerpc/include/asm/mmzone.h | 6 -
> > arch/powerpc/mm/numa.c| 26 +-
> > arch/riscv/include/asm/Kbuild | 1 +
> > arch/riscv/include/asm/mmzone.h | 13 -
> > arch/riscv/include/asm/topology.h | 4 +
> > arch/s390/include/asm/Kbuild | 1 +
> > arch/s390/include/asm/mmzone.h| 17 -
> > arch/s390/kernel/numa.c | 3 -
> > arch/sh/include/asm/mmzone.h | 3 -
> > arch/sh/mm/init.c | 7 +-
> > arch/sh/mm/numa.c | 3 -
> > arch/sparc/include/asm/mmzone.h | 4 -
> > arch/sparc/mm/init_64.c | 11 +-
> > arch/x86/Kconfig
Re: [PATCH 15/17] mm: make numa_memblks more self-contained
On Fri, Jul 19, 2024 at 07:07:12PM +0100, Jonathan Cameron wrote: > On Tue, 16 Jul 2024 14:13:44 +0300 > Mike Rapoport wrote: > > > From: "Mike Rapoport (Microsoft)" > > > > Introduce numa_memblks_init() and move some code around to avoid several > > global variables in numa_memblks. > > Hi Mike, > > Adding the effectively always on memblock_force_top_down > deserves a comment on why. I assume because you are going to do > something with it later? > > There also seems to be more going on in here such as the change to > get_pfn_range_for_nid() Perhaps break this up so each > change can have an explanation. I'll split this into several commits. -- Sincerely yours, Mike.
Re: [PATCH 12/17] mm: introduce numa_memblks
On Fri, Jul 19, 2024 at 07:16:47PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:41 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move code dealing with numa_memblks from arch/x86 to mm/ and add Kconfig
> > options to let x86 select it in its Kconfig.
> >
> > This code will be later reused by arch_numa.
> >
> > No functional changes.
> >
> > Signed-off-by: Mike Rapoport (Microsoft)
> Hi Mike,
>
> My only real concern in here is there are a few places where
> the lifted code makes changes to memblocks that are x86 only today.
> I need to do some more digging to work out if those are safe
> in all cases.
>
> Jonathan
>
>
>
> > +/**
> > + * numa_cleanup_meminfo - Cleanup a numa_meminfo
> > + * @mi: numa_meminfo to clean up
> > + *
> > + * Sanitize @mi by merging and removing unnecessary memblks. Also check
> > for
> > + * conflicts and clear unused memblks.
> > + *
> > + * RETURNS:
> > + * 0 on success, -errno on failure.
> > + */
> > +int __init numa_cleanup_meminfo(struct numa_meminfo *mi)
> > +{
> > + const u64 low = 0;
>
> Given always zero, why not just use that value inline?
Actually it seems to me that it should be memblock_start_of_DRAM().
The blocks outside system memory are moved to numa_reserved_meminfo, so
AFAIU on arm64/riscv such blocks can be below the RAM.
> > + const u64 high = PFN_PHYS(max_pfn);
> > + int i, j, k;
> > +
> > + /* first, trim all entries */
> > + for (i = 0; i < mi->nr_blks; i++) {
> > + struct numa_memblk *bi = >blk[i];
> > +
> > + /* move / save reserved memory ranges */
> > + if (!memblock_overlaps_region(,
> > + bi->start, bi->end - bi->start)) {
> > + numa_move_tail_memblk(_reserved_meminfo, i--, mi);
> > + continue;
> > + }
> > +
> > + /* make sure all non-reserved blocks are inside the limits */
> > + bi->start = max(bi->start, low);
> > +
> > + /* preserve info for non-RAM areas above 'max_pfn': */
> > + if (bi->end > high) {
> > + numa_add_memblk_to(bi->nid, high, bi->end,
> > + _reserved_meminfo);
> > + bi->end = high;
> > + }
> > +
> > + /* and there's no empty block */
> > + if (bi->start >= bi->end)
> > + numa_remove_memblk_from(i--, mi);
> > + }
> > +
> > + /* merge neighboring / overlapping entries */
> > + for (i = 0; i < mi->nr_blks; i++) {
> > + struct numa_memblk *bi = >blk[i];
> > +
> > + for (j = i + 1; j < mi->nr_blks; j++) {
> > + struct numa_memblk *bj = >blk[j];
> > + u64 start, end;
> > +
> > + /*
> > +* See whether there are overlapping blocks. Whine
> > +* about but allow overlaps of the same nid. They
> > +* will be merged below.
> > +*/
> > + if (bi->end > bj->start && bi->start < bj->end) {
> > + if (bi->nid != bj->nid) {
> > + pr_err("node %d [mem %#010Lx-%#010Lx]
> > overlaps with node %d [mem %#010Lx-%#010Lx]\n",
> > + bi->nid, bi->start, bi->end - 1,
> > + bj->nid, bj->start, bj->end - 1);
> > + return -EINVAL;
> > + }
> > + pr_warn("Warning: node %d [mem %#010Lx-%#010Lx]
> > overlaps with itself [mem %#010Lx-%#010Lx]\n",
> > + bi->nid, bi->start, bi->end - 1,
> > + bj->start, bj->end - 1);
> > + }
> > +
> > + /*
> > +* Join together blocks on the same node, holes
> > +* between which don't overlap with memory on other
> > +* nodes.
> > +*/
> > + if (bi->nid != bj->nid)
> > + continue;
> > + start = min(bi->start, bj->start);
> > + end = max(bi->end, bj->end);
> > + for (k = 0; k < mi->nr_blks; k++) {
> > + struct numa_memblk *bk = >blk[k];
> > +
> > + if (bi->nid == bk->nid)
> > + continue;
> > + if (start < bk->end && end > bk->start)
> > + break;
> > + }
> > + if (k < mi->nr_blks)
> > + continue;
> > + pr_info("NUMA: Node %d [mem %#010Lx-%#010Lx] + [mem
> > %#010Lx-%#010Lx] -> [mem %#010Lx-%#010Lx]\n",
> > + bi->nid, bi->start, bi->end - 1, bj->start,
> > +
Re: [PATH v4 2/3] vdpa_sim_net: Add the support of set mac address
On Mon, Jul 22, 2024 at 3:57 PM Cindy Lu wrote:
>
> On Mon, 22 Jul 2024 at 15:48, Jason Wang wrote:
> >
> > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa_sim_net, the driver will write the MAC address
> > > to the config space, and other devices can implement
> > > their own functions to support this.
> > >
> > > Signed-off-by: Cindy Lu
> > > ---
> > > drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 22 +-
> > > 1 file changed, 21 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > > b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > > index cfe962911804..936e33e5021a 100644
> > > --- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > > @@ -414,6 +414,25 @@ static void vdpasim_net_get_config(struct vdpasim
> > > *vdpasim, void *config)
> > > net_config->status = cpu_to_vdpasim16(vdpasim,
> > > VIRTIO_NET_S_LINK_UP);
> > > }
> > >
> > > +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
> > > + struct vdpa_device *dev,
> > > + const struct vdpa_dev_set_config *config)
> > > +{
> > > + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> > > + struct virtio_net_config *vio_config = vdpasim->config;
> > > +
> > > + mutex_lock(>mutex);
> > > +
> > > + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > + memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
> > > + mutex_unlock(>mutex);
> > > + return 0;
> > > + }
> > > +
> > > + mutex_unlock(>mutex);
> >
> > Do we need to protect:
> >
> > case VIRTIO_NET_CTRL_MAC_ADDR_SET:
> > read = vringh_iov_pull_iotlb(>vring, >in_iov,
> > vio_config->mac, ETH_ALEN);
> > if (read == ETH_ALEN)
> > status = VIRTIO_NET_OK;
> > break;
> >
> > As both are modifying vio_config?
> >
> > Thanks
> >
> i have added a lock for this; CVQ also needs to take this lock to
> change the MAC address.I thinks maybe this can protect?
Right, I miss that it is done in the vdpasim_net_work().
> Do you mean I need to compare the mac address from the vdpa_tool and
> mac address in vio_config?
> this vdpa tool should not be used after the guest load, if this is
> different this is also acceptable
> thanks
The patch looks good then.
Acked-by: Jason Wang
Thanks
> Cindy
>
> > > + return -EINVAL;
> > > +}
> > > +
> > > static void vdpasim_net_setup_config(struct vdpasim *vdpasim,
> > > const struct vdpa_dev_set_config
> > > *config)
> > > {
> > > @@ -510,7 +529,8 @@ static void vdpasim_net_dev_del(struct vdpa_mgmt_dev
> > > *mdev,
> > >
> > > static const struct vdpa_mgmtdev_ops vdpasim_net_mgmtdev_ops = {
> > > .dev_add = vdpasim_net_dev_add,
> > > - .dev_del = vdpasim_net_dev_del
> > > + .dev_del = vdpasim_net_dev_del,
> > > + .dev_set_attr = vdpasim_net_set_attr
> > > };
> > >
> > > static struct virtio_device_id id_table[] = {
> > > --
> > > 2.45.0
> > >
> >
>
Re: [PATH v4 2/3] vdpa_sim_net: Add the support of set mac address
On Mon, 22 Jul 2024 at 15:48, Jason Wang wrote:
>
> On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa_sim_net, the driver will write the MAC address
> > to the config space, and other devices can implement
> > their own functions to support this.
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 22 +-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > index cfe962911804..936e33e5021a 100644
> > --- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > @@ -414,6 +414,25 @@ static void vdpasim_net_get_config(struct vdpasim
> > *vdpasim, void *config)
> > net_config->status = cpu_to_vdpasim16(vdpasim,
> > VIRTIO_NET_S_LINK_UP);
> > }
> >
> > +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
> > + struct vdpa_device *dev,
> > + const struct vdpa_dev_set_config *config)
> > +{
> > + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> > + struct virtio_net_config *vio_config = vdpasim->config;
> > +
> > + mutex_lock(>mutex);
> > +
> > + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > + memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
> > + mutex_unlock(>mutex);
> > + return 0;
> > + }
> > +
> > + mutex_unlock(>mutex);
>
> Do we need to protect:
>
> case VIRTIO_NET_CTRL_MAC_ADDR_SET:
> read = vringh_iov_pull_iotlb(>vring, >in_iov,
> vio_config->mac, ETH_ALEN);
> if (read == ETH_ALEN)
> status = VIRTIO_NET_OK;
> break;
>
> As both are modifying vio_config?
>
> Thanks
>
i have added a lock for this; CVQ also needs to take this lock to
change the MAC address.I thinks maybe this can protect?
Do you mean I need to compare the mac address from the vdpa_tool and
mac address in vio_config?
this vdpa tool should not be used after the guest load, if this is
different this is also acceptable
thanks
Cindy
> > + return -EINVAL;
> > +}
> > +
> > static void vdpasim_net_setup_config(struct vdpasim *vdpasim,
> > const struct vdpa_dev_set_config
> > *config)
> > {
> > @@ -510,7 +529,8 @@ static void vdpasim_net_dev_del(struct vdpa_mgmt_dev
> > *mdev,
> >
> > static const struct vdpa_mgmtdev_ops vdpasim_net_mgmtdev_ops = {
> > .dev_add = vdpasim_net_dev_add,
> > - .dev_del = vdpasim_net_dev_del
> > + .dev_del = vdpasim_net_dev_del,
> > + .dev_set_attr = vdpasim_net_set_attr
> > };
> >
> > static struct virtio_device_id id_table[] = {
> > --
> > 2.45.0
> >
>
Re: [PATCH 06/17] x86/numa: simplify numa_distance allocation
On Fri, Jul 19, 2024 at 05:28:49PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:35 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Allocation of numa_distance uses memblock_phys_alloc_range() to limit
> > allocation to be below the last mapped page.
> >
> > But NUMA initializaition runs after the direct map is populated and
>
> initialization (one too many 'i's)
Thanks.
> > there is also code in setup_arch() that adjusts memblock limit to
> > reflect how much memory is already mapped in the direct map.
> >
> > Simplify the allocation of numa_distance and use plain memblock_alloc().
> > This makes the code clearer and ensures that when numa_distance is not
> > allocated it is always NULL.
> Doesn't this break the comment in numa_set_distance() kernel-doc?
> "
> * If such table cannot be allocated, a warning is printed and further
> * calls are ignored until the distance table is reset with
> * numa_reset_distance().
> "
>
> Superficially that looks to be to avoid repeatedly hitting the
> singleton bit at the top of numa_set_distance() as SRAT or similar
> parsing occurs.
I believe it's there to avoid allocation of numa_distance in the middle of
distance parsing (SLIT or DT numa-distance-map).
If the allocation fails for the first element in the table, the
numa_distance and numa_distance_cnt remain zero and node_distance() falls
back to
return from == to ? LOCAL_DISTANCE : REMOTE_DISTANCE;
It's different from arch_numa that always tries to allocate MAX_NUMNODES *
MAX_NUMNODES for numa_distance and treats the allocation failure as a
failure to initialize NUMA.
I like the general approach x86 uses more, i.e. in case distance parsing
fails in some way NUMA is still initialized with probably suboptimal
distances between nodes.
I'm going to restore that "singleton" behavior for now and will look into
making this all less cumbersome later.
> > Signed-off-by: Mike Rapoport (Microsoft)
> > ---
> > arch/x86/mm/numa.c | 12 +++-
> > 1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > index 5e1dde26674b..ab2d4ecef786 100644
> > --- a/arch/x86/mm/numa.c
> > +++ b/arch/x86/mm/numa.c
> > @@ -319,8 +319,7 @@ void __init numa_reset_distance(void)
> > {
> > size_t size = numa_distance_cnt * numa_distance_cnt *
> > sizeof(numa_distance[0]);
> >
> > - /* numa_distance could be 1LU marking allocation failure, test cnt */
> > - if (numa_distance_cnt)
> > + if (numa_distance)
> > memblock_free(numa_distance, size);
> > numa_distance_cnt = 0;
> > numa_distance = NULL; /* enable table creation */
> > @@ -331,7 +330,6 @@ static int __init numa_alloc_distance(void)
> > nodemask_t nodes_parsed;
> > size_t size;
> > int i, j, cnt = 0;
> > - u64 phys;
> >
> > /* size the new table and allocate it */
> > nodes_parsed = numa_nodes_parsed;
> > @@ -342,16 +340,12 @@ static int __init numa_alloc_distance(void)
> > cnt++;
> > size = cnt * cnt * sizeof(numa_distance[0]);
> >
> > - phys = memblock_phys_alloc_range(size, PAGE_SIZE, 0,
> > -PFN_PHYS(max_pfn_mapped));
> > - if (!phys) {
> > + numa_distance = memblock_alloc(size, PAGE_SIZE);
> > + if (!numa_distance) {
> > pr_warn("Warning: can't allocate distance table!\n");
> > - /* don't retry until explicitly reset */
> > - numa_distance = (void *)1LU;
> > return -ENOMEM;
> > }
> >
> > - numa_distance = __va(phys);
> > numa_distance_cnt = cnt;
> >
> > /* fill with the default distances */
>
>
--
Sincerely yours,
Mike.
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index ecfc16151d61..415b527a9c72 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
> *v_mdev, struct vdpa_device *
> destroy_workqueue(wq);
> mgtdev->ndev = NULL;
> }
> +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *add_config)
> +{
> + struct mlx5_vdpa_dev *mvdev;
> + struct mlx5_vdpa_net *ndev;
> + struct mlx5_core_dev *mdev;
> + struct virtio_net_config *config;
> + struct mlx5_core_dev *pfmdev;
> + int err = -EOPNOTSUPP;
> +
> + mvdev = to_mvdev(dev);
> + ndev = to_mlx5_vdpa_ndev(mvdev);
> + mdev = mvdev->mdev;
> + config = >config;
> +
> + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> + if (!err)
> + memcpy(config->mac, add_config->net.mac, ETH_ALEN);
> + }
> + return err;
Similar to net simulator, how could be serialize the modification to
mac address:
1) from vdpa tool
2) via control virtqueue
Thanks
> +}
>
> static const struct vdpa_mgmtdev_ops mdev_ops = {
> .dev_add = mlx5_vdpa_dev_add,
> .dev_del = mlx5_vdpa_dev_del,
> + .dev_set_attr = mlx5_vdpa_set_attr,
> };
>
> static struct virtio_device_id id_table[] = {
> --
> 2.45.0
>
Re: [PATH v4 2/3] vdpa_sim_net: Add the support of set mac address
On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa_sim_net, the driver will write the MAC address
> to the config space, and other devices can implement
> their own functions to support this.
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> index cfe962911804..936e33e5021a 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> @@ -414,6 +414,25 @@ static void vdpasim_net_get_config(struct vdpasim
> *vdpasim, void *config)
> net_config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
> }
>
> +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *config)
> +{
> + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> + struct virtio_net_config *vio_config = vdpasim->config;
> +
> + mutex_lock(>mutex);
> +
> + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
> + mutex_unlock(>mutex);
> + return 0;
> + }
> +
> + mutex_unlock(>mutex);
Do we need to protect:
case VIRTIO_NET_CTRL_MAC_ADDR_SET:
read = vringh_iov_pull_iotlb(>vring, >in_iov,
vio_config->mac, ETH_ALEN);
if (read == ETH_ALEN)
status = VIRTIO_NET_OK;
break;
As both are modifying vio_config?
Thanks
> + return -EINVAL;
> +}
> +
> static void vdpasim_net_setup_config(struct vdpasim *vdpasim,
> const struct vdpa_dev_set_config *config)
> {
> @@ -510,7 +529,8 @@ static void vdpasim_net_dev_del(struct vdpa_mgmt_dev
> *mdev,
>
> static const struct vdpa_mgmtdev_ops vdpasim_net_mgmtdev_ops = {
> .dev_add = vdpasim_net_dev_add,
> - .dev_del = vdpasim_net_dev_del
> + .dev_del = vdpasim_net_dev_del,
> + .dev_set_attr = vdpasim_net_set_attr
> };
>
> static struct virtio_device_id id_table[] = {
> --
> 2.45.0
>
Re: [PATCH 02/17] MIPS: sgi-ip27: make NODE_DATA() the same as on all other architectures
On Fri, Jul 19, 2024 at 03:38:52PM +0100, Jonathan Cameron wrote:
> On Wed, 17 Jul 2024 16:32:59 +0200
> David Hildenbrand wrote:
>
> > On 16.07.24 13:13, Mike Rapoport wrote:
> > > From: "Mike Rapoport (Microsoft)"
> > >
> > > sgi-ip27 is the only system that defines NODE_DATA() differently than
> > > the rest of NUMA machines.
> > >
> > > Add node_data array of struct pglist pointers that will point to
> > > __node_data[node]->pglist and redefine NODE_DATA() to use node_data
> > > array.
> > >
> > > This will allow pulling declaration of node_data to the generic mm code
> > > in the next commit.
> > >
> > > Signed-off-by: Mike Rapoport (Microsoft)
> > > ---
> > > arch/mips/include/asm/mach-ip27/mmzone.h | 5 -
> > > arch/mips/sgi-ip27/ip27-memory.c | 5 -
> > > 2 files changed, 8 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/mips/include/asm/mach-ip27/mmzone.h
> > > b/arch/mips/include/asm/mach-ip27/mmzone.h
> > > index 08c36e50a860..629c3f290203 100644
> > > --- a/arch/mips/include/asm/mach-ip27/mmzone.h
> > > +++ b/arch/mips/include/asm/mach-ip27/mmzone.h
> > > @@ -22,7 +22,10 @@ struct node_data {
> > >
> > > extern struct node_data *__node_data[];
> > >
> > > -#define NODE_DATA(n) (&__node_data[(n)]->pglist)
> > > #define hub_data(n) (&__node_data[(n)]->hub)
> > >
> > > +extern struct pglist_data *node_data[];
> > > +
> > > +#define NODE_DATA(nid) (node_data[nid])
> > > +
> > > #endif /* _ASM_MACH_MMZONE_H */
> > > diff --git a/arch/mips/sgi-ip27/ip27-memory.c
> > > b/arch/mips/sgi-ip27/ip27-memory.c
> > > index b8ca94cfb4fe..c30ef6958b97 100644
> > > --- a/arch/mips/sgi-ip27/ip27-memory.c
> > > +++ b/arch/mips/sgi-ip27/ip27-memory.c
> > > @@ -34,8 +34,10 @@
> > > #define SLOT_PFNSHIFT (SLOT_SHIFT - PAGE_SHIFT)
> > > #define PFN_NASIDSHFT (NASID_SHFT - PAGE_SHIFT)
> > >
> > > -struct node_data *__node_data[MAX_NUMNODES];
> > > +struct pglist_data *node_data[MAX_NUMNODES];
> > > +EXPORT_SYMBOL(node_data);
> > >
> > > +struct node_data *__node_data[MAX_NUMNODES];
> > > EXPORT_SYMBOL(__node_data);
> > >
> > > static u64 gen_region_mask(void)
> > > @@ -361,6 +363,7 @@ static void __init node_mem_init(nasid_t node)
> > >*/
> > > __node_data[node] = __va(slot_freepfn << PAGE_SHIFT);
> > > memset(__node_data[node], 0, PAGE_SIZE);
> > > + node_data[node] = &__node_data[node]->pglist;
> > >
> > > NODE_DATA(node)->node_start_pfn = start_pfn;
> > > NODE_DATA(node)->node_spanned_pages = end_pfn - start_pfn;
> >
> > I was assuming we could get rid of __node_data->pglist.
> >
> > But now I am confused where that is actually set.
>
> It looks nasty...
Nasty indeed :)
> Cast in arch_refresh_nodedata() takes incoming pg_data_t * and casts it
> to the local version of struct node_data * which I think is this one
>
> struct node_data {
> struct pglist_data pglist; (which is pg_data_t pglist)
> struct hub_data hub;
> };
>
> https://elixir.bootlin.com/linux/v6.10/source/arch/mips/sgi-ip27/ip27-memory.c#L432
>
> Now that pg_data_t is allocated by
> arch_alloc_nodedata() which might be fine (though types could be handled in a
> more
> readable fashion via some container_of() magic.
> https://elixir.bootlin.com/linux/v6.10/source/arch/mips/sgi-ip27/ip27-memory.c#L427
>
> However that call is:
> pg_data_t * __init arch_alloc_nodedata(int nid)
> {
> return memblock_alloc(sizeof(pg_data_t), SMP_CACHE_BYTES);
> }
>
> So doesn't seem to allocate enough space to me as should be sizeof(struct
> node_data)
Well, it's there to silence a compiler error (commit f8f9f21c7848 ("MIPS:
Fix build error for loongson64 and sgi-ip27")), but this is not a proper
fix :(
Luckily nothing calls cpumask_of_node() for offline nodes...
> Worth cleaning up whilst here? Proper handling of types would definitely
> help.
Worth cleanup indeed, but I'd rather drop arch_alloc_nodedata() on MIPS
altogether.
> Jonathan
--
Sincerely yours,
Mike.
Re: [PATCH 08/12] arm64: dts: qcom: sm6115-pro1x: Update copyright year
On 22/07/2024 09:10, Dang Huynh wrote: > It's 2024, let's update the copyright year. > > Signed-off-by: Dang Huynh > --- > arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts > b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts > index a32fc27bc783..6e9e4d9f8250 100644 > --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts > +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > /* > - * Copyright (c) 2023, Dang Huynh > + * Copyright (c) 2023 - 2024, Dang Huynh Please squash it. I don't think copyright update has a merit on its own. Best regards, Krzysztof
Re: [PATCH V2 3/7] vhost-vdpa: VHOST_NEW_OWNER
On Thu, Jul 18, 2024 at 2:28 AM Steven Sistare
wrote:
>
> On 7/16/2024 1:16 AM, Jason Wang wrote:
> > On Mon, Jul 15, 2024 at 10:27 PM Steven Sistare
> > wrote:
> >>
> >> On 7/14/2024 10:26 PM, Jason Wang wrote:
> >>> On Fri, Jul 12, 2024 at 9:19 PM Steve Sistare
> >>> wrote:
>
> Add an ioctl to transfer file descriptor ownership and pinned memory
> accounting from one process to another.
>
> This is more efficient than VHOST_RESET_OWNER followed by
> VHOST_SET_OWNER,
> as that would unpin all physical pages, requiring them to be repinned in
> the new process. That would cost multiple seconds for large memories,
> and
> be incurred during a virtual machine's pause time during live update.
>
> Signed-off-by: Steve Sistare
> ---
> drivers/vhost/vdpa.c | 41 ++
> drivers/vhost/vhost.c | 15 ++
> drivers/vhost/vhost.h | 1 +
> include/uapi/linux/vhost.h | 10 ++
> 4 files changed, 67 insertions(+)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index b49e5831b3f0..5cf55ca4ec02 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -632,6 +632,44 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v)
> return ret;
> }
>
> +static long vhost_vdpa_new_owner(struct vhost_vdpa *v)
> +{
> + int r;
> + struct vhost_dev *vdev = >vdev;
> + struct mm_struct *mm_old = vdev->mm;
> + struct mm_struct *mm_new = current->mm;
> + long pinned_vm = v->pinned_vm;
> + unsigned long lock_limit = PFN_DOWN(rlimit(RLIMIT_MEMLOCK));
> +
> + if (!mm_old)
> + return -EINVAL;
> + mmgrab(mm_old);
> +
> + if (!v->vdpa->use_va &&
> + pinned_vm + atomic64_read(_new->pinned_vm) > lock_limit) {
> + r = -ENOMEM;
> + goto out;
> + }
> >>>
> >>> So this seems to allow an arbitrary process to execute this. Seems to be
> >>> unsafe.
> >>>
> >>> I wonder if we need to add some checks here, maybe PID or other stuff
> >>> to only allow the owner process to do this.
> >>
> >> The original owner must send the file descriptor to the new owner.
> >
> > This seems not to be in the steps you put in the cover letter.
>
> It's there:
>"The vdpa device descriptor, fd, remains open across the exec."
>
> But, I can say more about how fd visibility constitutes permission to changer
> owner in this commit message.
Yes, that would be great.
>
> >> That constitutes permission to take ownership.
> >
> > This seems like a relaxed version of the reset_owner:
> >
> > Currently, reset_owner have the following check:
>
> Not relaxed, just different. A process cannot do anything with fd if it
> is not the owner, *except* for becoming the new owner. Holding the fd is
> like holding a key.
I meant it kind of "defeats" the effort of VHOST_NET_RESET_OWNER ...
Thanks
>
> - Steve
>
> > /* Caller should have device mutex */
> > long vhost_dev_check_owner(struct vhost_dev *dev)
> > {
> > /* Are you the owner? If not, I don't think you mean to do that */
> > return dev->mm == current->mm ? 0 : -EPERM;
> > }
> > EXPORT_SYMBOL_GPL(vhost_dev_check_owner);
> >
> > It means even if the fd is passed to some other process, the reset
> > owner won't work there.
> >
> > Thanks
> >
> >>
> + r = vhost_vdpa_bind_mm(v, mm_new);
> + if (r)
> + goto out;
> +
> + r = vhost_dev_new_owner(vdev);
> + if (r) {
> + vhost_vdpa_bind_mm(v, mm_old);
> + goto out;
> + }
> +
> + if (!v->vdpa->use_va) {
> + atomic64_sub(pinned_vm, _old->pinned_vm);
> + atomic64_add(pinned_vm, _new->pinned_vm);
> + }
> +
> +out:
> + mmdrop(mm_old);
> + return r;
> +}
> +
> static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int
> cmd,
> void __user *argp)
> {
> @@ -876,6 +914,9 @@ static long vhost_vdpa_unlocked_ioctl(struct file
> *filep,
> case VHOST_VDPA_RESUME:
> r = vhost_vdpa_resume(v);
> break;
> + case VHOST_NEW_OWNER:
> + r = vhost_vdpa_new_owner(v);
> + break;
> default:
> r = vhost_dev_ioctl(>vdev, cmd, argp);
> if (r == -ENOIOCTLCMD)
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index b60955682474..ab40ae50552f 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -963,6 +963,21 @@ long
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Fri, Jul 19, 2024 at 9:19 AM Michael S. Tsirkin wrote: > > On Fri, Jul 19, 2024 at 09:02:29AM +0800, Jason Wang wrote: > > On Wed, Jul 17, 2024 at 2:53 PM Jason Wang wrote: > > > > > > On Wed, Jul 17, 2024 at 2:00 PM Michael S. Tsirkin > > > wrote: > > > > > > > > On Wed, Jul 17, 2024 at 09:19:02AM +0800, Jason Wang wrote: > > > > > On Wed, Jul 10, 2024 at 11:03 AM Jason Wang > > > > > wrote: > > > > > > > > > > > > On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote: > > > > > > > > This patch synchronize operstate with admin state per RFC2863. > > > > > > > > > > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > > > synchronize with the config change work. This allows propagate > > > > > > > > status > > > > > > > > correctly to stacked devices like: > > > > > > > > > > > > > > > > ip link add link enp0s3 macvlan0 type macvlan > > > > > > > > ip link set link enp0s3 down > > > > > > > > ip link show > > > > > > > > > > > > > > > > Before this patch: > > > > > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast > > > > > > > > state DOWN mode DEFAULT group default qlen 1000 > > > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > > > .. > > > > > > > > 5: macvlan0@enp0s3: > > > > > > > > mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen > > > > > > > > 1000 > > > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > > > > > > > After this patch: > > > > > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast > > > > > > > > state DOWN mode DEFAULT group default qlen 1000 > > > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > > > ... > > > > > > > > 5: macvlan0@enp0s3: > > > > > > > > mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group > > > > > > > > default qlen 1000 > > > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > > > > > I think that the commit log is confusing. It seems to say that > > > > > > > the issue fixed is synchronizing state with hardware > > > > > > > config change. > > > > > > > But your example does not show any > > > > > > > hardware change. Isn't this example really just > > > > > > > a side effect of setting carrier off on close? > > > > > > > > > > > > The main goal for this patch is to make virtio-net follow RFC2863. > > > > > > The > > > > > > main thing that is missed is to synchronize the operstate with admin > > > > > > state, if we do this, we get several good results, one of the > > > > > > obvious > > > > > > one is to allow virtio-net to propagate status to the upper layer, > > > > > > for > > > > > > example if the admin state of the lower virtio-net is down it should > > > > > > be propagated to the macvlan on top, so I give the example of using > > > > > > a > > > > > > stacked device. I'm not we had others but the commit log is probably > > > > > > too small to say all of it. > > > > > > > > > > Michael, any more comments on this? > > > > > > > > > > Thans > > > > > > > > > > > > Still don't get it, sorry. > > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > > > synchronize with the config change work. > > > > What does this sentence mean? What is not synchronized with config > > > > change that needs to be? > > > > > > I meant, > > > > > > 1) maclvan depends on the linkwatch to transfer operstate from the > > > lower device to itself. > > > 2) ndo_open()/close() will not trigger the linkwatch so we need to do > > > it by ourselves in virtio-net to make sure macvlan get the correct > > > opersate > > > 3) consider config change work can change the state so ndo_close() > > > needs to synchronize with it > > > > > > Thanks > > > > Michael, are you fine with the above or I miss something there? > > > > Thanks > > > I don't understand 3. config change can always trigger. > what I do not like is all these reads from config space > that now trigger on open/close. previously we did > read > - on probe > - after probe, if config changed > > > and that made sense. Ok, not sure I get you all but I will post a new version to see. Thanks > > -- > MST >
Re: [PATCH] tracing: Fix overflow in get_free_elt()
On Wed, 2024-07-10 at 17:19 +0800, Tze-nan Wu wrote:
> "tracing_map->next_elt" in get_free_elt() is at risk of overflowing.
>
> Once it overflows, new elements can still be inserted into the
> tracing_map
> even though the maximum number of elements (`max_elts`) has been
> reached.
> Continuing to insert elements after the overflow could result in the
> tracing_map containing "tracing_map->max_size" elements, leaving no
> empty
> entries.
> If any attempt is made to insert an element into a full tracing_map
> using
> `__tracing_map_insert()`, it will cause an infinite loop with
> preemption
> disabled, leading to a CPU hang problem.
>
> Fix this by preventing any further increments to "tracing_map-
> >next_elt"
> once it reaches "tracing_map->max_elt".
>
> Co-developed-by: Cheng-Jui Wang
> Signed-off-by: Cheng-Jui Wang
> Signed-off-by: Tze-nan Wu
> ---
> kernel/trace/tracing_map.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Just a gentle ping. Any comments on this patch will be appreciated.
Actually we have encountered this issue internally after enabling the
throttle_rss_stat feature in Perfetto for an extended duration, during
which the rss_stat tracepoint was invoked over 2^32 times.
Then the CPU could hang in function "__tracing_map_insert()" after the
tracing_map left no empty entry.
throttle_rss_stat is literally:
1. $echo "rss_stat_throttled unsigned int mm_id unsigned int curr int
member long size" >> /sys/kernel/tracing/synthetic_events
2. $echo
'hist:keys=mm_id,member:bucket=size/0x8:onchange($bucket).rss_stat_
throttled(mm_id,curr,member,size)' >
/sys/kernel/tracing/events/kmem/rss_stat/trigger
> diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c
> index a4dcf0f24352..3a56e7c8aa4f 100644
> --- a/kernel/trace/tracing_map.c
> +++ b/kernel/trace/tracing_map.c
> @@ -454,7 +454,7 @@ static struct tracing_map_elt
> *get_free_elt(struct tracing_map *map)
> struct tracing_map_elt *elt = NULL;
> int idx;
>
> - idx = atomic_inc_return(>next_elt);
> + idx = atomic_fetch_add_unless(>next_elt, 1, map-
> >max_elts);
> if (idx < map->max_elts) {
> elt = *(TRACING_MAP_ELT(map->elts, idx));
> if (map->ops && map->ops->elt_init)
> @@ -699,7 +699,7 @@ void tracing_map_clear(struct tracing_map *map)
> {
> unsigned int i;
>
> - atomic_set(>next_elt, -1);
> + atomic_set(>next_elt, 0);
> atomic64_set(>hits, 0);
> atomic64_set(>drops, 0);
>
> @@ -783,7 +783,7 @@ struct tracing_map *tracing_map_create(unsigned
> int map_bits,
>
> map->map_bits = map_bits;
> map->max_elts = (1 << map_bits);
> - atomic_set(>next_elt, -1);
> + atomic_set(>next_elt, 0);
>
> map->map_size = (1 << (map_bits + 1));
> map->ops = ops;
Re: [PATCH 2/6] kallsyms: Emit symbol at the holes in the text
On 2024/7/20 22:14, Masahiro Yamada wrote:
On Thu, Jul 18, 2024 at 12:45 PM Zheng Yejian wrote:
On 2024/7/16 16:33, Masahiro Yamada wrote:
On Thu, Jun 13, 2024 at 10:36 PM Zheng Yejian wrote:
When a weak type function is overridden, its symbol will be removed
from the symbol table, but its code will not be removed. Besides,
due to lacking of size for kallsyms, kernel compute function size by
substracting its symbol address from its next symbol address (see
kallsyms_lookup_size_offset()). These will cause that size of some
function is computed to be larger than it actually is, just because
symbol of its following weak function is removed.
This issue also causes multiple __fentry__ locations to be counted in
the some function scope, and eventually causes ftrace_location() to find
wrong __fentry__ location. It was reported in
Link:
https://lore.kernel.org/all/20240607115211.734845-1-zhengyeji...@huawei.com/
Peter suggested to change scipts/kallsyms.c to emit readily
identifiable symbol names for all the weak junk, eg:
__weak_junk_N
The name of this kind symbol needs some discussion, but it's temporarily
called "__hole_symbol_X" in this patch:
1. Pass size info to scripts/kallsyms (see mksysmap());
2. Traverse sorted function symbols, if one function address plus its
size less than next function address, it means there's a hole, then
emit a symbol "__hole_symbol_X" there which type is 't'.
After this patch, the effect is as follows:
$ cat /proc/kallsyms | grep -A 3 do_one_initcall
810021e0 T do_one_initcall
8100245e t __hole_symbol_X
810024a0 t __pfx_rootfs_init_fs_context
Suggested-by: Peter Zijlstra
Signed-off-by: Zheng Yejian
With my quick test, "t__hole_symbol_X" was encoded
into the following 10-byte stream.
.byte 0x09, 0x94, 0xbf, 0x18, 0xf3, 0x3d, 0xce, 0xd1, 0xd1, 0x58
Now "t__hole_symbol_X" is the most common symbol name.
However, 10 byte is consumed for every instance of
"t__hole_symbol_X".
This is much less efficient thanI had expected,
although I did not analyze the logic of this inefficiency.
Hi, Masahiro!
In my local test, "t__hole_symbol_X" was finally encoded
into just one byte. See "kallsyms_token_table" in the .tmp_vmlinux.kallsyms2.S:
kallsyms_token_table:
[...]
.asciz "t__hole_symbol_X"
.asciz "hole_symbol_X"
.asciz "e_symbol_X"
.asciz "X"
.asciz "XXX"
.asciz "e_symbol_"
.asciz "ymbol_"
.asciz "ymb"
.asciz "hol"
.asciz "ol_"
.asciz "pfx"
.asciz "pf"
.asciz "e_s"
.asciz "ym"
.asciz "t__"
.asciz "_s"
.asciz "ol"
.asciz "__"
.asciz "XX"
But it would still takes up several tokens due to substrings of
"t__hole_symbol_X" would also become the most common ones.
After this patch, the number of "t__hole_symbol_X" will be ~30% of the
total.
---
scripts/kallsyms.c | 101 +++-
scripts/link-vmlinux.sh | 4 +-
scripts/mksysmap| 2 +-
3 files changed, 102 insertions(+), 5 deletions(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 6559a9802f6e..5c4cde864a04 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -35,6 +35,7 @@
struct sym_entry {
struct sym_entry *next;
unsigned long long addr;
+ unsigned long long size;
unsigned int len;
unsigned int seq;
unsigned int start_pos;
@@ -74,6 +75,7 @@ static int token_profit[0x1];
static unsigned char best_table[256][2];
static unsigned char best_table_len[256];
+static const char hole_symbol[] = "__hole_symbol_X";
static void usage(void)
{
@@ -130,8 +132,16 @@ static struct sym_entry *read_symbol(FILE *in, char **buf,
size_t *buf_len)
size_t len;
ssize_t readlen;
struct sym_entry *sym;
+ unsigned long long size = 0;
errno = 0;
+ /*
+* Example of expected symbol format:
+* 1. symbol with size info:
+*8170 01d7 T __startup_64
+* 2. symbol without size info:
+*02a0 A text_size
+*/
readlen = getline(buf, buf_len, in);
if (readlen < 0) {
if (errno) {
@@ -145,9 +155,24 @@ static struct sym_entry *read_symbol(FILE *in, char **buf,
size_t *buf_len)
(*buf)[readlen - 1] = 0;
addr = strtoull(*buf, , 16);
+ if (*buf == p || *p++ != ' ') {
+ fprintf(stderr, "line format error: unable to parse address\n");
+ exit(EXIT_FAILURE);
+ }
+
+ if (*p == '0') {
+ char *str = p;
- if (*buf == p || *p++ != ' ' || !isascii((type = *p++)) || *p++ != ' ')
{
-
Re: [RFC v11 05/14] mm: page_frag: avoid caller accessing 'page_frag_cache' directly
On Fri, 2024-07-19 at 17:33 +0800, Yunsheng Lin wrote: > Use appropriate frag_page API instead of caller accessing > 'page_frag_cache' directly. > > CC: Alexander Duyck > Signed-off-by: Yunsheng Lin > --- > drivers/vhost/net.c | 2 +- > include/linux/page_frag_cache.h | 10 ++ > mm/page_frag_test.c | 2 +- > net/core/skbuff.c | 6 +++--- > net/rxrpc/conn_object.c | 4 +--- > net/rxrpc/local_object.c| 4 +--- > net/sunrpc/svcsock.c| 6 ++ > 7 files changed, 19 insertions(+), 15 deletions(-) > Looks fine to me. Reviewed-by: Alexander Duyck
Re: [RFC v11 04/14] mm: page_frag: add '_va' suffix to page_frag API
On Fri, Jul 19, 2024 at 2:37 AM Yunsheng Lin wrote: > > Currently the page_frag API is returning 'virtual address' > or 'va' when allocing and expecting 'virtual address' or > 'va' as input when freeing. > > As we are about to support new use cases that the caller > need to deal with 'struct page' or need to deal with both > 'va' and 'struct page'. In order to differentiate the API > handling between 'va' and 'struct page', add '_va' suffix > to the corresponding API mirroring the page_pool_alloc_va() > API of the page_pool. So that callers expecting to deal with > va, page or both va and page may call page_frag_alloc_va*, > page_frag_alloc_pg*, or page_frag_alloc* API accordingly. > > CC: Alexander Duyck > Signed-off-by: Yunsheng Lin > Reviewed-by: Subbaraya Sundeep Rather than renaming the existing API I would rather see this follow the same approach as we use with the other memory subsystem functions. A specific example being that with free_page it is essentially passed a virtual address, while the double underscore version is passed a page. I would be more okay with us renaming the double underscore version of any functions we might have to address that rather than renaming all the functions with "va". In general I would say this patch is adding no value as what it is doing is essentially pushing the primary users of this API to change to support use cases that won't impact most of them. It is just creating a ton of noise in terms of changes with no added value so we can reuse the function names.
Re: [PATCH v1 1/1] Input: gpio-keys - expose wakeup keys in sysfs
Hi, On Tue, May 14, 2024 at 06:05:20PM +0200, Guido Günther wrote: > Hi, > On Mon, May 13, 2024 at 03:13:53PM -0700, Dmitry Torokhov wrote: > > Hi Guido, > > > > On Thu, May 09, 2024 at 02:00:28PM +0200, Guido Günther wrote: > > > This helps user space to figure out which keys should be used to unidle a > > > device. E.g on phones the volume rocker should usually not unblank the > > > screen. > > > > How exactly this is supposed to be used? We have "disabled" keys and > > switches attribute because this function can be controlled at runtime > > from userspace while wakeup control is a static device setting. > > Current Linux userspace usually unblanks/unidles a device on every > keypress. That is usually not the expected result on phones where often > only the power button and e.g. some home buttons should do this. > > These keys usually match the keys that are used as wakeup sources to > bring a device out of suspend. So if we export the wakeup keys to > userspace we can pick some sensible defaults (overridable via hwdb¹). > > > Kernel also does not really know if the screen should be unblanked or > > not, if a button or switch is configured for wake up the kernel will go > > through wakeup process all the same and then userspace can decide if it > > should stay woken up or not. > > Yes, we merely want that as a hint to figure out sensible defaults in > userspace (which might be a subset of the wakeup keys). Is there anything I can do to get this applied (currently we play catchup per device when the wakup keys change) ? Cheers, -- Guido > > Cherrs, > -- Guido > > ¹) See > https://gitlab.gnome.org/World/Phosh/gmobile/-/blob/main/data/61-gmobile-wakeup.hwdb?ref_type=heads#L57-L59 > > > > > Thanks. > > > > -- > > Dmitry > >
Re: [PATCH V2 0/7] vdpa live update
On 7/17/2024 8:33 PM, Jason Wang wrote:
On Thu, Jul 18, 2024 at 2:29 AM Steven Sistare
wrote:
On 7/16/2024 1:30 AM, Jason Wang wrote:
On Mon, Jul 15, 2024 at 10:29 PM Steven Sistare
wrote:
On 7/14/2024 10:14 PM, Jason Wang wrote:
On Fri, Jul 12, 2024 at 9:19 PM Steve Sistare wrote:
Live update is a technique wherein an application saves its state, exec's
to an updated version of itself, and restores its state. Clients of the
application experience a brief suspension of service, on the order of
100's of milliseconds, but are otherwise unaffected.
Define and implement interfaces that allow vdpa devices to be preserved
across fork or exec, to support live update for applications such as QEMU.
The device must be suspended during the update, but its DMA mappings are
preserved, so the suspension is brief.
The VHOST_NEW_OWNER ioctl transfers device ownership and pinned memory
accounting from one process to another.
The VHOST_BACKEND_F_NEW_OWNER backend capability indicates that
VHOST_NEW_OWNER is supported.
The VHOST_IOTLB_REMAP message type updates a DMA mapping with its userland
address in the new process.
The VHOST_BACKEND_F_IOTLB_REMAP backend capability indicates that
VHOST_IOTLB_REMAP is supported and required. Some devices do not
require it, because the userland address of each DMA mapping is discarded
after being translated to a physical address.
Here is a pseudo-code sequence for performing live update, based on
suspend + reset because resume is not yet widely available. The vdpa device
descriptor, fd, remains open across the exec.
ioctl(fd, VHOST_VDPA_SUSPEND)
ioctl(fd, VHOST_VDPA_SET_STATUS, 0)
I don't understand why we need a reset after suspend, it looks to me
the previous suspend became meaningless.
The suspend guarantees completion of in-progress DMA. At least, that is
my interpretation of why that is done for live migration in QEMU, which
also does suspend + reset + re-create. I am following the live migration
model.
Yes, but any reason we need a reset after the suspension?
Probably not. I found it cleanest to call reset and let new qemu configure the
device as it always does during startup, rather than altering those code paths
to skip the kernel calls.
If we care about the downtime, I think avoiding a reset should be faster.
Agreed. I want to try it some time, but I think what I have now using reset is
decent enough for version 1.
- Steve
So, consider this to be just one of several possible
userland algorithms.
- Steve
Thanks
exec
ioctl(fd, VHOST_NEW_OWNER)
issue ioctls to re-create vrings
if VHOST_BACKEND_F_IOTLB_REMAP
So the idea is for a device that is using a virtual address, it
doesn't need VHOST_BACKEND_F_IOTLB_REMAP at all?
Actually the reverse: if the device translates virtual to physical when
the mappings are created, and discards the virtual, then VHOST_IOTLB_REMAP
is not needed.
Ok.
foreach dma mapping
write(fd, {VHOST_IOTLB_REMAP, new_addr})
ioctl(fd, VHOST_VDPA_SET_STATUS,
ACKNOWLEDGE | DRIVER | FEATURES_OK | DRIVER_OK)
From API level, this seems to be asymmetric as we have suspending but
not resuming?
Again, I am just following the path taken by live migration.
I will be happy to use resume when the devices and QEMU support it.
The decision to use reset vs resume should not affect the definition
and use of VHOST_NEW_OWNER and VHOST_IOTLB_REMAP.
- Steve
Thanks
Re: [GIT PULL] NVDIMM and DAX for 6.11
The pull request you sent on Fri, 19 Jul 2024 11:19:47 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git > tags/libnvdimm-for-6.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/13a7871541b7f5fa6d81e76f160644d1e118b6b0 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [bug report] tracing/kprobes: Add symbol counting check when module loads
On Thu, 18 Jul 2024 13:30:57 -0500
Dan Carpenter wrote:
> Hello Masami Hiramatsu (Google),
>
> Commit 9d8616034f16 ("tracing/kprobes: Add symbol counting check when
> module loads") from Jul 5, 2024 (linux-next), leads to the following
> Smatch static checker warning:
>
> kernel/trace/trace_kprobe.c:828 validate_probe_symbol()
> warn: missing error code here? 'try_module_get_by_name()' failed. 'ret'
> = '0'
>
> kernel/trace/trace_kprobe.c
> 815 static int validate_probe_symbol(char *symbol)
> 816 {
> 817 struct module *mod = NULL;
> 818 char *modname = NULL, *p;
> 819 int ret = 0;
> 820
> 821 p = strchr(symbol, ':');
> 822 if (p) {
> 823 modname = symbol;
> 824 symbol = p + 1;
> 825 *p = '\0';
> 826 mod = try_module_get_by_name(modname);
> 827 if (!mod)
> --> 828 goto out;
>
> Is it intentional that "ret = 0;" here?
Yes, hm, I dropped an important message here. If you see the commit
9d8616034f16, you can see there was;
/* Return 0 (defer) if the module does not exist yet. */
So it is intentional.
But thanks for reporting. It should be cleaned up.
Thank you,
>
> 829 }
> 830
> 831 ret = validate_module_probe_symbol(modname, symbol);
> 832 out:
> 833 if (p)
> 834 *p = ':';
> 835 if (mod)
> 836 module_put(mod);
> 837 return ret;
> 838 }
>
> regards,
> dan carpenter
--
Masami Hiramatsu (Google)
Re: [PATCH 2/6] kallsyms: Emit symbol at the holes in the text
On Thu, Jul 18, 2024 at 12:45 PM Zheng Yejian wrote:
>
> On 2024/7/16 16:33, Masahiro Yamada wrote:
> > On Thu, Jun 13, 2024 at 10:36 PM Zheng Yejian
> > wrote:
> >>
> >> When a weak type function is overridden, its symbol will be removed
> >> from the symbol table, but its code will not be removed. Besides,
> >> due to lacking of size for kallsyms, kernel compute function size by
> >> substracting its symbol address from its next symbol address (see
> >> kallsyms_lookup_size_offset()). These will cause that size of some
> >> function is computed to be larger than it actually is, just because
> >> symbol of its following weak function is removed.
> >>
> >> This issue also causes multiple __fentry__ locations to be counted in
> >> the some function scope, and eventually causes ftrace_location() to find
> >> wrong __fentry__ location. It was reported in
> >> Link:
> >> https://lore.kernel.org/all/20240607115211.734845-1-zhengyeji...@huawei.com/
> >>
> >> Peter suggested to change scipts/kallsyms.c to emit readily
> >> identifiable symbol names for all the weak junk, eg:
> >>
> >>__weak_junk_N
> >>
> >> The name of this kind symbol needs some discussion, but it's temporarily
> >> called "__hole_symbol_X" in this patch:
> >> 1. Pass size info to scripts/kallsyms (see mksysmap());
> >> 2. Traverse sorted function symbols, if one function address plus its
> >> size less than next function address, it means there's a hole, then
> >> emit a symbol "__hole_symbol_X" there which type is 't'.
> >>
> >> After this patch, the effect is as follows:
> >>
> >>$ cat /proc/kallsyms | grep -A 3 do_one_initcall
> >>810021e0 T do_one_initcall
> >>8100245e t __hole_symbol_X
> >>810024a0 t __pfx_rootfs_init_fs_context
> >>
> >> Suggested-by: Peter Zijlstra
> >> Signed-off-by: Zheng Yejian
> >
> >
> >
> > With my quick test, "t__hole_symbol_X" was encoded
> > into the following 10-byte stream.
> >
> > .byte 0x09, 0x94, 0xbf, 0x18, 0xf3, 0x3d, 0xce, 0xd1, 0xd1, 0x58
> >
> >
> >
> > Now "t__hole_symbol_X" is the most common symbol name.
> > However, 10 byte is consumed for every instance of
> > "t__hole_symbol_X".
> >
> > This is much less efficient thanI had expected,
> > although I did not analyze the logic of this inefficiency.
> >
> Hi, Masahiro!
>
> In my local test, "t__hole_symbol_X" was finally encoded
> into just one byte. See "kallsyms_token_table" in the
> .tmp_vmlinux.kallsyms2.S:
>
>kallsyms_token_table:
> [...]
> .asciz "t__hole_symbol_X"
> .asciz "hole_symbol_X"
> .asciz "e_symbol_X"
> .asciz "X"
> .asciz "XXX"
> .asciz "e_symbol_"
> .asciz "ymbol_"
> .asciz "ymb"
> .asciz "hol"
> .asciz "ol_"
> .asciz "pfx"
> .asciz "pf"
> .asciz "e_s"
> .asciz "ym"
> .asciz "t__"
> .asciz "_s"
> .asciz "ol"
> .asciz "__"
> .asciz "XX"
>
> But it would still takes up several tokens due to substrings of
> "t__hole_symbol_X" would also become the most common ones.
> After this patch, the number of "t__hole_symbol_X" will be ~30% of the
> total.
>
> >
> >
> >
> >
> >
> >
> >> ---
> >> scripts/kallsyms.c | 101 +++-
> >> scripts/link-vmlinux.sh | 4 +-
> >> scripts/mksysmap| 2 +-
> >> 3 files changed, 102 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> >> index 6559a9802f6e..5c4cde864a04 100644
> >> --- a/scripts/kallsyms.c
> >> +++ b/scripts/kallsyms.c
> >> @@ -35,6 +35,7 @@
> >> struct sym_entry {
> >> struct sym_entry *next;
> >> unsigned long long addr;
> >> + unsigned long long size;
> >> unsigned int len;
> >> unsigned int seq;
> >> unsigned int start_pos;
> >> @@ -74,6 +75,7 @@ static int token_profit[0x1];
> >> static unsigned char best_table[256][2];
> >> static unsigned char best_table_len[256];
> >>
> >> +static const char hole_symbol[] = "__hole_symbol_X";
> >>
> >> static void usage(void)
> >> {
> >> @@ -130,8 +132,16 @@ static struct sym_entry *read_symbol(FILE *in, char
> >> **buf, size_t *buf_len)
> >> size_t len;
> >> ssize_t readlen;
> >> struct sym_entry *sym;
> >> + unsigned long long size = 0;
> >>
> >> errno = 0;
> >> + /*
> >> +* Example of expected symbol format:
> >> +* 1. symbol with size info:
> >> +*8170 01d7 T __startup_64
> >> +* 2. symbol without size info:
> >> +*02a0 A text_size
> >> +*/
> >> readlen = getline(buf, buf_len, in);
> >> if (readlen < 0) {
> >> if (errno) {
> >> @@ -145,9 +155,24 @@ static struct sym_entry *read_symbol(FILE *in,
Re: [PATCH 15/17] mm: make numa_memblks more self-contained
On Fri, Jul 19, 2024 at 07:07:12PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:44 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Introduce numa_memblks_init() and move some code around to avoid several
> > global variables in numa_memblks.
>
> Hi Mike,
>
> Adding the effectively always on memblock_force_top_down
> deserves a comment on why. I assume because you are going to do
> something with it later?
Yes, arch_numa sets it to false. I'll add a note in the changelog.
> There also seems to be more going on in here such as the change to
> get_pfn_range_for_nid() Perhaps break this up so each
> change can have an explanation.
Ok.
> >
> > Signed-off-by: Mike Rapoport (Microsoft)
> > ---
> > arch/x86/mm/numa.c | 53 -
> > include/linux/numa_memblks.h | 9 +
> > mm/numa_memblks.c| 77 +++-
> > 3 files changed, 68 insertions(+), 71 deletions(-)
> >
> > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > index 3848e68d771a..16bc703c9272 100644
> > --- a/arch/x86/mm/numa.c
> > +++ b/arch/x86/mm/numa.c
> > @@ -115,30 +115,19 @@ void __init setup_node_to_cpumask_map(void)
> > pr_debug("Node to cpumask map for %u nodes\n", nr_node_ids);
> > }
> >
> > -static int __init numa_register_memblks(struct numa_meminfo *mi)
> > +static int __init numa_register_nodes(void)
> > {
> > - int i, nid, err;
> > -
> > - err = numa_register_meminfo(mi);
> > - if (err)
> > - return err;
> > + int nid;
> >
> > if (!memblock_validate_numa_coverage(SZ_1M))
> > return -EINVAL;
> >
> > /* Finally register nodes. */
> > for_each_node_mask(nid, node_possible_map) {
> > - u64 start = PFN_PHYS(max_pfn);
> > - u64 end = 0;
> > -
> > - for (i = 0; i < mi->nr_blks; i++) {
> > - if (nid != mi->blk[i].nid)
> > - continue;
> > - start = min(mi->blk[i].start, start);
> > - end = max(mi->blk[i].end, end);
> > - }
> > + unsigned long start_pfn, end_pfn;
> >
> > - if (start >= end)
> > + get_pfn_range_for_nid(nid, _pfn, _pfn);
>
> It's not immediately obvious to me that this code is equivalent so I'd
> prefer it in a separate patch with some description of why
> it is a valid change.
Will do.
> > + if (start_pfn >= end_pfn)
> > continue;
> >
> > alloc_node_data(nid);
> > @@ -178,39 +167,11 @@ static int __init numa_init(int (*init_func)(void))
> > for (i = 0; i < MAX_LOCAL_APIC; i++)
> > set_apicid_to_node(i, NUMA_NO_NODE);
> >
> > - nodes_clear(numa_nodes_parsed);
> > - nodes_clear(node_possible_map);
> > - nodes_clear(node_online_map);
> > - memset(_meminfo, 0, sizeof(numa_meminfo));
> > - WARN_ON(memblock_set_node(0, ULLONG_MAX, ,
> > - NUMA_NO_NODE));
> > - WARN_ON(memblock_set_node(0, ULLONG_MAX, ,
> > - NUMA_NO_NODE));
> > - /* In case that parsing SRAT failed. */
> > - WARN_ON(memblock_clear_hotplug(0, ULLONG_MAX));
> > - numa_reset_distance();
> > -
> > - ret = init_func();
> > - if (ret < 0)
> > - return ret;
> > -
> > - /*
> > -* We reset memblock back to the top-down direction
> > -* here because if we configured ACPI_NUMA, we have
> > -* parsed SRAT in init_func(). It is ok to have the
> > -* reset here even if we did't configure ACPI_NUMA
> > -* or acpi numa init fails and fallbacks to dummy
> > -* numa init.
> > -*/
> > - memblock_set_bottom_up(false);
> > -
> > - ret = numa_cleanup_meminfo(_meminfo);
> > + ret = numa_memblks_init(init_func, /* memblock_force_top_down */ true);
> The comment in parameter list seems unnecessary.
> Maybe add a comment above the call instead if need to call that out?
I'll drop it for now.
> > if (ret < 0)
> > return ret;
> >
> > - numa_emulation(_meminfo, numa_distance_cnt);
> > -
> > - ret = numa_register_memblks(_meminfo);
> > + ret = numa_register_nodes();
> > if (ret < 0)
> > return ret;
> >
>
> > diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> > index e0039549aaac..640f3a3ce0ee 100644
> > --- a/mm/numa_memblks.c
> > +++ b/mm/numa_memblks.c
> > @@ -7,13 +7,27 @@
> > #include
> > #include
> >
>
> > +/*
> > + * Set nodes, which have memory in @mi, in *@nodemask.
> > + */
> > +static void __init numa_nodemask_from_meminfo(nodemask_t *nodemask,
> > + const struct numa_meminfo *mi)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(mi->blk); i++)
> > + if (mi->blk[i].start != mi->blk[i].end &&
> > + mi->blk[i].nid != NUMA_NO_NODE)
> > + node_set(mi->blk[i].nid, *nodemask);
> > +}
>
> The code move doesn't have an obvious
Re: [PATCH 13/17] mm: move numa_distance and related code from x86 to numa_memblks
On Fri, Jul 19, 2024 at 06:48:42PM +0100, Jonathan Cameron wrote: > On Tue, 16 Jul 2024 14:13:42 +0300 > Mike Rapoport wrote: > > > From: "Mike Rapoport (Microsoft)" > > > > Move code dealing with numa_distance array from arch/x86 to > > mm/numa_memblks.c > > It's not really numa memblock related. Is this the best place > to put it? There is a dependency of numa_alloc_distance() on numa_nodemask_from_meminfo() that relies on numa_memblk but I agree that they are not really related. However, I'd prefer to keep this code in mm/numa_memblks.c because node_distance() definitions and related code are different between architecures and having this code outside numa_memblks in e.g mm/numa.c would be way more involved. > > This code will be later reused by arch_numa. > > > > No functional changes. > > > > Signed-off-by: Mike Rapoport (Microsoft) > -- Sincerely yours, Mike.
Re: [PATCH 14/17] mm: introduce numa_emulation
On Fri, Jul 19, 2024 at 12:03:11PM -0400, Zi Yan wrote: > On 16 Jul 2024, at 7:13, Mike Rapoport wrote: > > > From: "Mike Rapoport (Microsoft)" > > > > Move numa_emulation codfrom arch/x86 to mm/numa_emulation.c > > > > This code will be later reused by arch_numa. > > > > No functional changes. > > > > Signed-off-by: Mike Rapoport (Microsoft) > > --- > > arch/x86/Kconfig | 8 > > arch/x86/include/asm/numa.h | 12 > > arch/x86/mm/Makefile | 1 - > > arch/x86/mm/numa_internal.h | 11 --- > > include/linux/numa_memblks.h | 17 + > > mm/Kconfig | 8 > > mm/Makefile | 1 + > > mm/numa_emulation.c | 4 +--- > > 8 files changed, 27 insertions(+), 35 deletions(-) > > After this code move, the document of numa=fake= should be moved from > Documentation/arch/x86/x86_64/boot-options.rst to > Documentation/admin-guide/kernel-parameters.txt > too. I'll add this as a separate commit. > Something like: > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index bc55fb55cd26..ce3659289b5e 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -4158,6 +4158,18 @@ > Disable NUMA, Only set up a single NUMA node > spanning all memory. > > + numa=fake=[MG] > + If given as a memory unit, fills all system RAM with > nodes of > + size interleaved over physical nodes. > + > + numa=fake= > + If given as an integer, fills all system RAM with N > fake nodes > + interleaved over physical nodes. > + > + numa=fake=U > + If given as an integer followed by 'U', it will > divide each > + physical node into N emulated nodes. > + > numa_balancing= [KNL,ARM64,PPC,RISCV,S390,X86] Enable or disable > automatic > NUMA balancing. > Allowed values are enable and disable > diff --git a/Documentation/arch/x86/x86_64/boot-options.rst > b/Documentation/arch/x86/x86_64/boot-options.rst > index 137432d34109..98d4805f0823 100644 > --- a/Documentation/arch/x86/x86_64/boot-options.rst > +++ b/Documentation/arch/x86/x86_64/boot-options.rst > @@ -170,18 +170,6 @@ NUMA > Don't parse the HMAT table for NUMA setup, or soft-reserved memory > partitioning. > > - numa=fake=[MG] > -If given as a memory unit, fills all system RAM with nodes of > -size interleaved over physical nodes. > - > - numa=fake= > -If given as an integer, fills all system RAM with N fake nodes > -interleaved over physical nodes. > - > - numa=fake=U > -If given as an integer followed by 'U', it will divide each > -physical node into N emulated nodes. > - > ACPI > > > Best Regards, > Yan, Zi -- Sincerely yours, Mike.
Re: [PATCH 05/17] arch, mm: pull out allocation of NODE_DATA to generic code
On Wed, Jul 17, 2024 at 04:42:48PM +0200, David Hildenbrand wrote:
> On 16.07.24 13:13, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)"
> >
> > Architectures that support NUMA duplicate the code that allocates
> > NODE_DATA on the node-local memory with slight variations in reporting
> > of the addresses where the memory was allocated.
> >
> > Use x86 version as the basis for the generic alloc_node_data() function
> > and call this function in architecture specific numa initialization.
> >
> > Signed-off-by: Mike Rapoport (Microsoft)
> > ---
>
> [...]
>
> > diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
> > index 9208eaadf690..909f6cec3a26 100644
> > --- a/arch/mips/loongson64/numa.c
> > +++ b/arch/mips/loongson64/numa.c
> > @@ -81,12 +81,8 @@ static void __init init_topology_matrix(void)
> > static void __init node_mem_init(unsigned int node)
> > {
> > - struct pglist_data *nd;
> > unsigned long node_addrspace_offset;
> > unsigned long start_pfn, end_pfn;
> > - unsigned long nd_pa;
> > - int tnid;
> > - const size_t nd_size = roundup(sizeof(pg_data_t), SMP_CACHE_BYTES);
>
> One interesting change is that we now always round up to full pages on
> architectures where we previously rounded up to SMP_CACHE_BYTES.
I did some git archaeology and it seems that round up to full pages on x86
backdates to bootmem era when allocation granularity was PAGE_SIZE anyway.
I'm going to change that to SMP_CACHE_BYTES in v2.
> I assume we don't really expect a significant growth in memory consumption
> that we care about, especially because most systems with many nodes also
> have quite some memory around.
--
Sincerely yours,
Mike.
Re: [PATCH] livepatch: Add using attribute to klp_func for using func show
> is this always correct though? See the logic in klp_ftrace_handler(). If > there is a transition running, it is a little bit more complicated. > > Miroslav Hi! Miroslav. In reality, we often encounter such situation that serval patch in one system, some patch make changes to one same function A. This make us confused that we don't know which version of function A is now using. In my view, this "using" state show the function version that is now enabling. Even if there is a transition running, the end state of one task will finally use patchN's version. If we see the attribute "using" is 1, it mean that livepatch will use this function to work but seem to be not all task running this version because the "transition" flag of this patch is "1". We can be told from "transition" that if all threads have completed synchronization. So, the main function of this attribute is to enable user space find out which version of the patched function is running now (or will use after transition completed)in the system. Please see if I have explain my opinion clearly. Thanks! Wardenjohn.
Re: tracing: user events UAF crash report
On Fri, Jul 19, 2024 at 10:47:01PM +0200, Mathias Krause wrote: > Hi Steven, Ajay, > > [ @Cc list: I found out issues with tracefs have been reported / > attempted to get fixed in the past, so you may be interested. ] > > I noticed, the user events ftrace selftest is crashing every now and > then in our automated tests. Digging into, I found that the following > is triggering the issue very reliable: > > - in one shell, as root: > # while true; do ./kselftest/user_events/ftrace_test; done > > - in a second shell, again as root: > # cd /sys/kernel/tracing > # while true; do cat events/user_events/__test_event/format; done > 2>/dev/null > > Ignoring that the selftest fails for half of its tests -- which is a > regression and therefore yet another bug, I guess -- this triggers an > access fault (GFP/PF/NULL deref) after a few iterations, usually within > a minute, mostly mere seconds. With KASAN enabled it generates a splat > almost instantly, like following: > > [ 23.790955] > == > [ 23.791692] BUG: KASAN: slab-use-after-free in f_show+0x43b/0x470 > [ 23.792244] Read of size 8 at addr 888007076878 by task cat/755 > [ 23.792753] > [ 23.792947] CPU: 1 PID: 755 Comm: cat Tainted: G D N > 6.10.0-vanilla-dirty #30 > [ 23.793563] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 > [ 23.794280] Call Trace: > [ 23.794470] > [ 23.794642] dump_stack_lvl+0x66/0xa0 > [ 23.794909] print_report+0xd0/0x630 > [ 23.795180] ? f_show+0x43b/0x470 > [ 23.795415] ? __virt_addr_valid+0x208/0x3f0 > [ 23.795700] ? f_show+0x43b/0x470 > [ 23.795935] kasan_report+0xd8/0x110 > [ 23.796183] ? f_show+0x43b/0x470 > [ 23.796418] f_show+0x43b/0x470 > [ 23.796645] seq_read_iter+0x418/0x11e0 > [ 23.796907] ? __page_table_check_ptes_set+0x166/0x1a0 > [ 23.797280] seq_read+0x261/0x350 > [ 23.797537] ? lock_release+0x453/0x600 > [ 23.797819] ? __pfx_seq_read+0x10/0x10 > [ 23.798103] ? set_ptes.isra.0+0x11b/0x150 > [ 23.798402] vfs_read+0x171/0x9e0 > [ 23.798657] ? lock_acquire+0x408/0x4b0 > [ 23.798970] ? __pfx_vfs_read+0x10/0x10 > [ 23.799267] ? lock_release+0x453/0x600 > [ 23.799549] ? do_user_addr_fault+0x45b/0x8b0 > [ 23.799862] ? __pfx_lock_release+0x10/0x10 > [ 23.800162] ? __pfx___up_read+0x10/0x10 > [ 23.800448] ksys_read+0xdd/0x1a0 > [ 23.800704] ? __pfx_ksys_read+0x10/0x10 > [ 23.801007] ? do_user_addr_fault+0x465/0x8b0 > [ 23.801341] do_syscall_64+0x66/0x130 > [ 23.801615] entry_SYSCALL_64_after_hwframe+0x71/0x79 > [ 23.801959] RIP: 0033:0x7f1fdb9df40e > [ 23.802230] Code: c0 e9 b6 fe ff ff 50 48 8d 3d 2e 08 0b 00 e8 69 01 02 00 > 66 0f 1f 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d > 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28 > [ 23.803352] RSP: 002b:7fff86d62658 EFLAGS: 0246 ORIG_RAX: > > [ 23.803848] RAX: ffda RBX: 0002 RCX: > 7f1fdb9df40e > [ 23.804302] RDX: 0002 RSI: 7f1fdb8d3000 RDI: > 0003 > [ 23.804753] RBP: 7f1fdb8d3000 R08: 7f1fdb8d2010 R09: > > [ 23.805239] R10: fbc5 R11: 0246 R12: > > [ 23.805694] R13: 0003 R14: 0002 R15: > 0002 > [ 23.806153] > [ 23.806352] > [ 23.806518] Allocated by task 753: > [ 23.806781] kasan_save_stack+0x20/0x40 > [ 23.807094] kasan_save_track+0x14/0x30 > [ 23.807377] __kasan_kmalloc+0x8f/0xa0 > [ 23.807656] user_event_parse_cmd+0x590/0x25e0 > [ 23.807969] user_events_ioctl+0xa52/0x17f0 > [ 23.808267] __x64_sys_ioctl+0x133/0x190 > [ 23.808555] do_syscall_64+0x66/0x130 > [ 23.808830] entry_SYSCALL_64_after_hwframe+0x71/0x79 > [ 23.809208] > [ 23.809370] Freed by task 58: > [ 23.809609] kasan_save_stack+0x20/0x40 > [ 23.809890] kasan_save_track+0x14/0x30 > [ 23.810173] kasan_save_free_info+0x3b/0x60 > [ 23.810473] poison_slab_object+0x10a/0x170 > [ 23.810771] __kasan_slab_free+0x14/0x30 > [ 23.811090] kfree+0xe0/0x2f0 > [ 23.811338] destroy_user_event+0x305/0x450 > [ 23.811639] delayed_destroy_user_event+0x5c/0xe0 > [ 23.811965] process_one_work+0x81c/0x1970 > [ 23.812259] worker_thread+0x608/0x1160 > [ 23.812542] kthread+0x2be/0x3b0 > [ 23.812794] ret_from_fork+0x2c/0x70 > [ 23.813098] ret_from_fork_asm+0x1a/0x30 > [ 23.813387] > [ 23.813551] Last potentially related work creation: > [ 23.813885] kasan_save_stack+0x20/0x40 > [ 23.814168] __kasan_record_aux_stack+0x8e/0xa0 > [ 23.814489] insert_work+0x20/0x1b0 > [ 23.814756] __queue_work+0x67a/0xc60 > [ 23.815079] queue_work_on+0x63/0x90 > [ 23.815350] user_event_put+0x1f9/0x390 > [ 23.815631] user_events_ioctl+0x11ed/0x17f0 > [ 23.815935]
Re: [GIT PULL] virtio: features, fixes, cleanups
The pull request you sent on Wed, 17 Jul 2024 05:30:34 -0400: > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f4f92db4391285ef3a688cdad25d5c76db200a30 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v2 00/11] perf/uprobe: Optimize uprobes
On Mon, Jul 15, 2024 at 11:10 AM Andrii Nakryiko wrote: > > On Mon, Jul 15, 2024 at 10:10 AM Andrii Nakryiko > wrote: > > > > On Mon, Jul 15, 2024 at 7:45 AM Peter Zijlstra wrote: > > > > > > On Thu, Jul 11, 2024 at 09:57:44PM -0700, Andrii Nakryiko wrote: > > > > > > > But then I also ran it on Linux built from perf/uprobes branch (these > > > > patches), and after a few seconds I see that there is no more > > > > attachment/detachment happening. Eventually I got splats, which you > > > > can see in [1]. I used `sudo ./uprobe-stress -a10 -t5 -m5 -f3` command > > > > to run it inside my QEMU image. > > > > > > So them git voodoo incantations did work and I got it built. I'm running > > > that exact same line above (minus the sudo, because test box only has a > > > root account I think) on real hardware. > > > > > > I'm now ~100 periods in and wondering what 'eventually' means... > > > > So I was running in a qemu set up with 16 cores on top of bare metal's > > 80 core CPU (Intel(R) Xeon(R) Gold 6138 CPU @ 2.00GHz). I just tried > > it again, and I can reproduce it within first few periods: > > > > WORKING HARD!.. > > > > PERIOD #1 STATS: > > FUNC CALLS 919632 > > UPROBE HITS 706351 > > URETPROBE HITS 641679 > > ATTACHED LINKS 951 > > ATTACHED UPROBES 2421 > > ATTACHED URETPROBES2343 > > MMAP CALLS33533 > > FORKS CALLS 241 > > > > PERIOD #2 STATS: > > FUNC CALLS11444 > > UPROBE HITS 14320 > > URETPROBE HITS 9896 > > ATTACHED LINKS 26 > > ATTACHED UPROBES 75 > > ATTACHED URETPROBES 61 > > MMAP CALLS39093 > > FORKS CALLS 14 > > > > PERIOD #3 STATS: > > FUNC CALLS 230 > > UPROBE HITS 152 > > URETPROBE HITS 145 > > ATTACHED LINKS2 > > ATTACHED UPROBES 2 > > ATTACHED URETPROBES 2 > > MMAP CALLS39121 > > FORKS CALLS 0 > > > > PERIOD #4 STATS: > > FUNC CALLS0 > > UPROBE HITS 0 > > URETPROBE HITS0 > > ATTACHED LINKS0 > > ATTACHED UPROBES 0 > > ATTACHED URETPROBES 0 > > MMAP CALLS39010 > > FORKS CALLS 0 > > > > You can see in the second period all the numbers drop and by period #4 > > (which is about 20 seconds in) anything but mmap()ing stops. When I > > said "eventually" I meant about a minute tops, however long it takes > > to do soft lockup detection, 23 seconds this time. > > > > So it should be very fast. > > > > Note that I'm running with debug kernel configuration (see [0] for > > full kernel config), here are debug-related settings, in case that > > makes a difference: > > > > $ cat ~/linux-build/default/.config | rg -i debug | rg -v '^#' > > CONFIG_X86_DEBUGCTLMSR=y > > CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y > > CONFIG_BLK_DEBUG_FS=y > > CONFIG_PNP_DEBUG_MESSAGES=y > > CONFIG_AIC7XXX_DEBUG_MASK=0 > > CONFIG_AIC79XX_DEBUG_MASK=0 > > CONFIG_SCSI_MVSAS_DEBUG=y > > CONFIG_DM_DEBUG=y > > CONFIG_MLX4_DEBUG=y > > CONFIG_USB_SERIAL_DEBUG=m > > CONFIG_INFINIBAND_MTHCA_DEBUG=y > > CONFIG_INFINIBAND_IPOIB_DEBUG=y > > CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y > > CONFIG_CIFS_DEBUG=y > > CONFIG_DLM_DEBUG=y > > CONFIG_DEBUG_BUGVERBOSE=y > > CONFIG_DEBUG_KERNEL=y > > CONFIG_DEBUG_INFO=y > > CONFIG_DEBUG_INFO_DWARF4=y > > CONFIG_DEBUG_INFO_COMPRESSED_NONE=y > > CONFIG_DEBUG_INFO_BTF=y > > CONFIG_DEBUG_INFO_BTF_MODULES=y > > CONFIG_DEBUG_FS=y > > CONFIG_DEBUG_FS_ALLOW_ALL=y > > CONFIG_ARCH_HAS_DEBUG_WX=y > > CONFIG_HAVE_DEBUG_KMEMLEAK=y > > CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE=y > > CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y > > CONFIG_SCHED_DEBUG=y > > CONFIG_DEBUG_PREEMPT=y > > CONFIG_LOCK_DEBUGGING_SUPPORT=y > > CONFIG_DEBUG_RT_MUTEXES=y > > CONFIG_DEBUG_SPINLOCK=y > > CONFIG_DEBUG_MUTEXES=y > > CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y > > CONFIG_DEBUG_RWSEMS=y > > CONFIG_DEBUG_LOCK_ALLOC=y > > CONFIG_DEBUG_LOCKDEP=y > > CONFIG_DEBUG_ATOMIC_SLEEP=y > > CONFIG_DEBUG_IRQFLAGS=y > > CONFIG_X86_DEBUG_FPU=y > > CONFIG_FAULT_INJECTION_DEBUG_FS=y > > > > [0] https://gist.github.com/anakryiko/97a023a95b30fb0fe607ff743433e64b > > > > > > > > Also, this is a 2 socket, 10 core per socket, 2 threads per core > > > ivybridge thing, are those parameters sufficient? > > > > Should be, I guess? It might be VM vs bare metal differences, though. > > I'll try to run this on bare metal with more production-like kernel > > configuration to see if I can still trigger this. Will let you know > > the results when I get them. > > Ok, so I ran it on bare metal host with production config. I didn't > really bother to specify parameters (so just one thread for > everything, the default): > > # ./uprobe-stress > WORKING HARD!.. > > PERIOD #1 STATS: > FUNC CALLS 2959843 > UPROBE HITS 1001312 >
Re: [PATCH 17/17] mm: make range-to-target_node lookup facility a part of numa_memblks
On Tue, 16 Jul 2024 14:13:46 +0300 Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > The x86 implementation of range-to-target_node lookup (i.e. > phys_to_target_node() and memory_add_physaddr_to_nid()) relies on > numa_memblks. > > Since numa_memblks are now part of the generic code, move these > functions from x86 to mm/numa_memblks.c and select > CONFIG_NUMA_KEEP_MEMINFO when CONFIG_NUMA_MEMBLKS=y for dax and cxl. > > Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Jonathan Cameron Thanks. I'll poke around more next week. Have a good weekend. Jonathan
