From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A0EBC433FE for ; Wed, 9 Nov 2022 12:09:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229751AbiKIMJP (ORCPT ); Wed, 9 Nov 2022 07:09:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229518AbiKIMJN (ORCPT ); Wed, 9 Nov 2022 07:09:13 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8918B10FC0 for ; Wed, 9 Nov 2022 04:09:12 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 24DE861A51 for ; Wed, 9 Nov 2022 12:09:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D66AEC433D6; Wed, 9 Nov 2022 12:09:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1667995751; bh=I1TqxwsgYjSqK2MI2Hxtj+/lmCs/5QlrHAeZidaInuc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DJZoCFvf6eEQ37NOS5FkpCwseBOpl2S32vQC/ITSzhKm++1p9T7KxB2G+MeX+LtS5 jo5Dlb7Cl4Lb/L6OaHWkBvEIeuohesLVve46qjaqu+mCd50r1x7Bven5n8OMHT/ZcU i/3KN6t3Rsd2//5HWQr3atfHxW/lqm50XhSdsgY0= Date: Wed, 9 Nov 2022 13:09:08 +0100 From: Greg KH To: Zheng Hacker Cc: Zheng Wang , zhengyejian1@huawei.com, dimitri.sivanich@hpe.com, arnd@arndb.de, linux-kernel@vger.kernel.org, alex000young@gmail.com, security@kernel.org, sivanich@hpe.com, lkp@intel.com Subject: Re: [PATCH v8] misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os Message-ID: References: <20221109105158.230081-1-zyytlz.wz@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 09, 2022 at 08:04:04PM +0800, Zheng Hacker wrote: > Greg KH 于2022年11月9日周三 19:12写道： > > > /* > > > * If the current task is the context owner, verify that the > > > @@ -727,14 +728,16 @@ void gru_check_context_placement(struct gru_thread_state *gts) > > > */ > > > gru = gts->ts_gru; > > > if (!gru || gts->ts_tgid_owner != current->tgid) > > > - return; > > > + return ret; > > > > Why does this check return "all is good!" ? > > > > Shouldn't that be an error? > > > This check is something like "if the gts has been initiiazed properly". > If it's not, I thinks we shouldn't treat the gts like something very > bad happend. Because in the later request, the gts can still have a > chance to be configed/updated properly. This is different from "it's > too bad so we have to unload gts right now". This is just my personal > point of view. Besides, the caller of this function have token it into > consider. In gru_fault, it will try again and in gru_handle_user_call_os, > it will return -EAGAIN. In gru_set_context_option, it will be fine > because there won't be any operation on gts->ts_gru or gts->ts_tgid_owner Then you need to document it why this is "success" as it is not obvious at all. thanks, greg k-h