All of lore.kernel.org
 help / color / mirror / Atom feed
From: Byungchul Park <byungchul@sk.com>
To: Gavin Guo <gavinguo@igalia.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	muchun.song@linux.dev, osalvador@suse.de,
	akpm@linux-foundation.org, mike.kravetz@oracle.com,
	kernel-dev@igalia.com, stable@vger.kernel.org,
	Hugh Dickins <hughd@google.com>,
	Florent Revest <revest@google.com>, Gavin Shan <gshan@redhat.com>,
	kernel_team@skhynix.com
Subject: Re: [PATCH] mm/hugetlb: fix a deadlock with pagecache_folio and hugetlb_fault_mutex_table
Date: Fri, 16 May 2025 15:03:09 +0900	[thread overview]
Message-ID: <20250516060309.GA51921@system.software.com> (raw)
In-Reply-To: <075ae729-1d4a-4f12-a2ba-b4f508e5d0a1@igalia.com>

On Wed, May 14, 2025 at 04:10:12PM +0800, Gavin Guo wrote:
> Hi Byungchul,
> 
> On 5/14/25 14:47, Byungchul Park wrote:
> > On Tue, May 13, 2025 at 05:34:48PM +0800, Gavin Guo wrote:
> > > The patch fixes a deadlock which can be triggered by an internal
> > > syzkaller [1] reproducer and captured by bpftrace script [2] and its log
> > 
> > Hi,
> > 
> > I'm trying to reproduce using the test program [1].  But not yet
> > produced.  I see a lot of segfaults while running [1].  I guess
> > something goes wrong.  Is there any prerequisite condition to reproduce
> > it?  Lemme know if any.  Or can you try DEPT15 with your config and
> > environment by the following steps:
> > 
> >     1. Apply the patchset on v6.15-rc6.
> >        https://lkml.kernel.org/r/20250513100730.12664-1-byungchul@sk.com
> >     2. Turn on CONFIG_DEPT.
> >     3. Run test program reproducing the deadlock.
> >     4. Check dmesg to see if dept reported the dependency.
> > 
> > 	Byungchul
> 
> I have enabled the patchset and successfully reproduced the bug. It
> seems that there is no warning or error log related to the lock. Did I
> miss anything? This is the console log:
> https://drive.google.com/file/d/1dxWNiO71qE-H-e5NMPqj7W-aW5CkGSSF/view?usp=sharing

My bad.  I think I found the problem that dept didn't report it.  You
might see the report with the following patch applied on the top, there
might be a lot of false positives along with that might be annoying tho.

Some of my efforts to suppress false positives, suppressed the real one.

Do you mind if I ask you to run the test with the following patch
applied?  It'd be appreciated if you do and share the result with me.

	Byungchul

---
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index f31cd68f2935..fd7559e663c5 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -1138,6 +1138,7 @@ static inline bool trylock_page(struct page *page)
 static inline void folio_lock(struct folio *folio)
 {
 	might_sleep();
+	dept_page_wait_on_bit(&folio->page, PG_locked);
 	if (!folio_trylock(folio))
 		__folio_lock(folio);
 }
diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c
index b2fa96d984bc..4e96a6a72d02 100644
--- a/kernel/dependency/dept.c
+++ b/kernel/dependency/dept.c
@@ -931,7 +931,6 @@ static void print_circle(struct dept_class *c)
 	dept_outworld_exit();
 
 	do {
-		tc->reported = true;
 		tc = fc;
 		fc = fc->bfs_parent;
 	} while (tc != c);
diff --git a/kernel/dependency/dept_unit_test.c b/kernel/dependency/dept_unit_test.c
index 88e846b9f876..496149f31fb3 100644
--- a/kernel/dependency/dept_unit_test.c
+++ b/kernel/dependency/dept_unit_test.c
@@ -125,6 +125,8 @@ static int __init dept_ut_init(void)
 {
 	int i;
 
+	return 0;
+
 	lockdep_off();
 
 	dept_ut_results.ecxt_stack_valid_cnt = 0;
--

  parent reply	other threads:[~2025-05-16  6:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-13  9:34 [PATCH] mm/hugetlb: fix a deadlock with pagecache_folio and hugetlb_fault_mutex_table Gavin Guo
2025-05-14  0:56 ` Andrew Morton
2025-05-14  4:33   ` Byungchul Park
2025-05-14  6:47 ` Byungchul Park
2025-05-14  8:10   ` Gavin Guo
2025-05-15  2:22     ` Byungchul Park
2025-05-16  6:03     ` Byungchul Park [this message]
2025-05-16  7:32       ` Gavin Guo
2025-05-16  7:43         ` Byungchul Park
2025-05-20 19:53 ` Oscar Salvador
2025-05-21 11:12   ` Gavin Guo
2025-05-26  4:41 ` Gavin Shan
2025-05-27  9:59   ` Gavin Guo
2025-05-27 10:59     ` Gavin Shan

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=20250516060309.GA51921@system.software.com \
    --to=byungchul@sk.com \
    --cc=akpm@linux-foundation.org \
    --cc=gavinguo@igalia.com \
    --cc=gshan@redhat.com \
    --cc=hughd@google.com \
    --cc=kernel-dev@igalia.com \
    --cc=kernel_team@skhynix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=revest@google.com \
    --cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.