[tracing,0/3] tracing: support > 8 byte filter predicates

  For cases like IPv6 addresses, having a means to supply tracing
predicates for fields with more than 8 bytes would be convenient.
This series provides a simple way to support this by allowing
simple ==, != memory comparison with the predicate supplied when
the size of the field exceeds 8 bytes.  For example, to trace
::1, the predicate

	"dst == 0x00000000000000000000000000000001"

..could be used.

Patch 1 provides the support for > 8 byte fields via a memcmp()-style
predicate.  Patch 2 adds tests for filter predicates, and patch 3
documents the fact that for > 8 bytes. only == and != are supported.

Changes since RFC [1]:

- originally a fix was intermixed with the new functionality as
  patch 1 in series [1]; the fix landed separately
- small tweaks to how filter predicates are defined via fn_num as
  opposed to via fn directly

[1] https://lore.kernel.org/lkml/1659910883-18223-1-git-send-email-alan.maguire@oracle.com/

Alan Maguire (3):
  tracing: support > 8 byte array filter predicates
  selftests/ftrace: add test coverage for filter predicates
  tracing: document > 8 byte numeric filtering support

 Documentation/trace/events.rst                |  9 +++
 kernel/trace/trace_events_filter.c            | 55 +++++++++++++++-
 .../selftests/ftrace/test.d/event/filter.tc   | 62 +++++++++++++++++++
 3 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/ftrace/test.d/event/filter.tc
  

On Tue, 25 Apr 2023 10:16:34 +0100
Alan Maguire <alan.maguire@oracle.com> wrote:

> For cases like IPv6 addresses, having a means to supply tracing
> predicates for fields with more than 8 bytes would be convenient.
> This series provides a simple way to support this by allowing
> simple ==, != memory comparison with the predicate supplied when
> the size of the field exceeds 8 bytes.  For example, to trace
> ::1, the predicate
> 
> 	"dst == 0x00000000000000000000000000000001"
> 
> ..could be used.

Nice!
And I also would like to use something like "dst == ipv6(::1)" because
it seems easy to make a mistake on the number of zeros.

Can we add such type casting feature to the filter?

Thank you,

> 
> Patch 1 provides the support for > 8 byte fields via a memcmp()-style
> predicate. Patch 2 adds tests for filter predicates, and patch 3
> documents the fact that for > 8 bytes. only == and != are supported.
> 
> Changes since RFC [1]:
> 
> - originally a fix was intermixed with the new functionality as
>   patch 1 in series [1]; the fix landed separately
> - small tweaks to how filter predicates are defined via fn_num as
>   opposed to via fn directly
> 
> [1] https://lore.kernel.org/lkml/1659910883-18223-1-git-send-email-alan.maguire@oracle.com/
> 
> Alan Maguire (3):
>   tracing: support > 8 byte array filter predicates
>   selftests/ftrace: add test coverage for filter predicates
>   tracing: document > 8 byte numeric filtering support
> 
>  Documentation/trace/events.rst                |  9 +++
>  kernel/trace/trace_events_filter.c            | 55 +++++++++++++++-
>  .../selftests/ftrace/test.d/event/filter.tc   | 62 +++++++++++++++++++
>  3 files changed, 125 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/ftrace/test.d/event/filter.tc
> 
> -- 
> 2.31.1
>
  

On 25/04/2023 15:32, Masami Hiramatsu (Google) wrote:
> On Tue, 25 Apr 2023 10:16:34 +0100
> Alan Maguire <alan.maguire@oracle.com> wrote:
> 
>> For cases like IPv6 addresses, having a means to supply tracing
>> predicates for fields with more than 8 bytes would be convenient.
>> This series provides a simple way to support this by allowing
>> simple ==, != memory comparison with the predicate supplied when
>> the size of the field exceeds 8 bytes.  For example, to trace
>> ::1, the predicate
>>
>> 	"dst == 0x00000000000000000000000000000001"
>>
>> ..could be used.
> 
> Nice!
> And I also would like to use something like "dst == ipv6(::1)" because
> it seems easy to make a mistake on the number of zeros.
> 
> Can we add such type casting feature to the filter?
>

that's a great idea; what would be the most consistent ftrace syntax
for this do you think? I noticed that hist triggers append a modifier
to the field name so would something like

"dst.ipv6 == ::1"

make sense maybe? Thanks!

