lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 5 Oct 2021 20:09:35 -0400
From:   Steven Rostedt <>
To:     "Gustavo A. R. Silva" <>
Cc:     Ingo Molnar <>,
        Daniel Bristot de Oliveira <>,, Jann Horn <>
Subject: Re: [PATCH][next] ftrace: Fix -Wcast-function-type warnings on

On Tue, 5 Oct 2021 14:35:57 -0500
"Gustavo A. R. Silva" <> wrote:

> On Tue, Oct 05, 2021 at 03:08:07PM -0400, Steven Rostedt wrote:
> [..]
> > Or did you not remove your patch first?  
> Yep; that was the problem. 
> I now applied it to a clean tree and the warnings went away.
> However, I'm a bit concerned about the following Jann's comments:

I should have replied back then, but I'll do that now (and added Jann
to the CC) 

> "the real issue here is that ftrace_func_t is defined as a fixed
> type, but actually has different types depending on the architecture?
> If so, it might be cleaner to define ftrace_func_t differently
> depending on architecture, or something like that?"[1]

It's not dependent on the architecture. It's dependent on what the
architecture has implemented. There's nothing limiting the arch to use
the normal method, except that nobody implemented the updates.

As I changed the core API, it affected the architectures, and since I
don't know how to update all the architectures that use that API, and
do not have the hardware to test it, I made it so architectures can
slowly be updated when their maintainers get time to. This was years
ago, and not much has been done.

> "Would it not be possible to have two function types (#define'd as the
> same if ARCH_SUPPORTS_FTRACE_OPS), and then ensure that ftrace_func_t
> is only used as ftrace_asm_func_t if ARCH_SUPPORTS_FTRACE_OPS?"[2]
> "Essentially my idea here is to take the high-level rule "you can only
> directly call ftrace_func_t-typed functions from assembly if
> ARCH_SUPPORTS_FTRACE_OPS", and encode it in the type system. And then
> the compiler won't complain as long as we make sure that we never cast
> between the two types under ARCH_SUPPORTS_FTRACE_OPS==0."[3]
> So, is this linker approach really a good solution to this problem? :)
> What's the main problem with what Jann suggests?

The main issue is I want no more #ifdef's in the main code. There's too
many already and it makes it difficult to maintain. I want to get rid
of them, not add more. So anything that adds more #ifdef's to the main
code, I will NACK.

Which I guess leaves us with either the linker trick, or having all
the archs get updated to support the latest ftrace features, and we can
remove the current #ifdefs.

-- Steve

> Thanks!
> --
> Gustavo
> [1]
> [2]
> [3]

Powered by blists - more mailing lists