linux-kernel - Re: [PATCH 00/41] signal: Use set_current

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:	Wed, 17 Aug 2011 19:01:52 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/41] signal: Use set_current_blocked()

On 08/16, Matt Fleming wrote:
>
> Did you want me to send just the updated
> versions of patches or the entire series again? It would seem over the
> top to send the entire series.

This is up to you. Just in case, feel free to add my acked-by or
reviewed-by to any patch I didn't comment explicitly. Or may be

> Also, are you going to pull these patches into your tree and send them
> to Linus or would it be better to route them through -mm?

This is the question ;)

I simply do not know what should we do. I think this should be
routed via maintainers.

Or I can push this into the poor ptrace branch... but I am
thinking with horror about the possible conflicts in arch/ code...

What do you think?



Damn. And I can't relax. This is very minor, but I still think
it would be nice to have a common helper which plays sa_mask /
SA_NODEFER to set ->blocked. But in this case, you probably need
to resend the whole series ;)

I mean something like the patch below. OK, nevermind. Probably
this factorization doesn't buy too much, but it will complicate
the merging.

Oleg.

--- x/include/linux/signal.h
+++ x/include/linux/signal.h
@@ -254,6 +254,7 @@ extern void set_current_blocked(const si
 extern int show_unhandled_signals;
 
 extern int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka, struct pt_regs *regs, void *cookie);
+extern void xxx(struct k_sigaction *ka);
 extern void exit_signals(struct task_struct *tsk);
 
 extern struct kmem_cache *sighand_cachep;
--- x/kernel/signal.c
+++ x/kernel/signal.c
@@ -2314,6 +2314,16 @@ relock:
 	return signr;
 }
 
+void xxx(struct k_sigaction *ka)
+{
+	sigset_t blocked;
+
+	sigorsets(&blocked, &current->blocked, &ka->sa.sa_mask);
+	if (!(ka->sa.sa_flags & SA_NODEFER))
+		sigaddset(&blocked, sig);
+	set_current_blocked(&blocked);
+}
+
 /*
  * It could be that complete_signal() picked us to notify about the
  * group-wide signal. Other threads should be notified now to take
--- x/arch/x86/kernel/signal.c
+++ x/arch/x86/kernel/signal.c
@@ -682,7 +682,6 @@ static int
 handle_signal(unsigned long sig, siginfo_t *info, struct k_sigaction *ka,
 		struct pt_regs *regs)
 {
-	sigset_t blocked;
 	int ret;
 
 	/* Are we from a system call? */
@@ -733,14 +732,10 @@ handle_signal(unsigned long sig, siginfo
 	 */
 	regs->flags &= ~X86_EFLAGS_TF;
 
-	sigorsets(&blocked, &current->blocked, &ka->sa.sa_mask);
-	if (!(ka->sa.sa_flags & SA_NODEFER))
-		sigaddset(&blocked, sig);
-	set_current_blocked(&blocked);
+	xxx(ka);
 
 	tracehook_signal_handler(sig, info, ka, regs,
 				 test_thread_flag(TIF_SINGLESTEP));
-
 	return 0;
 }
 

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