linux-kernel - Re: [PATCH] ppc64 ftrace: mark data

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <alpine.LNX.2.00.1505191150420.8186@pobox.suse.cz>
Date:	Tue, 19 May 2015 11:52:47 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Michael Ellerman <mpe@...erman.id.au>
cc:	Torsten Duwe <duwe@....de>,
	ppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ppc64 ftrace: mark data_access callees "notrace"
 (pt.1)

On Tue, 19 May 2015, Michael Ellerman wrote:

> > ftrace already handles recursion protection by itself (depending on the 
> > per-ftrace-ops FTRACE_OPS_FL_RECURSION_SAFE flag).
> 
> OK, so I wonder why that's not working for us?

The situation when traced function recurses to itself is different from 
the situation when tracing core infrastrcuture would recurse to itself 
while performing tracing.

> > It's however not really well-defined what to do when recursion would 
> > happen. Therefore __notrace__ annotation, that just completely avoid such 
> > situation by making tracing impossible, looks like saner general solution 
> > to me.
> 
> I disagree. Correctly annotating all functions that might be called ever and
> for all time is a maintenance nightmare and is never going to work in the long
> term.

All the functions called by ftrace must be marked as notrace, there is no 
way out of it.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/