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 59100C7EE23 for ; Wed, 31 May 2023 22:16:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231126AbjEaWQS (ORCPT ); Wed, 31 May 2023 18:16:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231175AbjEaWQH (ORCPT ); Wed, 31 May 2023 18:16:07 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 525C2E45 for ; Wed, 31 May 2023 15:15:45 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1ae64580e9fso24345ad.1 for ; Wed, 31 May 2023 15:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685571343; x=1688163343; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=C69/HgDQcYHZzBDl4mqXS6yFcUMrvhBV+XsyYfCeFy4=; b=avojlsc996gGnZc9DZwhWPrvUhBeM5Ph8gNSA8jcDuKN2emMUuWsHnU64lv54HzvW1 gk6Wiy/Gzo6kgMr7K5QQNsEvMkacDXf2sAq/hr/kXiDcBe5L+W24usb8vJEl3eouOszC dwWJzkYg9zPXF2m/+jsTwydw/xtxLXhHqz9MAGF8SyKIJnM5LaBgqpOdsGhxqG1SGl0V oU66ytUYcUTWLe2l3lfrG7+oADifxqKM2mo/sZgsogoDIgyX34io8uFbt8rOh9stuV8a pupW/pRMsonx5qViaZUfcJwVB0ydPW8XE0BHrd4SS80BzTaNWrKGuPKW46p2Y8suyrNZ ilMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685571343; x=1688163343; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=C69/HgDQcYHZzBDl4mqXS6yFcUMrvhBV+XsyYfCeFy4=; b=jaX9IP3SKyaw7JRyht13W9WeTmDmToMA2ejBeCLz3E4wwXknkD2BbpwXQucPNvEPbx +cCP6DISf4DkKx78CRBn8NLLj+JrhocnhndX3OmnoD4q4HYSH/xOT7OXZyFmxBxQiQbw CVlhG6SrrmowFX2ecjTdsDmm13FPH/SS+MRsOE70Bp2Gx7mRTX60datfv9EeD2WM+RF8 IklCywlbXNVScPh69rt+0e7YZtSbbV5RNrkA/SpQLc9e6ywlV0K8YT5G9ZZIOzvxAX2v OUmk/en39qqYjtefsL4LH8r3GvwrpwjFsoojmpA5bfG9DMbSkGTenh7UCTHA+T78YNAL Epqg== X-Gm-Message-State: AC+VfDxh0f9R4VSkv9NHo2Bwh6I4HZpV5gV1fD5wNgyckmhSZk87M6xp JskyHrbzo/mmGk43+KurpiAJZg== X-Google-Smtp-Source: ACHHUZ7zAWHVLeCjO/NeIx9R8Cm5pi2tcHFmuvYnV9NvWdpLer08hYIMnMnuREKWaC6bxLVBoTsmCw== X-Received: by 2002:a17:902:f38c:b0:1a6:6a2d:18f0 with SMTP id f12-20020a170902f38c00b001a66a2d18f0mr19120ple.9.1685571342975; Wed, 31 May 2023 15:15:42 -0700 (PDT) Received: from bsegall-glaptop.localhost (c-73-158-249-138.hsd1.ca.comcast.net. [73.158.249.138]) by smtp.gmail.com with ESMTPSA id b1-20020a170902d50100b0019aaab3f9d7sm1910004plg.113.2023.05.31.15.15.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 May 2023 15:15:42 -0700 (PDT) From: Benjamin Segall To: Christian Brauner Cc: Eric Biggers , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Andrew Morton Subject: Re: [PATCH RESEND] epoll: ep_autoremove_wake_function should use list_del_init_careful References: <20230531015748.GB1648@quark.localdomain> <20230531-zupacken-laute-22564cd952f7@brauner> Date: Wed, 31 May 2023 15:15:41 -0700 In-Reply-To: <20230531-zupacken-laute-22564cd952f7@brauner> (Christian Brauner's message of "Wed, 31 May 2023 09:53:01 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Christian Brauner writes: > On Tue, May 30, 2023 at 06:57:48PM -0700, Eric Biggers wrote: >> On Tue, May 30, 2023 at 11:32:28AM -0700, Benjamin Segall wrote: >> > autoremove_wake_function uses list_del_init_careful, so should epoll's >> > more aggressive variant. It only doesn't because it was copied from an >> > older wait.c rather than the most recent. >> > >> > Fixes: a16ceb139610 ("epoll: autoremove wakers even more aggressively") >> > Signed-off-by: Ben Segall >> > Cc: stable@vger.kernel.org >> > --- >> > fs/eventpoll.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/fs/eventpoll.c b/fs/eventpoll.c >> > index 52954d4637b5..081df056398a 100644 >> > --- a/fs/eventpoll.c >> > +++ b/fs/eventpoll.c >> > @@ -1756,11 +1756,11 @@ static struct timespec64 *ep_timeout_to_timespec(struct timespec64 *to, long ms) >> > static int ep_autoremove_wake_function(struct wait_queue_entry *wq_entry, >> > unsigned int mode, int sync, void *key) >> > { >> > int ret = default_wake_function(wq_entry, mode, sync, key); >> > >> > - list_del_init(&wq_entry->entry); >> > + list_del_init_careful(&wq_entry->entry); >> > return ret; >> > } >> >> Can you please provide a more detailed explanation about why >> list_del_init_careful() is needed here? > > Yeah, this needs more explanation... Next time someone looks at this > code and there's a *_careful() added they'll want to know why. So the general reason is the same as with autoremove_wake_function, it pairs with the list_entry_careful in ep_poll (which is epoll's modified copy of finish_wait). I think the original actual _problem_ was a -stable issue that was fixed instead by doing additional backports, so this may just avoid potential extra loops and avoid potential compiler shenanigans from the data race.