Alan

 
> Thank you,
> 
>>
>> Patch 1 provides the support for > 8 byte fields via a memcmp()-style
>> predicate. Patch 2 adds tests for filter predicates, and patch 3
>> documents the fact that for > 8 bytes. only == and != are supported.
>>
>> Changes since RFC [1]:
>>
>> - originally a fix was intermixed with the new functionality as
>>   patch 1 in series [1]; the fix landed separately
>> - small tweaks to how filter predicates are defined via fn_num as
>>   opposed to via fn directly
>>
>> [1] https://lore.kernel.org/lkml/1659910883-18223-1-git-send-email-alan.maguire@oracle.com/
>>
>> Alan Maguire (3):
>>   tracing: support > 8 byte array filter predicates
>>   selftests/ftrace: add test coverage for filter predicates
>>   tracing: document > 8 byte numeric filtering support
>>
>>  Documentation/trace/events.rst                |  9 +++
>>  kernel/trace/trace_events_filter.c            | 55 +++++++++++++++-
>>  .../selftests/ftrace/test.d/event/filter.tc   | 62 +++++++++++++++++++
>>  3 files changed, 125 insertions(+), 1 deletion(-)
>>  create mode 100644 tools/testing/selftests/ftrace/test.d/event/filter.tc
>>
>> -- 
>> 2.31.1
>>
> 
>
  

On Tue, 25 Apr 2023 18:15:03 +0100
Alan Maguire <alan.maguire@oracle.com> wrote:

> that's a great idea; what would be the most consistent ftrace syntax
> for this do you think? I noticed that hist triggers append a modifier
> to the field name so would something like
> 
> "dst.ipv6 == ::1"

Yeah, I think just having ":" in the name without quotes can help the filter
know that it's a ipv6 id.

Hmm, although we may want to do the same for mac addresses. But we can
determine the difference by the field size. If it's 6 bytes, it's a mac, if
it's 128 bits, then ipv6.

-- Steve
  

On 25/04/2023 18:20, Steven Rostedt wrote:
> On Tue, 25 Apr 2023 18:15:03 +0100
> Alan Maguire <alan.maguire@oracle.com> wrote:
> 
>> that's a great idea; what would be the most consistent ftrace syntax
>> for this do you think? I noticed that hist triggers append a modifier
>> to the field name so would something like
>>
>> "dst.ipv6 == ::1"
> 
> Yeah, I think just having ":" in the name without quotes can help the filter
> know that it's a ipv6 id.
> 
> Hmm, although we may want to do the same for mac addresses. But we can
> determine the difference by the field size. If it's 6 bytes, it's a mac, if
> it's 128 bits, then ipv6.
>

good idea! so what about the following

- 16 byte field with ':'; convert from IPv6 address before memcmp()ing
- 6 byte field with ':'; convert from MAC address before memcmp()ing
- 4 byte field with '.'; convert from IPv4 address before memcmp()ing
- 0x prefix, any other size; basic memcmp

? Thanks!

Alan
 
> -- Steve
>
  

On Wed, 26 Apr 2023 09:51:00 +0100
Alan Maguire <alan.maguire@oracle.com> wrote:

> - 16 byte field with ':'; convert from IPv6 address before memcmp()ing
> - 6 byte field with ':'; convert from MAC address before memcmp()ing
> - 4 byte field with '.'; convert from IPv4 address before memcmp()ing
> - 0x prefix, any other size; basic memcmp

Sure.

-- Steve
  

On Wed, 26 Apr 2023 09:51:00 +0100
Alan Maguire <alan.maguire@oracle.com> wrote:

> On 25/04/2023 18:20, Steven Rostedt wrote:
> > On Tue, 25 Apr 2023 18:15:03 +0100
> > Alan Maguire <alan.maguire@oracle.com> wrote:
> > 
> >> that's a great idea; what would be the most consistent ftrace syntax
> >> for this do you think? I noticed that hist triggers append a modifier
> >> to the field name so would something like
> >>
> >> "dst.ipv6 == ::1"
> > 
> > Yeah, I think just having ":" in the name without quotes can help the filter
> > know that it's a ipv6 id.
> > 
> > Hmm, although we may want to do the same for mac addresses. But we can
> > determine the difference by the field size. If it's 6 bytes, it's a mac, if
> > it's 128 bits, then ipv6.
> >
> 
> good idea! so what about the following
> 
> - 16 byte field with ':'; convert from IPv6 address before memcmp()ing
> - 6 byte field with ':'; convert from MAC address before memcmp()ing
> - 4 byte field with '.'; convert from IPv4 address before memcmp()ing
> - 0x prefix, any other size; basic memcmp

This looks good to me :)

Thanks!

> 
> ? Thanks!
> 
> Alan
>  
> > -- Steve
> >