- Linux-kselftest-mirror - lists.linaro.org

[PATCH bpf-next v2 0/3] Add FOU support for externally controlled ipip devices

by Christian Ehrig

This patch set adds support for using FOU or GUE encapsulation with an ipip device operating in collect-metadata mode and a set of kfuncs for controlling encap parameters exposed to a BPF tc-hook. BPF tc-hooks allow us to read tunnel metadata (like remote IP addresses) in the ingress path of an externally controlled tunnel interface via the bpf_skb_get_tunnel_{key,opt} bpf-helpers. Packets can then be redirected to the same or a different externally controlled tunnel interface by overwriting metadata via the bpf_skb_set_tunnel_{key,opt} helpers and a call to bpf_redirect. This enables us to redirect packets between tunnel interfaces - and potentially change the encapsulation type - using only a single BPF program. Today this approach works fine for a couple of tunnel combinations. For example: redirecting packets between Geneve and GRE interfaces or GRE and plain ipip interfaces. However, redirecting using FOU or GUE is not supported today. The ip_tunnel module does not allow us to egress packets using additional UDP encapsulation from an ipip device in collect-metadata mode. Patch 1 lifts this restriction by adding a struct ip_tunnel_encap to the tunnel metadata. It can be filled by a new BPF kfunc introduced in Patch 2 and evaluated by the ip_tunnel egress path. This will allow us to use FOU and GUE encap with externally controlled ipip devices. Patch 2 introduces two new BPF kfuncs: bpf_skb_{set,get}_fou_encap. These helpers can be used to set and get UDP encap parameters from the BPF tc-hook doing the packet redirect. Patch 3 adds BPF tunnel selftests using the two kfuncs. --- v2: - Fixes for checkpatch.pl - Fixes for kernel test robot Christian Ehrig (3): ipip,ip_tunnel,sit: Add FOU support for externally controlled ipip devices bpf,fou: Add bpf_skb_{set,get}_fou_encap kfuncs selftests/bpf: Test FOU kfuncs for externally controlled ipip devices include/net/fou.h | 2 + include/net/ip_tunnels.h | 28 +++-- net/ipv4/Makefile | 2 +- net/ipv4/fou_bpf.c | 119 ++++++++++++++++++ net/ipv4/fou_core.c | 5 + net/ipv4/ip_tunnel.c | 22 +++- net/ipv4/ipip.c | 1 + net/ipv6/sit.c | 2 +- .../selftests/bpf/progs/test_tunnel_kern.c | 117 +++++++++++++++++ tools/testing/selftests/bpf/test_tunnel.sh | 81 ++++++++++++ 10 files changed, 362 insertions(+), 17 deletions(-) create mode 100644 net/ipv4/fou_bpf.c -- 2.39.2

2 years, 5 months

2
2
0 0

[gpio kself-test & bisect] gpio-mockup.sh kslef-test failed in v6.3-rc5

by Pengfei Xu

