Hi Shuah, David,
I am sorry for my slow response, I have submit a new patch to fix it. Please see: https://patchwork.kernel.org/project/linux-kselftest/patch/20221011013926.2…
Thanks,
Gongyi
>
> On 10/10/22 00:54, David Hildenbrand wrote:
> > On 08.10.22 03:40, zhaogongyi wrote:
>
> >>
> >> Yes, online_memory_expect_success() already prints a warning,
> remove
> >> the warning in online_all_offline_memory() seems ok,
> >>
> >> My previous consideration was that one more log information would
> make it easier to locate the wrong location.
> >
> > Let's keep it simple unless there is real reason to warn twice.
> >
>
> zhaogongyi,
>
> Please note that I already applied the patches to linux-kselftest next for my
> second pull request before the merge window. Please send the change
> David requested in a separate patch on top of next as a fix.
>
> thanks,
> -- Shuah
From: Roberto Sassu <roberto.sassu(a)huawei.com>
Add the _opts variant for bpf_*_get_fd_by_id() functions, to be able to
pass to the kernel more options, when requesting a fd of an eBPF object.
Pass the options through a newly introduced structure,
bpf_get_fd_by_id_opts, which currently contains open_flags (the other two
members are for compatibility and for padding).
open_flags allows the caller to request specific permissions to access a
map (e.g. read-only). This is useful for example in the situation where a
map is write-protected.
Besides patches 2-6, which introduce the new variants and the data
structure, patch 1 fixes the LIBBPF_1.0.0 declaration in libbpf.map.
Changelog
v1:
- Don't CC stable kernel mailing list for patch 1 (suggested by Andrii)
- Rename bpf_get_fd_opts struct to bpf_get_fd_by_id_opts (suggested by
Andrii)
- Move declaration of _opts variants after non-opts variants (suggested by
Andrii)
- Correctly initialize bpf_map_info, fix style issues, use map from
skeleton, check valid fd in the test (suggested by Andrii)
- Rename libbpf_get_fd_opts test to libbpf_get_fd_by_id_opts
Roberto Sassu (6):
libbpf: Fix LIBBPF_1.0.0 declaration in libbpf.map
libbpf: Introduce bpf_get_fd_by_id_opts and
bpf_map_get_fd_by_id_opts()
libbpf: Introduce bpf_prog_get_fd_by_id_opts()
libbpf: Introduce bpf_btf_get_fd_by_id_opts()
libbpf: Introduce bpf_link_get_fd_by_id_opts()
selftests/bpf: Add tests for _opts variants of bpf_*_get_fd_by_id()
tools/lib/bpf/bpf.c | 48 +++++++++-
tools/lib/bpf/bpf.h | 16 ++++
tools/lib/bpf/libbpf.map | 6 +-
tools/testing/selftests/bpf/DENYLIST.s390x | 1 +
.../bpf/prog_tests/libbpf_get_fd_by_id_opts.c | 87 +++++++++++++++++++
.../bpf/progs/test_libbpf_get_fd_by_id_opts.c | 36 ++++++++
6 files changed, 189 insertions(+), 5 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/libbpf_get_fd_by_id_opts.c
create mode 100644 tools/testing/selftests/bpf/progs/test_libbpf_get_fd_by_id_opts.c
--
2.25.1
Hi!
>
> On 30.09.22 10:52, zhaogongyi wrote:
> > Hi!
> >
> >>
> >> On 30.09.22 08:35, Zhao Gongyi wrote:
> >>> Some momory will be left in offline state when calling
> >>> offline_memory_expect_fail() failed. Restore it before exit.
> >>>
> >>> Signed-off-by: Zhao Gongyi <zhaogongyi(a)huawei.com>
> >>> ---
> >>> .../memory-hotplug/mem-on-off-test.sh | 21
> >> ++++++++++++++-----
> >>> 1 file changed, 16 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
> >> b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
> >>> index 1d87611a7d52..91a7457616bb 100755
> >>> --- a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
> >>> +++ b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
> >>> @@ -134,6 +134,16 @@ offline_memory_expect_fail()
> >>> return 0
> >>> }
> >>>
> >>> +online_all_offline_memory()
> >>> +{
> >>> + for memory in `hotpluggable_offline_memory`; do
> >>> + if ! online_memory_expect_success $memory; then
> >>> + echo "$FUNCNAME $memory: unexpected fail" >&2
> >>
> >> Do we need that output?
> >
> > In my opinion, if online a memory node failed ,it should be a kernel bug
> catched, so, I think the output here is needed.
>
> But online_memory_expect_success() already prints a warning, no?
Yes, online_memory_expect_success() already prints a warning, remove the warning in online_all_offline_memory() seems ok,
My previous consideration was that one more log information would make it easier to locate the wrong location.
Best Regards,
Gongyi