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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7139C433E5 for ; Fri, 24 Jul 2020 00:47:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 681A0206E3 for ; Fri, 24 Jul 2020 00:47:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="MfMPxvMD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 681A0206E3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E9DE96B002B; Thu, 23 Jul 2020 20:47:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E4DC86B002C; Thu, 23 Jul 2020 20:47:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3D3F6B002D; Thu, 23 Jul 2020 20:47:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id BE7266B002B for ; Thu, 23 Jul 2020 20:47:22 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 546BE3637 for ; Fri, 24 Jul 2020 00:47:22 +0000 (UTC) X-FDA: 77071130724.27.skirt74_0d032e526f43 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 528181A9F8 for ; Fri, 24 Jul 2020 00:47:19 +0000 (UTC) X-HE-Tag: skirt74_0d032e526f43 X-Filterd-Recvd-Size: 6120 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Jul 2020 00:47:18 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id h19so8249629ljg.13 for ; Thu, 23 Jul 2020 17:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mUaZ6oEhaxK6LHHxjQm2OcsjcreLEUTmrsVj8KinfEw=; b=MfMPxvMDiUBBcl90gFozRhD46ePBTnsGsvmrHjsEBskvGVqG0I3gH9nIf1ESYZxS07 Sl1DHyZskPVvE8LErPPfUDDDcK+05p7FEM34h0GGpTgr217o11tHoE+fl0bCOD0HqzEx RW0W/ERJnL1Dv/2rmNvi0o5hhSw3jqX/7J/oU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mUaZ6oEhaxK6LHHxjQm2OcsjcreLEUTmrsVj8KinfEw=; b=OjvJHwPOD/0lS6G3UrvOx8d7pmwnSGqmXg4GrIuJN2ZlQ7Ad6M4mKDZyPpI5iX2ISH SAV/xNVZ52Ymx6h8Ol3U8wdJo2llrWkc5i9p1eYYFHPYdZc/L/mlzpHuOYek2CXbwH+N QYvTU1i0bVCFGmYn3YhFUHq1/yZO7k/SlWBYgK+9huXTkBCjO3M07qolecZuKSEC/kHZ 7HeP7zeItAgc1DBNfiJ059kbKpIwq18iKtMW9lMZQlSf/Kw/Pcp1+NRQRbiK8IxzLZUL 9WccvCMNhWGU3jUwOO+CRkIx7xBMeK+Kqmy9Ydc8nQ7/v1+h5/XEqgwOvk6iitLrN/1B RSKw== X-Gm-Message-State: AOAM533LdBmhHBQzEjFPq4yPzYpD2Tfo3rEqw4FpOknvj4S95NwrFeF6 BTMbitqg9paTGOXt8GzbPTxfA8MxeKM= X-Google-Smtp-Source: ABdhPJzj9WFMle4mW0Q/OaORLv3v2BjwawLSFuM3CXpkkMTL+ea6owdZJ9YTYMAvq9s0t9TT/wRQOg== X-Received: by 2002:a2e:9b8c:: with SMTP id z12mr3181674lji.35.1595551636723; Thu, 23 Jul 2020 17:47:16 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id l4sm3278510ljc.83.2020.07.23.17.47.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2020 17:47:15 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id i19so4284144lfj.8 for ; Thu, 23 Jul 2020 17:47:15 -0700 (PDT) X-Received: by 2002:ac2:58d5:: with SMTP id u21mr3512335lfo.31.1595551635182; Thu, 23 Jul 2020 17:47:15 -0700 (PDT) MIME-Version: 1.0 References: <20200721063258.17140-1-mhocko@kernel.org> <20200723124749.GA7428@redhat.com> In-Reply-To: From: Linus Torvalds Date: Thu, 23 Jul 2020 17:46:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] mm: silence soft lockups from unlock_page To: Hugh Dickins Cc: Oleg Nesterov , Michal Hocko , Linux-MM , LKML , Andrew Morton , Tim Chen , Michal Hocko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 528181A9F8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 23, 2020 at 5:07 PM Hugh Dickins wrote: > > I say that for full disclosure, so you don't wrack your brains > too much, when it may still turn out to be a screwup on my part. Sounds unlikely. If that patch applied even reasonably closely, I don't see how you'd see a list corruption that wasn't due to the patch. You'd have had to use the wrong spinlock by mistake due to munging it, or something crazy like that. The main list-handling change is (a) open-coding of that finish_wait() (b) slightly different heuristics for removal in the wakeup function where (a) was because my original version of finishing the wait needed to do that return code checking. So a normal "finish_wait()" just does list_del_init(&wait->entry); where-as my open-coded one replaced that with if (!list_empty(&wait->entry)) { list_del(&wait->entry); ret = -EINTR; } and apart from that "set return to -EINTR because nobody woke us up", it also uses just a regular "list_del()" rather than a "list_del_init()". That causes the next/prev field to be poisoned rather than re-initialized. But that second change was because the list entry is on the stack, and we're not touching it any more and are about to return, so I removed the "init" part. Anyway, (a) really looks harmless. Unless the poisoning now triggers some racy debug test that had been hidden by the "init". Hmm. In contrast, (b) means that the likely access patterns of irqs removing the wait entry from the list might be very different from before. The old "autoremove" semantics would only remove the entry from the list when try_to_wake_up() actually woke things up. Now, a successful bit state _always_ removes it, which was kind of the point. But it might cause very different list handling patterns. All the actual list handling looks "obviously safe" because it's protected by the spinlock, though... If you do get oopses with the new patch too, try to send me a copy, and maybe I'll stare at exactly where it happens register contents and go "aah". Linus