Hi Christophe Leroy and gpio experts, Greeting! Platform: Tigerlake-H and so on x86 platforms All detailed info is in link: https://github.com/xupengfe/syzkaller_logs/tree/main/issue_bisect/230406_gp… Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/issue_bisect/230406_gp… gpio-mockup.sh kslef-test failed in v6.3-rc5 kernel. gpio-mockup.sh(gpio overflow test) in kself-test could reproduce this issue: cd linux/tools/testing/selftests 1. ./kselftest_install.sh 2. cd linux/tools/testing/selftests/kselftest_install/gpio # ./gpio-mockup.sh 1. Module load tests 1.1. dynamic allocation of gpio 2. Module load error tests 2.1 gpio overflow test failed: unexpected chip - gpiochip1 GPIO gpio-mockup test FAIL And the simplified steps to reproduce this issue are as follow: " # Load gpio_mockup with overflow ranges -1,1024: modprobe -q gpio_mockup gpio_mockup_ranges="-1,1024" # Check is there some Call Trace generated in dmesg dmesg | grep -C 5 Call # Should not generate any gpiochip folder like /sys/kernel/debug/gpio-mockup/gpiochip1 # Because load gpio_mockup with overflow ranges -1,1024 find "/sys/kernel/debug/gpio-mockup/" -name gpiochip* -type d | sort # Unload the gpio_mockup module modprobe -r gpio_mockup # Check is there "Call Trace" generated in dmesg dmesg | grep -C 5 Call " Actually the judgement "gpio-mockup.sh" test/bisect judgement point is that: Should not generate any gpiochip folder like /sys/kernel/debug/gpio-mockup/gpiochip1 after load gpio_mockup with overflow ranges -1,1024. I met gpio-mockup.sh test failed but there is no any "Call Trace" dmesg info sometimes. So the shortest check steps are as follow: " 1. modprobe -q gpio_mockup gpio_mockup_ranges="-1,1024" After above gpio_mockup module loaded with overflow range "-1,1024": Correct behavior as previous v6.1 or older kernel:"gpio should not load "gpiochip1" due to overflow range -1,1024"; Wrong behavior in v6.3-rc5 kernel: "gpio *load* "gpiochip1" with overflow range -1,1024 and "gpiochip1" should not be loaded". The underlying problem was already buried here. 2. Could use below command to check if "gpiochip1" generated: As before v6.1, there was no "/sys/kernel/debug/gpio-mockup/gpiochip1" sysfs folder due to overflow range -1,1024"; Wrong behavior in v6.3-rc5 kernel: "/sys/kernel/debug/gpio-mockup/gpiochip1" sysfs folder generated as follow command check: # find "/sys/kernel/debug/gpio-mockup/" -name gpiochip* -type d | sort /sys/kernel/debug/gpio-mockup/gpiochip1 If there is gpiochip* generated, gpio-mockup.sh kself-test would be failed also. " Bisected and found the bad commit was: " 7b61212f2a07a5afd213c8876e52b5c9946441e2 gpiolib: Get rid of ARCH_NR_GPIOS " And after reverted the above commit on top of v6.3-rc5 kernel, above gpio-mockup.sh kself-test could pass and this issue was gone. Now gpio-mockup.sh kself-test is failed on almost all x86 platform from v6.2 cycle mainline kernel. I hope above info is helpful to solve the "gpio-mockup.sh kself-test failed" problem. Thanks! BR.

2 years, 5 months

2
2
0 0

[GIT PULL] Kselftest fixes update for Linux 6.3-rc6

by Shuah Khan

Hi Linus, Please pull the following Kselftest fixes update for Linux 6.3-rc6. This Kselftest fixes update for Linux 6.3-rc6 consists of one single fix to mount_setattr_test build failure. diff is attached. thanks, -- Shuah ---------------------------------------------------------------- The following changes since commit 05107edc910135d27fe557267dc45be9630bf3dd: selftests: sigaltstack: fix -Wuninitialized (2023-03-20 17:28:31 -0600) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-fixes-6.3-rc6 for you to fetch changes up to f1594bc676579133a3cd906d7d27733289edfb86: selftests mount: Fix mount_setattr_test builds failed (2023-03-31 09:18:45 -0600) ---------------------------------------------------------------- linux-kselftest-fixes-6.3-rc6 This Kselftest fixes update for Linux 6.3-rc6 consists of one single fix to mount_setattr_test build failure. ---------------------------------------------------------------- Anh Tuan Phan (1): selftests mount: Fix mount_setattr_test builds failed tools/testing/selftests/mount_setattr/mount_setattr_test.c | 1 + 1 file changed, 1 insertion(+) ----------------------------------------------------------------

2 years, 5 months

2
1
0 0

[PATCH v4 0/3] mm: process/cgroup ksm support

by Stefan Roesch

