From: Hugh Dickins <hughd@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Hugh Dickins <hughd@google.com>, Oleg Nesterov <oleg@redhat.com>,
Michal Hocko <mhocko@kernel.org>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tim Chen <tim.c.chen@linux.intel.com>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [RFC PATCH] mm: silence soft lockups from unlock_page
Date: Sun, 26 Jul 2020 15:09:44 -0700 (PDT) [thread overview]
Message-ID: <alpine.LSU.2.11.2007261454110.7444@eggly.anvils> (raw)
In-Reply-To: <CAHk-=wg+7Wk7BLmLiDkoNDBvMfoooDVEaLimDY+10Jr9jLKLZg@mail.gmail.com>
On Sun, 26 Jul 2020, Linus Torvalds wrote:
> On Sun, Jul 26, 2020 at 1:30 PM Hugh Dickins <hughd@google.com> wrote:
> >
> > I've deduced nothing useful from the logs, will have to leave that
> > to others here with more experience of them. But my assumption now
> > is that you have successfully removed one bottleneck, so the tests
> > get somewhat further and now stick in the next bottleneck, whatever
> > that may be. Which shows up as "failure", where the unlock_page()
> > wake_up_page_bit() bottleneck had allowed the tests to proceed in
> > a more serially sedate way.
>
> Well, that's the very optimistic reading.
>
> As the optimistic and happy person I am (hah!) I'm going to agree with
> you, and plan on just merging that patch early in the next merge
> window. It may fix a real bug in the current trere, but it's much too
> late to apply right now, particularly with your somewhat ambiguous
> results.
Absolutely: it should be good to see it in v5.9,
but much too late for a patch like this in v5.8.
>
> Oleg's theoretical race has probably never been seen, and while the
> watchdog triggering is clearly a real bug, it's also extreme enough
> not to really be a strong argument for merging this out-of-window..
>
> > The xhci handle_cmd_completion list_del bugs (on an older version
> > of the driver): weird, nothing to do with page wakeups, I'll just
> > have to assume that it's some driver bug exposed by the greater
> > stress allowed down, and let driver people investigate (if it
> > still manifests) when we take in your improvements.
>
> Do you have the bug-report, just to google against anybody else
> reporting something simialr>
Okay, just on that basis, with some reluctance an edited extract:
certainly not asking you or anyone on the list to investigate further.
[35196.140502] kernel BUG at lib/list_debug.c:53!
[35196.141448] RIP: 0010:__list_del_entry_valid+0x8e/0xb0
[35196.141534] Call Trace:
[35196.141538] <IRQ>
[35196.141557] [<ffffffffc01bc8b4>] handle_cmd_completion+0x7d4/0x14f0 [xhci_hcd]
[35196.141578] [<ffffffffc01bda22>] xhci_irq+0x242/0x1ea0 [xhci_hcd]
[35196.141608] [<ffffffffc01bf691>] xhci_msi_irq+0x11/0x20 [xhci_hcd]
[35196.141622] [<ffffffffb9ff27f8>] __handle_irq_event_percpu+0x48/0x2c0
[35196.141636] [<ffffffffb9ff2aa2>] handle_irq_event_percpu+0x32/0x80
[35196.141651] [<ffffffffb9ff2b3a>] handle_irq_event+0x4a/0x80
[35196.141680] [<ffffffffb9ff6b08>] handle_edge_irq+0xd8/0x1b0
[35196.141697] [<ffffffffb9ec22ab>] handle_irq+0x2b/0x50
[35196.141712] [<ffffffffbaa02766>] do_IRQ+0xb6/0x1c0
[35196.141725] [<ffffffffbaa00990>] common_interrupt+0x90/0x90
[35196.141732] </IRQ>
>
> > One nice thing from the comparison runs without your patches:
> > watchdog panic did crash one of those with exactly the unlock_page()
> > wake_up_page_bit() softlockup symptom we've been fighting, that did
> > not appear with your patches. So although the sample size is much
> > too small to justify a conclusion, it does tend towards confirming
> > your changes.
>
> You win some, you lose some. But yes, I'll take that as a tentative
> success and that the approach is valid.
Great, yes, tentative success: and we have three months in which to
change our minds if any real trouble surfaces; and I wouldn't call
anything I've seen (since that very first version) *real* trouble.
>
> Thanks,
>
> Linus
next prev parent reply other threads:[~2020-07-26 22:10 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-21 6:32 [RFC PATCH] mm: silence soft lockups from unlock_page Michal Hocko
[not found] ` <FCC3EB2D-9F11-4E9E-88F4-40B2926B35CC@lca.pw>
2020-07-21 11:25 ` Michal Hocko
[not found] ` <664A07B6-DBCD-4520-84F1-241A4E7A339F@lca.pw>
2020-07-21 12:17 ` Michal Hocko
[not found] ` <20200721132343.GA4261@lca.pw>
2020-07-21 13:38 ` Michal Hocko
2020-07-21 14:17 ` Chris Down
2020-07-21 15:00 ` Michal Hocko
2020-07-21 15:33 ` Linus Torvalds
2020-07-21 15:49 ` Michal Hocko
2020-07-22 18:29 ` Linus Torvalds
2020-07-22 21:29 ` Hugh Dickins
2020-07-22 22:10 ` Linus Torvalds
2020-07-22 23:42 ` Linus Torvalds
2020-07-23 0:23 ` Linus Torvalds
2020-07-23 12:47 ` Oleg Nesterov
2020-07-23 17:32 ` Linus Torvalds
2020-07-23 18:01 ` Oleg Nesterov
2020-07-23 18:22 ` Linus Torvalds
2020-07-23 19:03 ` Linus Torvalds
2020-07-24 14:45 ` Oleg Nesterov
2020-07-23 20:03 ` Linus Torvalds
2020-07-23 23:11 ` Hugh Dickins
2020-07-23 23:43 ` Linus Torvalds
2020-07-24 0:07 ` Hugh Dickins
2020-07-24 0:46 ` Linus Torvalds
2020-07-24 3:45 ` Hugh Dickins
2020-07-24 15:24 ` Oleg Nesterov
2020-07-24 17:32 ` Linus Torvalds
2020-07-24 23:25 ` Linus Torvalds
2020-07-25 2:08 ` Hugh Dickins
2020-07-25 2:46 ` Linus Torvalds
2020-07-25 10:14 ` Oleg Nesterov
2020-07-25 18:48 ` Linus Torvalds
2020-07-25 19:27 ` Oleg Nesterov
2020-07-25 19:51 ` Linus Torvalds
2020-07-26 13:57 ` Oleg Nesterov
2020-07-25 21:19 ` Hugh Dickins
2020-07-26 4:22 ` Hugh Dickins
2020-07-26 20:30 ` Hugh Dickins
2020-07-26 20:41 ` Linus Torvalds
2020-07-26 22:09 ` Hugh Dickins [this message]
2020-07-27 19:35 ` Greg KH
2020-08-06 5:46 ` Hugh Dickins
2020-08-18 13:50 ` Greg KH
2020-08-06 5:21 ` Hugh Dickins
2020-08-06 17:07 ` Linus Torvalds
2020-08-06 18:00 ` Matthew Wilcox
2020-08-06 18:32 ` Linus Torvalds
2020-08-07 18:41 ` Hugh Dickins
2020-08-07 19:07 ` Linus Torvalds
2020-08-07 19:35 ` Matthew Wilcox
2020-08-03 13:14 ` Michal Hocko
2020-08-03 17:56 ` Linus Torvalds
2020-07-25 9:39 ` Oleg Nesterov
2020-07-23 8:03 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.11.2007261454110.7444@eggly.anvils \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=oleg@redhat.com \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).