lkml.org 
[lkml]   [2013]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] kernel/exit.c: call read_unlock() when failure occurs after already called read_lock() in do_wait().
On Sat, Oct 05, 2013 at 01:53:26PM +0800, Chen Gang wrote:
> If failure occurs after called read_lock(), need call read_unlock() too.
>
> It can fail in multiple position, so add new tag 'fail_lock' for it
> (also can let 'if' only content one jump statement).

You know, this is getting too frequent... You really need to do
something about it. OK, you've formed a hypothesis (in this case,
that ptrace_do_wait() returns non-zero with tasklist_lock still held).
If that hypothesis was correct, you would've found a bug and yes,
this patch would probably be more or less a fix for that bug.

Do you see what's missing? That's right, verifying that hypothesis.
Which isn't hard to do, either by slapping a printk into these
exits, or by trying to build a proof. As it is, hypothesis is
incorrect and your patch introduces breakage. The same would have
happened if _some_ exits from that function returned non-zero
values with tasklist_lock held and some returned non-zero values
with tasklist_lock released.

You really need to realize that pattern-matching is not enough - you
need to prove that your fix is correct and that requires an analysis
of what's there.

"I see something odd" is a good reason to ask or to try and figure out
what's going on. It's not a good reason for blindly making changes
like that - not until you've done the analysis and can at least show
that it won't _break_ things.


\
 
 \ /
  Last update: 2013-10-05 09:01    [W:0.061 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site