So far KSM can only be enabled by calling madvise for memory regions. To be able to use KSM for more workloads, KSM needs to have the ability to be enabled / disabled at the process / cgroup level. Use case 1: The madvise call is not available in the programming language. An example for this are programs with forked workloads using a garbage collected language without pointers. In such a language madvise cannot be made available. In addition the addresses of objects get moved around as they are garbage collected. KSM sharing needs to be enabled "from the outside" for these type of workloads. Use case 2: The same interpreter can also be used for workloads where KSM brings no benefit or even has overhead. We'd like to be able to enable KSM on a workload by workload basis. Use case 3: With the madvise call sharing opportunities are only enabled for the current process: it is a workload-local decision. A considerable number of sharing opportuniites may exist across multiple workloads or jobs. Only a higler level entity like a job scheduler or container can know for certain if its running one or more instances of a job. That job scheduler however doesn't have the necessary internal worklaod knowledge to make targeted madvise calls. Security concerns: In previous discussions security concerns have been brought up. The problem is that an individual workload does not have the knowledge about what else is running on a machine. Therefore it has to be very conservative in what memory areas can be shared or not. However, if the system is dedicated to running multiple jobs within the same security domain, its the job scheduler that has the knowledge that sharing can be safely enabled and is even desirable. Performance: Experiments with using UKSM have shown a capacity increase of around 20%. 1. New options for prctl system command This patch series adds two new options to the prctl system call. The first one allows to enable KSM at the process level and the second one to query the setting. The setting will be inherited by child processes. With the above setting, KSM can be enabled for the seed process of a cgroup and all processes in the cgroup will inherit the setting. 2. Changes to KSM processing When KSM is enabled at the process level, the KSM code will iterate over all the VMA's and enable KSM for the eligible VMA's. When forking a process that has KSM enabled, the setting will be inherited by the new child process. In addition when KSM is disabled for a process, KSM will be disabled for the VMA's where KSM has been enabled. 3. Add general_profit metric The general_profit metric of KSM is specified in the documentation, but not calculated. This adds the general profit metric to /sys/kernel/debug/mm/ksm. 4. Add more metrics to ksm_stat This adds the process profit and ksm type metric to /proc/<pid>/ksm_stat. 5. Add more tests to ksm_tests This adds an option to specify the merge type to the ksm_tests. This allows to test madvise and prctl KSM. It also adds a new option to query if prctl KSM has been enabled. It adds a fork test to verify that the KSM process setting is inherited by client processes. Changes: - V4: - removing check in prctl for MMF_VM_MERGEABLE in PR_SET_MEMORY_MERGE handling - Checking for VM_MERGEABLE AND MMF_VM_MERGE_ANY to avoid chaning vm_flags - This requires also checking that the vma is compatible. The compatibility check is provided by a new helper - processes which have set MMF_VM_MERGE_ANY, only need to call the helper and not madvise. - removed unmerge_vmas function, this function is no longer necessary, clearing the MMF_VM_MERGE_ANY bit is sufficient - V3: - folded patch 1 - 6 - folded patch 7 - 14 - folded patch 15 - 19 - Expanded on the use cases in the cover letter - Added a section on security concerns to the cover letter - V2: - Added use cases to the cover letter - Removed the tracing patch from the patch series and posted it as an individual patch - Refreshed repo Stefan Roesch (3): mm: add new api to enable ksm per process mm: add new KSM process and sysfs knobs selftests/mm: add new selftests for KSM Documentation/ABI/testing/sysfs-kernel-mm-ksm | 8 + Documentation/admin-guide/mm/ksm.rst | 8 +- fs/proc/base.c | 5 + include/linux/ksm.h | 19 +- include/linux/sched/coredump.h | 1 + include/uapi/linux/prctl.h | 2 + kernel/sys.c | 27 ++ mm/ksm.c | 137 +++++++--- tools/include/uapi/linux/prctl.h | 2 + tools/testing/selftests/mm/Makefile | 2 +- tools/testing/selftests/mm/ksm_tests.c | 254 +++++++++++++++--- 11 files changed, 388 insertions(+), 77 deletions(-) -- 2.34.1

2 years, 5 months

5
18
0 0

[PATCH v5 0/3] mm: process/cgroup ksm support

by Stefan Roesch

