linux-kernel - ftrace breaks sparc64 build

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-next>] [day] [month] [year] [list]

Message-ID: <20090105181922.GA25622@uranus.ravnborg.org>
Date:	Mon, 5 Jan 2009 19:19:22 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <srostedt@...hat.com>,
	Ingo Molnar <mingo@...e.hu>, rostedt@...dmis.org,
	"David S. Miller" <davem@...emloft.net>,
	sparclinux <sparclinux@...r.kernel.org>
Subject: ftrace breaks sparc64 build

With an allmodconfig build on sparc and sparc64 I started
to see warnings that become propagated to errors by -Werror.

Example:
  CC      arch/sparc/kernel/ldc.o
arch/sparc/kernel/ldc.c: In function `process_control_frame':
arch/sparc/kernel/ldc.c:627: warning: 'vap' might be used uninitialized in this function


The code in question looks like this:
static int process_ver_nack(struct ldc_channel *lp, struct ldc_version *vp)
{
        struct ldc_version *vap;

        if ((vp->major == 0 && vp->minor == 0) ||
            !(vap = find_by_major(vp->major))) {
                return ldc_abort(lp);
        } else {
                struct ldc_packet *p;
                unsigned long new_tail;

                p = handshake_compose_ctrl(lp, LDC_INFO, LDC_VERS,
                                           vap, sizeof(*vap),
                                           &new_tail);
                if (p)
                        return send_tx_packet(lp, p, new_tail);
                else
                        return ldc_abort(lp);
        }
}

The else part will never be executed whitout assigning vap,
and this code do not emit warnings in the normal case.
[I am well aware that we recommend to move the assignment
out of the if () - but this code worked as is before].

This code gets expanded to:

static int process_ver_nack(struct ldc_channel *lp, struct ldc_version *vp)
{
	struct ldc_version *vap;

	if (__builtin_constant_p(((vp->major == 0 && vp->minor == 0) || !(vap = find_by_major(vp->major)))) ? 
	!!((vp->major == 0 && vp->minor == 0) || !(vap = find_by_major(vp->major))) : 
	({
		int ______r;
		static struct ftrace_branch_data  ______f = { .func = __func__, .file = "arch/sparc/kernel/ldc.c", .line = 630, };
		______r = !!((vp->major == 0 && vp->minor == 0) || !(vap = find_by_major(vp->major)));
		if (______r)
			______f.hit++;
		else
			______f.miss++; ______r;
	})) {

		return ldc_abort(lp);
	} else {
		struct ldc_packet *p;
		unsigned long new_tail;

		p = handshake_compose_ctrl(lp, 0x01, 0x01, vap, sizeof(*vap), &new_tail);
		if (__builtin_constant_p((p)) ? !!(p) : ({
			int ______r;
			static struct ftrace_branch_data ______f = { .func = __func__, .file = "arch/sparc/kernel/ldc.c", .line = 639, };
			______r = !!(p);
			if (______r)
				______f.hit++;
			else ______f.miss++;
				______r;
		}))
	 		return send_tx_packet(lp, p, new_tail);
		else
			return ldc_abort(lp);
	}
}
I have inserted newlines + tabs and removed a few __attribute__()
to keep line lengths to a sensible level.

My head started to spin with a dangerous speed trying to figure out
the code snippet above.

On top of this some inlining occurs which is why gcc point at another
function name.


This is with following gcc version:

sparc64-unknown-linux-gnu-gcc (GCC) 3.4.5
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Build using crosstool.

Is this a known issue?

Any recommendations?

	Sam
--
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/