linux-kernel - Re: [PATCH 2/3] ptrace_untrace: use wake_up_process() instead of bogus signal_wake

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: <20090209034255.E95A7FC330@magilla.sf.frob.com>
Date:	Sun,  8 Feb 2009 19:42:55 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jerome Marchand <jmarchan@...hat.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] ptrace_untrace: use wake_up_process() instead of
	bogus signal_wake_up()

> We are holding ->siglock, and task->state is TASK_TRACED. We can not do
> the "wrong" wakeup, afaics.

I guess that's true with the siglock.  But you'd be wrong to think that
this sort of detailed thinking is why wake_up_process() appears *anywhere
at all* in ptrace-related code.  I'm really quite sure that it's the
aforementioned (ancient) lack of detailed thinking about it that led to
wake_up_process() appearing originally--so any use of it reminds us of that
dubious past.

> Because it complicates the understanding of this code. I spent a lot
> of time trying to understand this signal_wake_up().
> 
> Perhaps this is just me. But when you see the code which does something,
> it is always good to understand the reason, otherwise the code at least
> looks wrong.

I had presumed most people interpret it the way I do: it does
signal_wake_up(,1), meaning "whatever it is that works right for SIGKILL or
SIGCONT", which it seems intuitive to think is right for this case too.
You don't have to think about exactly what is always exactly right for this
case, because it makes sense to think that this is like the wakeup that
SIGCONT would do.  To me, it takes much more thought to be convinced that
wake_up_process() without other considerations is correct here--because it
looks like such a scary, unconditional thing, whereas normally that is
wrapped up inside calls that handle appropriate bookkeeping--signal_wake_up()
being one of those.

Thanks,
Roland
--
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/