So far KSM can only be enabled by calling madvise for memory regions. To be able to use KSM for more workloads, KSM needs to have the ability to be enabled / disabled at the process / cgroup level. Use case 1: The madvise call is not available in the programming language. An example for this are programs with forked workloads using a garbage collected language without pointers. In such a language madvise cannot be made available. In addition the addresses of objects get moved around as they are garbage collected. KSM sharing needs to be enabled "from the outside" for these type of workloads. Use case 2: The same interpreter can also be used for workloads where KSM brings no benefit or even has overhead. We'd like to be able to enable KSM on a workload by workload basis. Use case 3: With the madvise call sharing opportunities are only enabled for the current process: it is a workload-local decision. A considerable number of sharing opportunities may exist across multiple workloads or jobs (if they are part of the same security domain). Only a higler level entity like a job scheduler or container can know for certain if its running one or more instances of a job. That job scheduler however doesn't have the necessary internal workload knowledge to make targeted madvise calls. Security concerns: In previous discussions security concerns have been brought up. The problem is that an individual workload does not have the knowledge about what else is running on a machine. Therefore it has to be very conservative in what memory areas can be shared or not. However, if the system is dedicated to running multiple jobs within the same security domain, its the job scheduler that has the knowledge that sharing can be safely enabled and is even desirable. Performance: Experiments with using UKSM have shown a capacity increase of around 20%. 1. New options for prctl system command This patch series adds two new options to the prctl system call. The first one allows to enable KSM at the process level and the second one to query the setting. The setting will be inherited by child processes. With the above setting, KSM can be enabled for the seed process of a cgroup and all processes in the cgroup will inherit the setting. 2. Changes to KSM processing When KSM is enabled at the process level, the KSM code will iterate over all the VMA's and enable KSM for the eligible VMA's. When forking a process that has KSM enabled, the setting will be inherited by the new child process. In addition when KSM is disabled for a process, KSM will be disabled for the VMA's where KSM has been enabled. 3. Add general_profit metric The general_profit metric of KSM is specified in the documentation, but not calculated. This adds the general profit metric to /sys/kernel/debug/mm/ksm. 4. Add more metrics to ksm_stat This adds the process profit and ksm type metric to /proc/<pid>/ksm_stat. 5. Add more tests to ksm_tests This adds an option to specify the merge type to the ksm_tests. This allows to test madvise and prctl KSM. It also adds a new option to query if prctl KSM has been enabled. It adds a fork test to verify that the KSM process setting is inherited by client processes. Changes: - V5: - When the prctl system call is invoked, mark all compatible VMA as mergeable - Instead of checcking during scan if VMA is mergeable, mark the VMA mergeable when the VMA is created (in case the VMA is compatible) - Remove earlier changes, they are no longer necessary - Unset the flag MMF_VM_MERGE_ANY in gmap_mark_unmergeable(). - When unsetting the MMF_VM_MERGE_ANY flag with prctl, only unset the flag - Remove pages_volatile function (with the simplar general_profit calculation, the function is no longer needed) - Use simpler formula for calculation of general_profit - V4: - removing check in prctl for MMF_VM_MERGEABLE in PR_SET_MEMORY_MERGE handling - Checking for VM_MERGEABLE AND MMF_VM_MERGE_ANY to avoid chaning vm_flags - This requires also checking that the vma is compatible. The compatibility check is provided by a new helper - processes which have set MMF_VM_MERGE_ANY, only need to call the helper and not madvise. - removed unmerge_vmas function, this function is no longer necessary, clearing the MMF_VM_MERGE_ANY bit is sufficient - V3: - folded patch 1 - 6 - folded patch 7 - 14 - folded patch 15 - 19 - Expanded on the use cases in the cover letter - Added a section on security concerns to the cover letter - V2: - Added use cases to the cover letter - Removed the tracing patch from the patch series and posted it as an individual patch - Refreshed repo Stefan Roesch (3): mm: add new api to enable ksm per process mm: add new KSM process and sysfs knobs selftests/mm: add new selftests for KSM Documentation/ABI/testing/sysfs-kernel-mm-ksm | 8 + Documentation/admin-guide/mm/ksm.rst | 8 +- arch/s390/mm/gmap.c | 1 + fs/proc/base.c | 5 + include/linux/ksm.h | 36 ++- include/linux/sched/coredump.h | 1 + include/uapi/linux/prctl.h | 2 + kernel/fork.c | 1 + kernel/sys.c | 24 ++ mm/ksm.c | 143 ++++++++-- mm/mmap.c | 7 + tools/include/uapi/linux/prctl.h | 2 + tools/testing/selftests/mm/Makefile | 2 +- tools/testing/selftests/mm/ksm_tests.c | 254 +++++++++++++++--- 14 files changed, 426 insertions(+), 68 deletions(-) -- 2.34.1

