Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754761AbbEUKcO (ORCPT ); Thu, 21 May 2015 06:32:14 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:35798 "EHLO mail-wg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753081AbbEUKcL (ORCPT ); Thu, 21 May 2015 06:32:11 -0400 MIME-Version: 1.0 In-Reply-To: <20150521060348.GA5615@gmail.com> References: <670017389.505251432184399737.JavaMail.weblogic@ep2mlwas07b> <20150521060348.GA5615@gmail.com> Date: Thu, 21 May 2015 12:32:10 +0200 Message-ID: Subject: Re: [EDT][PATCH] kernel/exit.c : Fix missing read_unlock From: Frans Klaver To: Ingo Molnar Cc: Maninder Singh , Andrew Morton , oleg@redhat.com, Michal Hocko , Peter Zijlstra , Rik van Riel , ionut.m.alexa@gmail.com, Peter Hurley , "linux-kernel@vger.kernel.org" , "v.narang@samsung.com" , AKHILESH KUMAR , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2026 Lines: 61 On Thu, May 21, 2015 at 8:03 AM, Ingo Molnar wrote: > > * Maninder Singh wrote: > >> EP-F6AA0618C49C4AEDA73BFF1B39950BAB >> Hi, >> >> From: Maninder Singh >> >> Subject: [PATCH 1/1] kernel/exit.c : Fix missing task_unlock >> >> This patch adds missing read_unlock if do_wait_thread or ptrace_do_wait >> returns non zero. >> >> Signed-off-by: Maninder Singh >> Signed-off-by: Vaneet Narang >> Reviewd-by: Akhilesh Kumar >> --- >> kernel/exit.c | 8 ++++++-- >> 1 files changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/exit.c b/kernel/exit.c >> index 22fcc05..31a061f 100644 >> --- a/kernel/exit.c >> +++ b/kernel/exit.c >> @@ -1486,12 +1486,16 @@ repeat: >> tsk = current; >> do { >> retval = do_wait_thread(wo, tsk); >> - if (retval) >> + if (retval) { >> + read_unlock(&tasklist_lock); >> goto end; >> + } >> >> retval = ptrace_do_wait(wo, tsk); >> - if (retval) >> + if (retval) { >> + read_unlock(&tasklist_lock); >> goto end; >> + } >> >> if (wo->wo_flags & __WNOTHREAD) >> break; > > That's surprising Still it looks like it is a legitimate change. I don't see where the unlock would be done otherwise. I do wonder if this would look nicer if the whole locked part would be pulled out into a separate (inline) function. That would render the repeated read_unlock()s unnecessary and possibly also prevent a goto/label mess if that were to be attempted in-line. Frans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/