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: <20120602213728.GO30000@ZenIV.linux.org.uk>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