2 years, 5 months

1
0
0 0

[PATCH v2 net-next 0/6] ATU and FDB synchronization on locked ports

by Hans J. Schultz

This patch set makes it possible to have synchronized dynamic ATU and FDB entries on locked ports. As locked ports are not able to automatically learn, they depend on userspace added entries, where userspace can add static or dynamic entries. The lifetime of static entries are completely dependent on userspace intervention, and thus not of interest here. We are only concerned with dynamic entries, which can be added with a command like: bridge fdb replace ADDR dev <DEV> master dynamic We choose only to support this feature on locked ports, as it involves utilizing the CPU to handle ATU related switchcore events (typically interrupts) and thus can result in significant performance loss if exposed to heavy traffic. On locked ports it is important for userspace to know when an authorized station has become silent, hence not breaking the communication of a station that has been authorized based on the MAC-Authentication Bypass (MAB) scheme. Thus if the station keeps being active after authorization, it will continue to have an open port as long as it is active. Only after a silent period will it have to be reauthorized. As the ageing process in the ATU is dependent on incoming traffic to the switchcore port, it is necessary for the ATU to signal that an entry has aged out, so that the FDB can be updated at the correct time. This patch set includes a solution for the Marvell mv88e6xxx driver, where for this driver we use the Hold-At-One feature so that an age-out violation interrupt occurs when a station has been silent for the system-set age time. The age out violation interrupt allows the switchcore driver to remove both the ATU and the FDB entry at the same time. It is up to the maintainers of other switchcore drivers to implement the feature for their specific driver. LOG: V2: Ensure the port is locked when using the feature as we must ensure that learning is enabled at all times for the interrupts to occur. This was missed in the previous version. Instead of ignoring unsupported flags, ensure that drivers are only called when supporting the feature. As 'dynamic' flag is legacy, all drivers support it at least by their previous handling. Hans J. Schultz (6): net: bridge: add dynamic flag to switchdev notifier net: dsa: propagate flags down towards drivers drivers: net: dsa: add fdb entry flags incoming to switchcore drivers net: bridge: ensure FDB offloaded flag is handled as needed net: dsa: mv88e6xxx: implementation of dynamic ATU entries selftests: forwarding: add dynamic FDB test drivers/net/dsa/b53/b53_common.c | 4 +- drivers/net/dsa/b53/b53_priv.h | 4 +- drivers/net/dsa/hirschmann/hellcreek.c | 4 +- drivers/net/dsa/lan9303-core.c | 4 +- drivers/net/dsa/lantiq_gswip.c | 4 +- drivers/net/dsa/microchip/ksz_common.c | 6 +- drivers/net/dsa/mt7530.c | 4 +- drivers/net/dsa/mv88e6xxx/chip.c | 20 ++++-- drivers/net/dsa/mv88e6xxx/chip.h | 9 ++- drivers/net/dsa/mv88e6xxx/global1_atu.c | 21 +++++++ drivers/net/dsa/mv88e6xxx/port.c | 6 +- drivers/net/dsa/mv88e6xxx/switchdev.c | 61 +++++++++++++++++++ drivers/net/dsa/mv88e6xxx/switchdev.h | 5 ++ drivers/net/dsa/mv88e6xxx/trace.h | 5 ++ drivers/net/dsa/ocelot/felix.c | 4 +- drivers/net/dsa/qca/qca8k-common.c | 4 +- drivers/net/dsa/qca/qca8k.h | 4 +- drivers/net/dsa/rzn1_a5psw.c | 4 +- drivers/net/dsa/sja1105/sja1105_main.c | 11 ++-- include/net/dsa.h | 9 ++- include/net/switchdev.h | 1 + net/bridge/br_fdb.c | 5 +- net/bridge/br_switchdev.c | 1 + net/dsa/dsa.c | 6 ++ net/dsa/port.c | 28 +++++---- net/dsa/port.h | 8 +-- net/dsa/slave.c | 20 ++++-- net/dsa/switch.c | 26 +++++--- net/dsa/switch.h | 1 + .../net/forwarding/bridge_locked_port.sh | 36 +++++++++++ 30 files changed, 258 insertions(+), 67 deletions(-) -- 2.34.1

