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 0A651C636D3 for ; Thu, 9 Feb 2023 18:46:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229766AbjBISqv (ORCPT ); Thu, 9 Feb 2023 13:46:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229501AbjBISqt (ORCPT ); Thu, 9 Feb 2023 13:46:49 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F8024216; Thu, 9 Feb 2023 10:46:48 -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 ams.source.kernel.org (Postfix) with ESMTPS id D1A89B822BF; Thu, 9 Feb 2023 18:46:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 531B1C433D2; Thu, 9 Feb 2023 18:46:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675968405; bh=NA3iBMWRcwiWdDAwavupXMF3yWhQzTQj/BEcxQTPM/Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gEBA8p5f1drrwalcpKiwz5P6rKDdKFoNX8y+rW0INdsnt8ucIy+YhSmp5RCVU9ZHV 452qi9hbX0cxpvblbJ7sg/ihkJkUNKZ3z2vez8Et2PUXeiCB9TPVO6cDBnoZ8nx4By rJo3QmhTOXh6HPbtQglP6pTkfKjAPZX9k8xdWdGB7kmUbWmDVQDE12HGT2tzUPgJ8B S1ISc1VTJHedYKKI1IBXcfHEjIL9tRa748yllU+ywDbebz737Rd8PNWkPj/nE38DaT SBJXGE9F7crNYXg80bBD4yb9ABdb+vI1OJqyCCpPf/Nc5BvZUvA31pE3KZn8s9KO3x fwDJJqM/SV4oA== Date: Thu, 9 Feb 2023 18:46:43 +0000 From: Eric Biggers To: Suren Baghdasaryan Cc: Munehisa Kamata , hannes@cmpxchg.org, hdanton@sina.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mengcc@amazon.com, stable@vger.kernel.org Subject: Re: [PATCH] sched/psi: fix use-after-free in ep_remove_wait_queue() Message-ID: References: <20230202030023.1847084-1-kamatam@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 09, 2023 at 09:09:03AM -0800, Suren Baghdasaryan wrote: > On Thu, Feb 2, 2023 at 1:11 PM Suren Baghdasaryan wrote: > > > > On Wed, Feb 1, 2023 at 8:56 PM Eric Biggers wrote: > > > > > > On Wed, Feb 01, 2023 at 07:00:23PM -0800, Munehisa Kamata wrote: > > > > diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c > > > > index 8ac8b81bfee6..6e66c15f6450 100644 > > > > --- a/kernel/sched/psi.c > > > > +++ b/kernel/sched/psi.c > > > > @@ -1343,10 +1343,11 @@ void psi_trigger_destroy(struct psi_trigger *t) > > > > > > > > group = t->group; > > > > /* > > > > - * Wakeup waiters to stop polling. Can happen if cgroup is deleted > > > > - * from under a polling process. > > > > + * Wakeup waiters to stop polling and clear the queue to prevent it from > > > > + * being accessed later. Can happen if cgroup is deleted from under a > > > > + * polling process otherwise. > > > > */ > > > > - wake_up_interruptible(&t->event_wait); > > > > + wake_up_pollfree(&t->event_wait); > > > > > > > > mutex_lock(&group->trigger_lock); > > > > > > wake_up_pollfree() should only be used in extremely rare cases. Why can't the > > > lifetime of the waitqueue be fixed instead? > > > > waitqueue lifetime in this case is linked to cgroup_file_release(), > > which seems appropriate to me here. Unfortunately > > cgroup_file_release() is not directly linked to the file's lifetime. > > For more details see: > > https://lore.kernel.org/all/CAJuCfpFZ3B4530TgsSHqp5F_gwfrDujwRYewKReJru==MdEHQg@mail.gmail.com/#t > > . > > So, if we want to fix the lifetime of the waitqueue, we would have to > > tie cgroup_file_release() to the fput() somehow. IOW, the fix would > > have to be done at the cgroups or higher (kernfs?) layer. > > Hi Eric, > Do you still object to using wake_up_pollfree() for this case? > Changing higher levels to make cgroup_file_release() be tied to fput() > would be ideal but I think that would be a big change for this one > case. If you agree I'll Ack this patch. > Thanks, > Suren. > I haven't read the code closely in this case. I'm just letting you know that wake_up_pollfree() is very much a last-resort option for when the waitqueue lifetime can't be fixed. So if you want to use wake_up_pollfree(), you need to explain why no other fix is possible. For example maybe the UAPI depends on the waitqueue having a nonstandard lifetime. - Eric