Message ID | 20250228194654.1022535-1-ihor.solodrai@linux.dev (mailing list archive) |
---|---|
Headers | show |
Series | btf_encoder: emit type tags for bpf_arena pointers | expand |
On 2/28/25 11:46 AM, Ihor Solodrai wrote: > This patch series implements emitting appropriate BTF type tags for > argument and return types of kfuncs marked with KF_ARENA_* flags. > > For additional context see the description of BPF patch > "bpf: define KF_ARENA_* flags for bpf_arena kfuncs" [1]. > > The feature depends on recent changes in libbpf [2]. > > [1] https://lore.kernel.org/bpf/20250206003148.2308659-1-ihor.solodrai@linux.dev/ > [2] https://lore.kernel.org/bpf/20250130201239.1429648-1-ihor.solodrai@linux.dev/ > > v3->v4: > * Add a patch (#2) replacing compile-time libbpf version checks with > runtime checks for symbol availablility > * Add a patch (#3) bumping libbpf submodule commit to latest master > * Modify "btf_encoder: emit type tags for bpf_arena pointers" > (#2->#4) to not use compile time libbpf version checks > > v2->v3: > * Nits in patch #1 > > v1->v2: > * Rewrite patch #1 refactoring btf_encoder__tag_kfuncs(): now the > post-processing step is removed entirely, and kfuncs are tagged in > btf_encoder__add_func(). > * Nits and renames in patch #2 > * Add patch #4 editing man pages > > v2: https://lore.kernel.org/dwarves/20250212201552.1431219-1-ihor.solodrai@linux.dev/ > v1: https://lore.kernel.org/dwarves/20250207021442.155703-1-ihor.solodrai@linux.dev/ > > Ihor Solodrai (6): > btf_encoder: refactor btf_encoder__tag_kfuncs() > btf_encoder: use __weak declarations of version-dependent libbpf API > pahole: sync with libbpf mainline > btf_encoder: emit type tags for bpf_arena pointers > pahole: introduce --btf_feature=attributes > man-pages: describe attributes and remove reproducible_build Hi Alan, Arnaldo. This series hasn't received any comments in a while. Do you plan to review/land this? Thanks. > > btf_encoder.c | 328 ++++++++++++++++++++++----------------------- > dwarves.h | 13 +- > lib/bpf | 2 +- > man-pages/pahole.1 | 7 +- > pahole.c | 11 +- > 5 files changed, 188 insertions(+), 173 deletions(-) >
On 20/03/2025 16:32, Ihor Solodrai wrote: > On 2/28/25 11:46 AM, Ihor Solodrai wrote: >> This patch series implements emitting appropriate BTF type tags for >> argument and return types of kfuncs marked with KF_ARENA_* flags. >> >> For additional context see the description of BPF patch >> "bpf: define KF_ARENA_* flags for bpf_arena kfuncs" [1]. >> >> The feature depends on recent changes in libbpf [2]. >> >> [1] https://lore.kernel.org/bpf/20250206003148.2308659-1-ihor.solodrai@linux.dev/ >> [2] https://lore.kernel.org/bpf/20250130201239.1429648-1-ihor.solodrai@linux.dev/ >> >> v3->v4: >> * Add a patch (#2) replacing compile-time libbpf version checks with >> runtime checks for symbol availablility >> * Add a patch (#3) bumping libbpf submodule commit to latest master >> * Modify "btf_encoder: emit type tags for bpf_arena pointers" >> (#2->#4) to not use compile time libbpf version checks >> >> v2->v3: >> * Nits in patch #1 >> >> v1->v2: >> * Rewrite patch #1 refactoring btf_encoder__tag_kfuncs(): now the >> post-processing step is removed entirely, and kfuncs are tagged in >> btf_encoder__add_func(). >> * Nits and renames in patch #2 >> * Add patch #4 editing man pages >> >> v2: https://lore.kernel.org/dwarves/20250212201552.1431219-1-ihor.solodrai@linux.dev/ >> v1: https://lore.kernel.org/dwarves/20250207021442.155703-1-ihor.solodrai@linux.dev/ >> >> Ihor Solodrai (6): >> btf_encoder: refactor btf_encoder__tag_kfuncs() >> btf_encoder: use __weak declarations of version-dependent libbpf API >> pahole: sync with libbpf mainline >> btf_encoder: emit type tags for bpf_arena pointers >> pahole: introduce --btf_feature=attributes >> man-pages: describe attributes and remove reproducible_build > > Hi Alan, Arnaldo. > > This series hasn't received any comments in a while. > Do you plan to review/land this? > Yep, thanks for the reminder; I hit a wall last time I looked a this when testing with a shared library libbpf versus embedded but I can get around that now so I should have the testing done for both modes tomorrow. Alan > Thanks. > >> >> btf_encoder.c | 328 ++++++++++++++++++++++----------------------- >> dwarves.h | 13 +- >> lib/bpf | 2 +- >> man-pages/pahole.1 | 7 +- >> pahole.c | 11 +- >> 5 files changed, 188 insertions(+), 173 deletions(-) >>
On 20/03/2025 20:34, Alan Maguire wrote: > On 20/03/2025 16:32, Ihor Solodrai wrote: >> On 2/28/25 11:46 AM, Ihor Solodrai wrote: >>> This patch series implements emitting appropriate BTF type tags for >>> argument and return types of kfuncs marked with KF_ARENA_* flags. >>> >>> For additional context see the description of BPF patch >>> "bpf: define KF_ARENA_* flags for bpf_arena kfuncs" [1]. >>> >>> The feature depends on recent changes in libbpf [2]. >>> >>> [1] https://lore.kernel.org/bpf/20250206003148.2308659-1-ihor.solodrai@linux.dev/ >>> [2] https://lore.kernel.org/bpf/20250130201239.1429648-1-ihor.solodrai@linux.dev/ >>> >>> v3->v4: >>> * Add a patch (#2) replacing compile-time libbpf version checks with >>> runtime checks for symbol availablility >>> * Add a patch (#3) bumping libbpf submodule commit to latest master >>> * Modify "btf_encoder: emit type tags for bpf_arena pointers" >>> (#2->#4) to not use compile time libbpf version checks >>> >>> v2->v3: >>> * Nits in patch #1 >>> >>> v1->v2: >>> * Rewrite patch #1 refactoring btf_encoder__tag_kfuncs(): now the >>> post-processing step is removed entirely, and kfuncs are tagged in >>> btf_encoder__add_func(). >>> * Nits and renames in patch #2 >>> * Add patch #4 editing man pages >>> >>> v2: https://lore.kernel.org/dwarves/20250212201552.1431219-1-ihor.solodrai@linux.dev/ >>> v1: https://lore.kernel.org/dwarves/20250207021442.155703-1-ihor.solodrai@linux.dev/ >>> >>> Ihor Solodrai (6): >>> btf_encoder: refactor btf_encoder__tag_kfuncs() >>> btf_encoder: use __weak declarations of version-dependent libbpf API >>> pahole: sync with libbpf mainline >>> btf_encoder: emit type tags for bpf_arena pointers >>> pahole: introduce --btf_feature=attributes >>> man-pages: describe attributes and remove reproducible_build >> >> Hi Alan, Arnaldo. >> >> This series hasn't received any comments in a while. >> Do you plan to review/land this? >> > > Yep, thanks for the reminder; I hit a wall last time I looked a this > when testing with a shared library libbpf versus embedded but I can get > around that now so I should have the testing done for both modes tomorrow. > hi Ihor, I took a look at the series and merged it with latest next branch; results are in https://web.git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next.attributes-v4 ...if you want to take a look. There are a few small things I think that it would be good to resolve before landing this. First, when testing this with -DLIBBPF_EMBEDDED=OFF and a packaged libbpf 1.5 - which means we wouldn't have the latest attributes-related libbpf function; I saw: BTF .tmp_vmlinux1.btf.o btf__add_type_attr is not available, is libbpf < 1.6? error: failed to encode function 'bbr_cwnd_event': invalid proto Failed to encode BTF NM .tmp_vmlinux1.syms ...and we got no BTF as a result. Ideally we'd like pahole to encode but without the attributes feature if not available. Related, we also report features that are not present, i.e. attributes with "--supported_btf_features". So I propose that we make use of the weak declarations being NULL in an optional feature check function. It is optionally declared for a feature, and if declared must return true if the feature is available. Something like the below works (it's in the next.attributes-v4 branch too for reference) and it resolves the issue of BTF generation failure and accurate supported_btf_features reporting. What do you think? Thanks! Alan From: Alan Maguire <alan.maguire@oracle.com> Date: Sun, 23 Mar 2025 11:06:18 +0000 Subject: [PATCH] pahole: add a BTF feature check function It is used to see if functions that BTF features rely on are really there; weak declarations mean they will be NULL if not in non-embedded linked libbpf. This gives us more accurate --supported_btf_features reporting also. Signed-off-by: Alan Maguire <alan.maguire@oracle.com> --- pahole.c | 39 +++++++++++++++++++++++++++++++++------ 1 file changed, 33 insertions(+), 6 deletions(-) diff --git a/pahole.c b/pahole.c index 4a2b1ce..8304ba4 100644 --- a/pahole.c +++ b/pahole.c @@ -1183,10 +1183,31 @@ ARGP_PROGRAM_VERSION_HOOK_DEF = dwarves_print_version; * floats, etc. This ensures backwards compatibility. */ #define BTF_DEFAULT_FEATURE(name, alias, initial_value) \ - { #name, #alias, &conf_load.alias, initial_value, true } + { #name, #alias, &conf_load.alias, initial_value, true, NULL } + +#define BTF_DEFAULT_FEATURE_CHECK(name, alias, initial_value, feature_check) \ + { #name, #alias, &conf_load.alias, initial_value, true, feature_check } #define BTF_NON_DEFAULT_FEATURE(name, alias, initial_value) \ - { #name, #alias, &conf_load.alias, initial_value, false } + { #name, #alias, &conf_load.alias, initial_value, false, NULL } + +#define BTF_NON_DEFAULT_FEATURE_CHECK(name, alias, initial_value, feature_check) \ + { #name, #alias, &conf_load.alias, initial_value, false, feature_check } + +static bool enum64_check(void) +{ + return btf__add_enum64 != NULL; +} + +static bool distilled_base_check(void) +{ + return btf__distill_base != NULL; +} + +static bool attributes_check(void) +{ + return btf__add_type_attr != NULL; +} struct btf_feature { const char *name; @@ -1196,20 +1217,23 @@ struct btf_feature { bool default_enabled; /* some nonstandard features may not * be enabled for --btf_features=default */ + bool (*feature_check)(void); } btf_features[] = { BTF_DEFAULT_FEATURE(encode_force, btf_encode_force, false), BTF_DEFAULT_FEATURE(var, skip_encoding_btf_vars, true), BTF_DEFAULT_FEATURE(float, btf_gen_floats, false), BTF_DEFAULT_FEATURE(decl_tag, skip_encoding_btf_decl_tag, true), BTF_DEFAULT_FEATURE(type_tag, skip_encoding_btf_type_tag, true), - BTF_DEFAULT_FEATURE(enum64, skip_encoding_btf_enum64, true), + BTF_DEFAULT_FEATURE_CHECK(enum64, skip_encoding_btf_enum64, true, enum64_check), BTF_DEFAULT_FEATURE(optimized_func, btf_gen_optimized, false), BTF_DEFAULT_FEATURE(consistent_func, skip_encoding_btf_inconsistent_proto, false), BTF_DEFAULT_FEATURE(decl_tag_kfuncs, btf_decl_tag_kfuncs, false), BTF_NON_DEFAULT_FEATURE(reproducible_build, reproducible_build, false), - BTF_NON_DEFAULT_FEATURE(distilled_base, btf_gen_distilled_base, false), + BTF_NON_DEFAULT_FEATURE_CHECK(distilled_base, btf_gen_distilled_base, false, + distilled_base_check), BTF_NON_DEFAULT_FEATURE(global_var, encode_btf_global_vars, false), - BTF_NON_DEFAULT_FEATURE(attributes, btf_attributes, false), + BTF_NON_DEFAULT_FEATURE_CHECK(attributes, btf_attributes, false, + attributes_check), }; #define BTF_MAX_FEATURE_STR 1024 @@ -1248,7 +1272,8 @@ static void enable_btf_feature(struct btf_feature *feature) /* switch "initial-off" features on, and "initial-on" features * off; i.e. negate the initial value. */ - *feature->conf_value = !feature->initial_value; + if (!feature->feature_check || feature->feature_check()) + *feature->conf_value = !feature->initial_value; } static void show_supported_btf_features(FILE *output) @@ -1256,6 +1281,8 @@ static void show_supported_btf_features(FILE *output) int i; for (i = 0; i < ARRAY_SIZE(btf_features); i++) { + if (btf_features[i].feature_check && !btf_features[i].feature_check()) + continue; if (i > 0) fprintf(output, ","); fprintf(output, "%s", btf_features[i].name);
On 3/23/25 4:11 AM, Alan Maguire wrote: > [...] > > hi Ihor, I took a look at the series and merged it with latest next > branch; results are in > > https://web.git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next.attributes-v4 > > ...if you want to take a look. > > There are a few small things I think that it would be good to resolve > before landing this. > > First, when testing this with -DLIBBPF_EMBEDDED=OFF and a packaged > libbpf 1.5 - which means we wouldn't have the latest attributes-related > libbpf function; I saw: > > BTF .tmp_vmlinux1.btf.o > btf__add_type_attr is not available, is libbpf < 1.6? > error: failed to encode function 'bbr_cwnd_event': invalid proto > Failed to encode BTF > NM .tmp_vmlinux1.syms Hi Alan. Thanks for testing. This is my mistake, I should've checked for attributes feature here: @@ -731,6 +812,10 @@ static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct f assert(ftype != NULL || state != NULL); + if (is_kfunc_state(state) && encoder->tag_kfuncs) + if (btf__add_bpf_arena_type_tags(encoder->btf, state) < 0) + return -1; > > ...and we got no BTF as a result. Ideally we'd like pahole to encode but > without the attributes feature if not available. Related, we also report > features that are not present, i.e. attributes with > "--supported_btf_features". So I propose that we make use of the weak > declarations being NULL in an optional feature check function. It is > optionally declared for a feature, and if declared must return true if > the feature is available. > > Something like the below works (it's in the next.attributes-v4 branch > too for reference) and it resolves the issue of BTF generation failure > and accurate supported_btf_features reporting. What do you think? Thanks! I think failing fast is a good approach here: check that all requested/default features are available on startup. > > Alan > > From: Alan Maguire <alan.maguire@oracle.com> > Date: Sun, 23 Mar 2025 11:06:18 +0000 > Subject: [PATCH] pahole: add a BTF feature check function > > It is used to see if functions that BTF features rely on are > really there; weak declarations mean they will be NULL if not > in non-embedded linked libbpf. > > This gives us more accurate --supported_btf_features reporting also. > > Signed-off-by: Alan Maguire <alan.maguire@oracle.com> > --- > pahole.c | 39 +++++++++++++++++++++++++++++++++------ > 1 file changed, 33 insertions(+), 6 deletions(-) > Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev> > diff --git a/pahole.c b/pahole.c > index 4a2b1ce..8304ba4 100644 > --- a/pahole.c > +++ b/pahole.c > @@ -1183,10 +1183,31 @@ ARGP_PROGRAM_VERSION_HOOK_DEF = > dwarves_print_version; > * floats, etc. This ensures backwards compatibility. > */ > #define BTF_DEFAULT_FEATURE(name, alias, initial_value) \ > - { #name, #alias, &conf_load.alias, initial_value, true } > + { #name, #alias, &conf_load.alias, initial_value, true, NULL } > + > +#define BTF_DEFAULT_FEATURE_CHECK(name, alias, initial_value, > feature_check) \ > + { #name, #alias, &conf_load.alias, initial_value, true, feature_check } > > #define BTF_NON_DEFAULT_FEATURE(name, alias, initial_value) \ > - { #name, #alias, &conf_load.alias, initial_value, false } > + { #name, #alias, &conf_load.alias, initial_value, false, NULL } > + > +#define BTF_NON_DEFAULT_FEATURE_CHECK(name, alias, initial_value, > feature_check) \ > + { #name, #alias, &conf_load.alias, initial_value, false, feature_check } > + > +static bool enum64_check(void) > +{ > + return btf__add_enum64 != NULL; > +} > + > +static bool distilled_base_check(void) > +{ > + return btf__distill_base != NULL; > +} > + > +static bool attributes_check(void) > +{ > + return btf__add_type_attr != NULL; > +} > > struct btf_feature { > const char *name; > @@ -1196,20 +1217,23 @@ struct btf_feature { > bool default_enabled; /* some nonstandard features may not > * be enabled for --btf_features=default > */ > + bool (*feature_check)(void); > } btf_features[] = { > BTF_DEFAULT_FEATURE(encode_force, btf_encode_force, false), > BTF_DEFAULT_FEATURE(var, skip_encoding_btf_vars, true), > BTF_DEFAULT_FEATURE(float, btf_gen_floats, false), > BTF_DEFAULT_FEATURE(decl_tag, skip_encoding_btf_decl_tag, true), > BTF_DEFAULT_FEATURE(type_tag, skip_encoding_btf_type_tag, true), > - BTF_DEFAULT_FEATURE(enum64, skip_encoding_btf_enum64, true), > + BTF_DEFAULT_FEATURE_CHECK(enum64, skip_encoding_btf_enum64, true, > enum64_check), > BTF_DEFAULT_FEATURE(optimized_func, btf_gen_optimized, false), > BTF_DEFAULT_FEATURE(consistent_func, > skip_encoding_btf_inconsistent_proto, false), > BTF_DEFAULT_FEATURE(decl_tag_kfuncs, btf_decl_tag_kfuncs, false), > BTF_NON_DEFAULT_FEATURE(reproducible_build, reproducible_build, false), > - BTF_NON_DEFAULT_FEATURE(distilled_base, btf_gen_distilled_base, false), > + BTF_NON_DEFAULT_FEATURE_CHECK(distilled_base, btf_gen_distilled_base, > false, > + distilled_base_check), > BTF_NON_DEFAULT_FEATURE(global_var, encode_btf_global_vars, false), > - BTF_NON_DEFAULT_FEATURE(attributes, btf_attributes, false), > + BTF_NON_DEFAULT_FEATURE_CHECK(attributes, btf_attributes, false, > + attributes_check), > }; > > #define BTF_MAX_FEATURE_STR 1024 > @@ -1248,7 +1272,8 @@ static void enable_btf_feature(struct btf_feature > *feature) > /* switch "initial-off" features on, and "initial-on" features > * off; i.e. negate the initial value. > */ > - *feature->conf_value = !feature->initial_value; > + if (!feature->feature_check || feature->feature_check()) > + *feature->conf_value = !feature->initial_value; > } > > static void show_supported_btf_features(FILE *output) > @@ -1256,6 +1281,8 @@ static void show_supported_btf_features(FILE *output) > int i; > > for (i = 0; i < ARRAY_SIZE(btf_features); i++) { > + if (btf_features[i].feature_check && !btf_features[i].feature_check()) > + continue; > if (i > 0) > fprintf(output, ","); > fprintf(output, "%s", btf_features[i].name);
On 3/24/25 11:07 AM, Ihor Solodrai wrote: > On 3/23/25 4:11 AM, Alan Maguire wrote: >> [...] >> >> hi Ihor, I took a look at the series and merged it with latest next >> branch; results are in >> >> https://web.git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next.attributes-v4 >> >> ...if you want to take a look. >> >> There are a few small things I think that it would be good to resolve >> before landing this. >> >> First, when testing this with -DLIBBPF_EMBEDDED=OFF and a packaged >> libbpf 1.5 - which means we wouldn't have the latest attributes-related >> libbpf function; I saw: >> >> BTF .tmp_vmlinux1.btf.o >> btf__add_type_attr is not available, is libbpf < 1.6? >> error: failed to encode function 'bbr_cwnd_event': invalid proto >> Failed to encode BTF >> NM .tmp_vmlinux1.syms > > Hi Alan. Thanks for testing. This is my mistake, I should've checked > for attributes feature here: > > @@ -731,6 +812,10 @@ static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct f > > assert(ftype != NULL || state != NULL); > > + if (is_kfunc_state(state) && encoder->tag_kfuncs) > + if (btf__add_bpf_arena_type_tags(encoder->btf, state) < 0) > + return -1; Actually, I added this check in a different patch so the failure must have happened in a different place. In any case, the point remains that it's better to check for feature availability (hence for API availability) in one place. Your suggestion to add a feature check makes sense to me. Thank you. > [...]
On 24/03/2025 18:47, Ihor Solodrai wrote: > On 3/24/25 11:07 AM, Ihor Solodrai wrote: >> On 3/23/25 4:11 AM, Alan Maguire wrote: >>> [...] >>> >>> hi Ihor, I took a look at the series and merged it with latest next >>> branch; results are in >>> >>> https://web.git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next.attributes-v4 >>> >>> ...if you want to take a look. >>> >>> There are a few small things I think that it would be good to resolve >>> before landing this. >>> >>> First, when testing this with -DLIBBPF_EMBEDDED=OFF and a packaged >>> libbpf 1.5 - which means we wouldn't have the latest attributes-related >>> libbpf function; I saw: >>> >>> BTF .tmp_vmlinux1.btf.o >>> btf__add_type_attr is not available, is libbpf < 1.6? >>> error: failed to encode function 'bbr_cwnd_event': invalid proto >>> Failed to encode BTF >>> NM .tmp_vmlinux1.syms >> >> Hi Alan. Thanks for testing. This is my mistake, I should've checked >> for attributes feature here: >> >> @@ -731,6 +812,10 @@ static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct f >> >> assert(ftype != NULL || state != NULL); >> >> + if (is_kfunc_state(state) && encoder->tag_kfuncs) >> + if (btf__add_bpf_arena_type_tags(encoder->btf, state) < 0) >> + return -1; > > Actually, I added this check in a different patch so the failure must > have happened in a different place. > > In any case, the point remains that it's better to check for feature > availability (hence for API availability) in one place. Your > suggestion to add a feature check makes sense to me. Thank you. > Great; so let's do this to land the series. Could you either - check I merged your patches correctly in the above branch, and if they look good I'll merge them into next and I'll officially send the feature check patch; or if you'd prefer - send a v5 (perhaps including my feature check patch?) ...whichever approach is easiest for you. Thanks! Alan
On 3/25/25 2:59 AM, Alan Maguire wrote: > > [...] > > Great; so let's do this to land the series. Could you either > > - check I merged your patches correctly in the above branch, and if they > look good I'll merge them into next and I'll officially send the feature > check patch; or if you'd prefer > - send a v5 (perhaps including my feature check patch?) > > ...whichever approach is easiest for you. Hi Alan. I reviewed the diff between your branch: https://web.git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next.attributes-v4 and v1.29 + my patchset: https://github.com/theihor/dwarves/tree/v4.kf-arena Not a lot of difference besides your patch. Didn't spot any problems. I also ran a couple of tests on your branch: * generate BTF with and without --btf_feature=attributes * run ./tests/tests on 6.14-rc3 vmlinux (just a build I had at hand) I think you can apply patches from next.attributes-v4 as is. Thank you. > > Thanks! > > Alan
On 26/03/2025 17:41, Ihor Solodrai wrote: > On 3/25/25 2:59 AM, Alan Maguire wrote: >> >> [...] >> >> Great; so let's do this to land the series. Could you either >> >> - check I merged your patches correctly in the above branch, and if they >> look good I'll merge them into next and I'll officially send the feature >> check patch; or if you'd prefer >> - send a v5 (perhaps including my feature check patch?) >> >> ...whichever approach is easiest for you. > > Hi Alan. > > I reviewed the diff between your branch: > https://web.git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next.attributes-v4 > > and v1.29 + my patchset: > https://github.com/theihor/dwarves/tree/v4.kf-arena > > Not a lot of difference besides your patch. > Didn't spot any problems. > > I also ran a couple of tests on your branch: > * generate BTF with and without --btf_feature=attributes > * run ./tests/tests on 6.14-rc3 vmlinux (just a build I had at hand) > > I think you can apply patches from next.attributes-v4 as is. > > Thank you. > will do; can I add your Acked-by to the feature check patch? Thanks! Alan
On 3/27/25 1:22 AM, Alan Maguire wrote: > On 26/03/2025 17:41, Ihor Solodrai wrote: >> On 3/25/25 2:59 AM, Alan Maguire wrote: >>> >>> [...] >>> >>> Great; so let's do this to land the series. Could you either >>> >>> - check I merged your patches correctly in the above branch, and if they >>> look good I'll merge them into next and I'll officially send the feature >>> check patch; or if you'd prefer >>> - send a v5 (perhaps including my feature check patch?) >>> >>> ...whichever approach is easiest for you. >> >> Hi Alan. >> >> I reviewed the diff between your branch: >> https://web.git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next.attributes-v4 >> >> and v1.29 + my patchset: >> https://github.com/theihor/dwarves/tree/v4.kf-arena >> >> Not a lot of difference besides your patch. >> Didn't spot any problems. >> >> I also ran a couple of tests on your branch: >> * generate BTF with and without --btf_feature=attributes >> * run ./tests/tests on 6.14-rc3 vmlinux (just a build I had at hand) >> >> I think you can apply patches from next.attributes-v4 as is. >> >> Thank you. >> > > will do; can I add your Acked-by to the feature check patch? Thanks! I left an Acked-by here: https://lore.kernel.org/dwarves/68a594e38c00ff3dd30d0a13fb1e1de71f19954c@linux.dev/ > > Alan
On 27/03/2025 15:33, Ihor Solodrai wrote: > On 3/27/25 1:22 AM, Alan Maguire wrote: >> On 26/03/2025 17:41, Ihor Solodrai wrote: >>> On 3/25/25 2:59 AM, Alan Maguire wrote: >>>> >>>> [...] >>>> >>>> Great; so let's do this to land the series. Could you either >>>> >>>> - check I merged your patches correctly in the above branch, and if they >>>> look good I'll merge them into next and I'll officially send the feature >>>> check patch; or if you'd prefer >>>> - send a v5 (perhaps including my feature check patch?) >>>> >>>> ...whichever approach is easiest for you. >>> >>> Hi Alan. >>> >>> I reviewed the diff between your branch: >>> https://web.git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next.attributes-v4 >>> >>> and v1.29 + my patchset: >>> https://github.com/theihor/dwarves/tree/v4.kf-arena >>> >>> Not a lot of difference besides your patch. >>> Didn't spot any problems. >>> >>> I also ran a couple of tests on your branch: >>> * generate BTF with and without --btf_feature=attributes >>> * run ./tests/tests on 6.14-rc3 vmlinux (just a build I had at hand) >>> >>> I think you can apply patches from next.attributes-v4 as is. >>> >>> Thank you. >>> >> >> will do; can I add your Acked-by to the feature check patch? Thanks! > > I left an Acked-by here: > https://lore.kernel.org/dwarves/68a594e38c00ff3dd30d0a13fb1e1de71f19954c@linux.dev/ > series applied to next branch at https://git.kernel.org/pub/scm/devel/pahole/pahole.git , thanks! Alan >> >> Alan