2 years, 5 months

5
42
0 0

[PATCH 0/2] kselftest: Support nolibc

by Mark Brown

At present the kselftest header can't be used with nolibc since it makes use of vprintf() which is not available in nolibc and seems like it would be inappropriate to implement given the minimal system requirements and environment intended for nolibc. This has resulted in some open coded kselftests which use nolibc to test features that are supposed to be controlled via libc and therefore better exercised in an environment with no libc. Rather than continue this let's factor out the I/O routines in kselftest.h into a separate header file and provide a nolibc implementation which only allows simple strings to be provided rather than full printf() support. This is limiting but a great improvement on sharing no code at all. As an example of using this I've updated the arm64 za-fork test to use the standard kselftest.h. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Mark Brown (2): kselftest: Support nolibc kselftest/arm64: Convert za-fork to use kselftest.h tools/testing/selftests/arm64/fp/Makefile | 2 +- tools/testing/selftests/arm64/fp/za-fork.c | 88 +++-------------- tools/testing/selftests/kselftest-nolibc.h | 93 ++++++++++++++++++ tools/testing/selftests/kselftest-std.h | 151 +++++++++++++++++++++++++++++ tools/testing/selftests/kselftest.h | 149 +++------------------------- 5 files changed, 272 insertions(+), 211 deletions(-) --- base-commit: e8d018dd0257f744ca50a729e3d042cf2ec9da65 change-id: 20230405-kselftest-nolibc-cb2ce0446d09 Best regards, -- Mark Brown <broonie(a)kernel.org>

2 years, 5 months

2
5
0 0

Re: [PATCH v4 2/3] mm: add new KSM process and sysfs knobs

by David Hildenbrand

