linux-kernel - Re: [PATCH 2/5] h8300/signal: Fix typo "statis"

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]

Date:	Sat, 2 Jun 2012 22:37:28 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Yoshinori Sato <ysato@...rs.sourceforge.jp>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tony Breeds <tony@...eyournoodle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] h8300/signal: Fix typo "statis"

On Sat, Jun 02, 2012 at 10:35:36PM +0200, Geert Uytterhoeven wrote:
> The keyword is "static", not "statis":
> 
> arch/h8300/kernel/signal.c:455:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
> arch/h8300/kernel/signal.c: In function 'do_notify_resume':
> arch/h8300/kernel/signal.c:511:3: error: implicit declaration of function 'do_signal' [-Werror=implicit-function-declaration]
> arch/h8300/kernel/signal.c: At top level:
> arch/h8300/kernel/signal.c:414:1: warning: 'handle_signal' defined but not used [-Wunused-function]
> 
> Introduced in commit 7ae4e32a65148353db3458e3eb87117f25620ac5 ("h8300: switch
> to saved_sigmask-based sigsuspend/rt_sigsuspend")

Sigh...  This one I don't even have a cross-toolchain for (ICEs galore),
nevermind the setup to test on ;-/

FWIW, there's a potential unpleasant bug in h8300 signal handling -
the check for return to user mode is in the wrong place; doing that
in do_signal() is pointless, since if you ever get there with both
TIF_SIGPENDING set and regs such that we are about to return to kernel,
you'll just keep looping.

That check belongs in the loop in entry.S, if anywhere (i.e. if that loop
can be reached when returning to kernel mode; AFAICS, the only plausible
way for that to happen is failing kernel_execve() leaving us on the exit
from system_call, about to return to kernel).  It might or might not be
worth doing more or less what arm does in its kernel_execve(); then that
check could be simply removed.  In any case, do_signal() is definitely the
wrong place for that check - if anything, it needs to be done before hitting
do_notify_resume, breaking the loop if we are returning to kernel.
--
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/