On Tue, Jul 05, 2022 at 04:47:10PM -0700, Andrew Morton wrote: > On Wed, 6 Jul 2022 00:38:41 +0100 Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > On Tue, Jul 05, 2022 at 02:18:19PM -0700, Andrew Morton wrote: > > > On Tue, 5 Jul 2022 20:35:32 +0800 Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote: > > > > > > > FSDAX page refcounts are 1-based, rather than 0-based: if refcount is > > > > 1, then the page is freed. The FSDAX pages can be pinned through GUP, > > > > then they will be unpinned via unpin_user_page() using a folio variant > > > > to put the page, however, folio variants did not consider this special > > > > case, the result will be to miss a wakeup event (like the user of > > > > __fuse_dax_break_layouts()). Since FSDAX pages are only possible get > > > > by GUP users, so fix GUP instead of folio_put() to lower overhead. > > > > > > > > > > What are the user visible runtime effects of this bug? > > > > "missing wake up event" seems pretty obvious to me? Something goes to > > sleep waiting for a page to become unused, and is never woken. > > No, missed wakeups are often obscured by another wakeup coming in > shortly afterwards. > I need to clarify the task will never be woken up. > If this wakeup is not one of these, then are there reports from the > softlockup detector? > > Do we have reports of processes permanently stuck in D state? > No. The task is in an TASK_INTERRUPTIBLE state (see __fuse_dax_break_layouts). The hung task reporter only reports D task (TASK_UNINTERRUPTIBLE). Thanks. >