On 10.03.23 19:28, Stefan Roesch wrote: > This adds the general_profit KSM sysfs knob and the process profit metric > and process merge type knobs to ksm_stat. > > 1) split off pages_volatile function > > This splits off the pages_volatile function. The next patch will > use this function. > > 2) expose general_profit metric > > The documentation mentions a general profit metric, however this > metric is not calculated. In addition the formula depends on the size > of internal structures, which makes it more difficult for an > administrator to make the calculation. Adding the metric for a better > user experience. > > 3) document general_profit sysfs knob > > 4) calculate ksm process profit metric > > The ksm documentation mentions the process profit metric and how to > calculate it. This adds the calculation of the metric. > > 5) add ksm_merge_type() function > > This adds the ksm_merge_type function. The function returns the > merge type for the process. For madvise it returns "madvise", for > prctl it returns "process" and otherwise it returns "none". > > 6) mm: expose ksm process profit metric and merge type in ksm_stat > > This exposes the ksm process profit metric in /proc/<pid>/ksm_stat. > The name of the value is ksm_merge_type. The documentation mentions > the formula for the ksm process profit metric, however it does not > calculate it. In addition the formula depends on the size of internal > structures. So it makes sense to expose it. > > 7) document new procfs ksm knobs > Often, when you have to start making a list of things that a patch does, it might make sense to split some of the items into separate patches such that you can avoid lists and just explain in list-free text how the pieces in the patch fit together. I'd suggest splitting this patch into logical pieces. For example, separating the general profit calculation/exposure from the per-mm profit and the per-mm ksm type indication. > Link: https://lkml.kernel.org/r/20230224044000.3084046-3-shr@devkernel.io > Signed-off-by: Stefan Roesch <shr(a)devkernel.io> > Reviewed-by: Bagas Sanjaya <bagasdotme(a)gmail.com> > Cc: David Hildenbrand <david(a)redhat.com> > Cc: Johannes Weiner <hannes(a)cmpxchg.org> > Cc: Michal Hocko <mhocko(a)suse.com> > Cc: Rik van Riel <riel(a)surriel.com> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > --- [...] > KSM_ATTR_RO(pages_volatile); > > @@ -3280,6 +3305,21 @@ static ssize_t zero_pages_sharing_show(struct kobject *kobj, > } > KSM_ATTR_RO(zero_pages_sharing); > > +static ssize_t general_profit_show(struct kobject *kobj, > + struct kobj_attribute *attr, char *buf) > +{ > + long general_profit; > + long all_rmap_items; > + > + all_rmap_items = ksm_max_page_sharing + ksm_pages_shared + > + ksm_pages_unshared + pages_volatile(); Are you sure you want to count a config knob (ksm_max_page_sharing) into that formula? I yet have to digest what this calculation implies, but it does feel odd. Further, maybe just avoid pages_volatile(). Expanding the formula (excluding ksm_max_page_sharing for now): all_rmap = ksm_pages_shared + ksm_pages_unshared + pages_volatile(); -> expand pages_volatile() (ignoring the < 0 case) all_rmap = ksm_pages_shared + ksm_pages_unshared + ksm_rmap_items - ksm_pages_shared - ksm_pages_sharing - ksm_pages_unshared; -> simplify all_rmap = ksm_rmap_items + ksm_pages_sharing; Or is the < 0 case relevant here? > + general_profit = ksm_pages_sharing * PAGE_SIZE - > + all_rmap_items * sizeof(struct ksm_rmap_item); > + > + return sysfs_emit(buf, "%ld\n", general_profit); > +} > +KSM_ATTR_RO(general_profit); > + > static ssize_t stable_node_dups_show(struct kobject *kobj, > struct kobj_attribute *attr, char *buf) > { > @@ -3345,6 +3385,7 @@ static struct attribute *ksm_attrs[] = { > &stable_node_dups_attr.attr, > &stable_node_chains_prune_millisecs_attr.attr, > &use_zero_pages_attr.attr, > + &general_profit_attr.attr, > NULL, > }; > The calculations (profit) don't include when KSM places the shared zeropage I guess. Accounting that per MM (and eventually globally) is in the works. [1] [1] https://lore.kernel.org/lkml/20230328153852.26c2577e4bd921c371c47a7e@linux-… -- Thanks, David / dhildenb

2 years, 5 months

3
4
0 0

[PATCH bpf-next v4 3/3] selftests: xsk: Add tests for 8K and 9K frame sizes

by Kal Conley

