linux-kernel - Re: [PATCH 0/1] (Was: [regression] boot failure on alpha, bisected)

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:	Sun, 14 Oct 2012 20:35:39 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	dl8bcu@...bcu.de, peterz@...radead.org, mingo@...nel.org,
	linux-kernel@...r.kernel.org, linux-alpha@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 0/1] (Was: [regression] boot failure on alpha, bisected)

On 10/12, Al Viro wrote:
>
> On Fri, Oct 12, 2012 at 06:03:37PM +0200, Oleg Nesterov wrote:
> > On 10/06, Thorsten Kranzkowski wrote:
> > >
> > > After upgrading from v3.5-rc7 to current git my system oopses and locks up
> > > early in the boot sequence.
> >
> > OK, I am sending the patch which I already showed.
> >
> > Perhaps we should only add the warning and local_irq_enable()
> > should go into arch/alpha/kernel/signal.c:do_notify_resume().
> >
> > In any case arch/alpha/ should be fixed imho.
>
> Oleg, could you check current signal.git#for-next?  alpha patches in
> there ought to deal with the do_notify_resume() mess on alpha
> for good, AFAICS.

Yes, thanks Al!

6972d6f25d21e3da58ff1309256c787078405c7f makes my patch unnecessary.
Although, as you pointed out, other architectures can have the same
problem so perhaps at least WARN_ONCE() in task_wrok_run() makes
sense.

But I am just curious,

	+do_work_pending(struct pt_regs *regs, struct switch_stack *sw,
	+		 unsigned long thread_flags,
			 unsigned long r0, unsigned long r19)
	 {
	-	if (thread_info_flags & _TIF_SIGPENDING)
	-		do_signal(regs, sw, r0, r19);
	-
	-	if (thread_info_flags & _TIF_NOTIFY_RESUME) {
	-		clear_thread_flag(TIF_NOTIFY_RESUME);
	-		tracehook_notify_resume(regs);
	-	}
	+	do {
	+		if (thread_flags & _TIF_NEED_RESCHED) {
	+			schedule();
	+		} else {
	+			local_irq_enable();

I think this is fine, schedule() can be called with irqs disabled.
And since this is ret-to-user path we can't have the problems with
sched_submit_work().

Still, any particular reason why this patch doesn't do irq_enable()
at the start of the loop?

	+			if (thread_flags & _TIF_SIGPENDING) {
	+				do_signal(regs, sw, r0, r19);
	+				r0 = 0;
	+			} else {
	+				clear_thread_flag(TIF_NOTIFY_RESUME);
	+				tracehook_notify_resume(regs);

Again, this is fine. But why "else" ? It seems that

			if (thread_flags & _TIF_SIGPENDING) {
				do_signal(regs, r0, r19);
				r0 = 0;
			}

			if (thread_flags & _TIF_NOTIFY_RESUME) {
				clear_thread_flag(TIF_NOTIFY_RESUME);
				tracehook_notify_resume(regs);
			}

makes a bit more sense?

Oleg.

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