Add tests: - RUN_TO_COMPLETION_8K_FRAME_SIZE: frame_size=8192 (aligned) - UNALIGNED_9K_FRAME_SIZE: frame_size=9000 (unaligned) Signed-off-by: Kal Conley <kal.conley(a)dectris.com> --- tools/testing/selftests/bpf/xskxceiver.c | 25 ++++++++++++++++++++++++ tools/testing/selftests/bpf/xskxceiver.h | 2 ++ 2 files changed, 27 insertions(+) diff --git a/tools/testing/selftests/bpf/xskxceiver.c b/tools/testing/selftests/bpf/xskxceiver.c index 7eccf57a0ccc..86797de7fc50 100644 --- a/tools/testing/selftests/bpf/xskxceiver.c +++ b/tools/testing/selftests/bpf/xskxceiver.c @@ -1841,6 +1841,17 @@ static void run_pkt_test(struct test_spec *test, enum test_mode mode, enum test_ pkt_stream_replace(test, DEFAULT_PKT_CNT, PKT_SIZE); testapp_validate_traffic(test); break; + case TEST_TYPE_RUN_TO_COMPLETION_8K_FRAME: + if (!hugepages_present(test->ifobj_tx)) { + ksft_test_result_skip("No 2M huge pages present.\n"); + return; + } + test_spec_set_name(test, "RUN_TO_COMPLETION_8K_FRAME_SIZE"); + test->ifobj_tx->umem->frame_size = 8192; + test->ifobj_rx->umem->frame_size = 8192; + pkt_stream_replace(test, DEFAULT_PKT_CNT, PKT_SIZE); + testapp_validate_traffic(test); + break; case TEST_TYPE_RX_POLL: test->ifobj_rx->use_poll = true; test_spec_set_name(test, "POLL_RX"); @@ -1904,6 +1915,20 @@ static void run_pkt_test(struct test_spec *test, enum test_mode mode, enum test_ if (!testapp_unaligned(test)) return; break; + case TEST_TYPE_UNALIGNED_9K_FRAME: + if (!hugepages_present(test->ifobj_tx)) { + ksft_test_result_skip("No 2M huge pages present.\n"); + return; + } + test_spec_set_name(test, "UNALIGNED_9K_FRAME_SIZE"); + test->ifobj_tx->umem->frame_size = 9000; + test->ifobj_rx->umem->frame_size = 9000; + test->ifobj_tx->umem->unaligned_mode = true; + test->ifobj_rx->umem->unaligned_mode = true; + pkt_stream_replace(test, DEFAULT_PKT_CNT, PKT_SIZE); + test->ifobj_rx->pkt_stream->use_addr_for_fill = true; + testapp_validate_traffic(test); + break; case TEST_TYPE_HEADROOM: testapp_headroom(test); break; diff --git a/tools/testing/selftests/bpf/xskxceiver.h b/tools/testing/selftests/bpf/xskxceiver.h index 919327807a4e..7f52f737f5e9 100644 --- a/tools/testing/selftests/bpf/xskxceiver.h +++ b/tools/testing/selftests/bpf/xskxceiver.h @@ -69,12 +69,14 @@ enum test_mode { enum test_type { TEST_TYPE_RUN_TO_COMPLETION, TEST_TYPE_RUN_TO_COMPLETION_2K_FRAME, + TEST_TYPE_RUN_TO_COMPLETION_8K_FRAME, TEST_TYPE_RUN_TO_COMPLETION_SINGLE_PKT, TEST_TYPE_RX_POLL, TEST_TYPE_TX_POLL, TEST_TYPE_POLL_RXQ_TMOUT, TEST_TYPE_POLL_TXQ_TMOUT, TEST_TYPE_UNALIGNED, + TEST_TYPE_UNALIGNED_9K_FRAME, TEST_TYPE_ALIGNED_INV_DESC, TEST_TYPE_ALIGNED_INV_DESC_2K_FRAME, TEST_TYPE_UNALIGNED_INV_DESC, -- 2.39.2

2 years, 5 months

1
0
0 0

[PATCH bpf-next v4 2/3] selftests: xsk: Use hugepages when umem->frame_size > PAGE_SIZE

by Kal Conley

HugeTLB UMEMs now support chunk_size > PAGE_SIZE. Set MAP_HUGETLB when frame_size > PAGE_SIZE for future tests. Signed-off-by: Kal Conley <kal.conley(a)dectris.com> --- tools/testing/selftests/bpf/xskxceiver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/xskxceiver.c b/tools/testing/selftests/bpf/xskxceiver.c index 5a9691e942de..7eccf57a0ccc 100644 --- a/tools/testing/selftests/bpf/xskxceiver.c +++ b/tools/testing/selftests/bpf/xskxceiver.c @@ -1289,7 +1289,7 @@ static void thread_common_ops(struct test_spec *test, struct ifobject *ifobject) void *bufs; int ret; - if (ifobject->umem->unaligned_mode) + if (ifobject->umem->frame_size > sysconf(_SC_PAGESIZE) || ifobject->umem->unaligned_mode) mmap_flags |= MAP_HUGETLB; if (ifobject->shared_umem) -- 2.39.2

2 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror