From nobody Wed Feb 11 05:43:43 2026 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A959313664A; Mon, 20 May 2024 13:26:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716211617; cv=none; b=NKoJhoAxwP6/s11ORzKvW+LOShvji1XtJ/DaRvn1mLXTWgrPYHa7eQBiLUIWxrAxjxqfZZGGor8eK2IcuvvsQrGa0OF7/AWPNLFR/41XgFnmuXCJChCxxrye2JbI3yoXRHIzOVfUcoJm1gBdUVk3UcyJegca38AX0Wuv8hSrHJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716211617; c=relaxed/simple; bh=1xasG/CgreKLTDJbZq9iuVZl83sLNiPA8/I/muRRB2o=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ps41td1f5QT6ZP0m9zk6h64ZKLa7BeQJU770IjWthgFcgnTmAg6ZfpyiHJG2XE6dlDtHVzUCt5drvQKVLazGxZJOYermDl9YsMLikE4/6NnrliDmZFmwMp9nfHS/CX8yQ3w6mnRGq1ePuEVSVkwkpbt14N7Hr+zhAbdfMpwwYqE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=VavuuiGk; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VavuuiGk" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1e651a9f3ffso70412495ad.1; Mon, 20 May 2024 06:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716211615; x=1716816415; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RKTW2iTjEKpg8c91ykURECnowHK+hWD/0s3IOnwVtRw=; b=VavuuiGkM1XzMz2UwfYL99BuFVCZ2Cr08fofxDIrrKmwGgatraV0os4oiz71lHO0fF xOjPARHn+OUmfs8/gVr8nEG/h3dWXCyYveZNgOf4zkrC+HfVrr7t9ECPfhUwAMH9Jyqx PXMw98xdhlRbw1LEYXJ7XBtSiKB4tkv2ttzTDx0/XSkK5IvA2rj8IfwMM1LwONLbfMEy /W+c0oWyK5xmaHb1THIVzRl8nFFhXQryW1inDBTyQUlERGYbZ4AljQru9n0jb8Vr7xZ8 eDsUuliDsJpcUPhkCFwBFOcKgDurbLhMU5gr/mcl9z3nQhcAiAi4gyPEdVMCUlRK1rC2 YItA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716211615; x=1716816415; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RKTW2iTjEKpg8c91ykURECnowHK+hWD/0s3IOnwVtRw=; b=eOz370AHAoBsK3amyXlZ9F2vY64RvIYI4LeKpTcxcQ7V6d0QJ8sdD6o3AroHFnIIOt shCbjTplswuIYWqyua6Cjp208VXAH01ay0494IMjSj4MOfFL0Pn6R3n2HaxSqfpXDsoU pkt0V9cKVEF9MzN11vtExtW/t15eErtIlTxHVSOnWvtVnGxw2ZEGKv+XF8OZSr61qBMC gEcRywN05S78YkP6YMxN0ZeIYTH9hwBD4jGfy7Ex8TX2GWWqQeUf4/E7ABedtK6b2Ion lQaA2LLIkW2SDeoqIsvtxP3yOe8EKa/ydEU297qMi5GDg4rvgJ0CYvptXBSguYVTl8oc o8Qw== X-Forwarded-Encrypted: i=1; AJvYcCVQJJhB+sijhMFGGNXQiP0RPW1S27yB6GSo5i6/99HP6sir2PWh0SeIu/UD0qOh+zBTLb5NaxYAWgBLZWzIV5fVpHGHEEPV5pD3Vsd8 X-Gm-Message-State: AOJu0YwzgghLZt92Gw3UsHH/JdtvHLzr6h1GCqHPcpBNI4qVwCz/MrRe Idj2mXAXgEFFw3kidaVNRW1RdBo1LG20sDVjL93w0F/LlXPvhd52 X-Google-Smtp-Source: AGHT+IEfyWey7gyS6tKFyo43qi+P5NuXgxOtcYINd+l/8gE9ftaUVUJrac7/TUZOk0Vs6fVCifn4Qw== X-Received: by 2002:a17:90b:1252:b0:2b1:a150:f75f with SMTP id 98e67ed59e1d1-2b6cc7801fbmr27283404a91.23.1716211614875; Mon, 20 May 2024 06:26:54 -0700 (PDT) Received: from carrot.. (i222-151-4-139.s42.a014.ap.plala.or.jp. [222.151.4.139]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2b628849c40sm22011380a91.18.2024.05.20.06.26.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 May 2024 06:26:54 -0700 (PDT) From: Ryusuke Konishi To: Andrew Morton Cc: linux-nilfs@vger.kernel.org, syzbot , syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org, sjb7183@psu.edu Subject: [PATCH 1/3] nilfs2: fix use-after-free of timer for log writer thread Date: Mon, 20 May 2024 22:26:19 +0900 Message-Id: <20240520132621.4054-2-konishi.ryusuke@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240520132621.4054-1-konishi.ryusuke@gmail.com> References: <0000000000001a167a05ebc4f62b@google.com> <20240520132621.4054-1-konishi.ryusuke@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure. The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime. Fix this issue by limiting the use of sc_timer only while the log writer thread is alive. Reported-by: "Bai, Shuangpeng" Closes: https://groups.google.com/g/syzkaller/c/MK_LYqtt8ko/m/8rgdWeseAwAJ Signed-off-by: Ryusuke Konishi Fixes: fdce895ea5dd ("nilfs2: change sc_timer from a pointer to an embedded= one in struct nilfs_sc_info") Tested-by: Ryusuke Konishi Cc: stable@vger.kernel.org --- fs/nilfs2/segment.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 8654ab8ad534..4e274bc8eb79 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -2118,8 +2118,10 @@ static void nilfs_segctor_start_timer(struct nilfs_s= c_info *sci) { spin_lock(&sci->sc_state_lock); if (!(sci->sc_state & NILFS_SEGCTOR_COMMIT)) { - sci->sc_timer.expires =3D jiffies + sci->sc_interval; - add_timer(&sci->sc_timer); + if (sci->sc_task) { + sci->sc_timer.expires =3D jiffies + sci->sc_interval; + add_timer(&sci->sc_timer); + } sci->sc_state |=3D NILFS_SEGCTOR_COMMIT; } spin_unlock(&sci->sc_state_lock); @@ -2320,10 +2322,21 @@ int nilfs_construct_dsync_segment(struct super_bloc= k *sb, struct inode *inode, */ static void nilfs_segctor_accept(struct nilfs_sc_info *sci) { + bool thread_is_alive; + spin_lock(&sci->sc_state_lock); sci->sc_seq_accepted =3D sci->sc_seq_request; + thread_is_alive =3D (bool)sci->sc_task; spin_unlock(&sci->sc_state_lock); - del_timer_sync(&sci->sc_timer); + + /* + * This function does not race with the log writer thread's + * termination. Therefore, deleting sc_timer, which should not be + * done after the log writer thread exits, can be done safely outside + * the area protected by sc_state_lock. + */ + if (thread_is_alive) + del_timer_sync(&sci->sc_timer); } =20 /** @@ -2349,7 +2362,7 @@ static void nilfs_segctor_notify(struct nilfs_sc_info= *sci, int mode, int err) sci->sc_flush_request &=3D ~FLUSH_DAT_BIT; =20 /* re-enable timer if checkpoint creation was not done */ - if ((sci->sc_state & NILFS_SEGCTOR_COMMIT) && + if ((sci->sc_state & NILFS_SEGCTOR_COMMIT) && sci->sc_task && time_before(jiffies, sci->sc_timer.expires)) add_timer(&sci->sc_timer); } @@ -2539,6 +2552,7 @@ static int nilfs_segctor_thread(void *arg) int timeout =3D 0; =20 sci->sc_timer_task =3D current; + timer_setup(&sci->sc_timer, nilfs_construction_timeout, 0); =20 /* start sync. */ sci->sc_task =3D current; @@ -2606,6 +2620,7 @@ static int nilfs_segctor_thread(void *arg) end_thread: /* end sync. */ sci->sc_task =3D NULL; + timer_shutdown_sync(&sci->sc_timer); wake_up(&sci->sc_wait_task); /* for nilfs_segctor_kill_thread() */ spin_unlock(&sci->sc_state_lock); return 0; @@ -2669,7 +2684,6 @@ static struct nilfs_sc_info *nilfs_segctor_new(struct= super_block *sb, INIT_LIST_HEAD(&sci->sc_gc_inodes); INIT_LIST_HEAD(&sci->sc_iput_queue); INIT_WORK(&sci->sc_iput_work, nilfs_iput_work_func); - timer_setup(&sci->sc_timer, nilfs_construction_timeout, 0); =20 sci->sc_interval =3D HZ * NILFS_SC_DEFAULT_TIMEOUT; sci->sc_mjcp_freq =3D HZ * NILFS_SC_DEFAULT_SR_FREQ; @@ -2748,7 +2762,6 @@ static void nilfs_segctor_destroy(struct nilfs_sc_inf= o *sci) =20 down_write(&nilfs->ns_segctor_sem); =20 - timer_shutdown_sync(&sci->sc_timer); kfree(sci); } =20 --=20 2.34.1 From nobody Wed Feb 11 05:43:43 2026 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F55713667A; Mon, 20 May 2024 13:26:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716211619; cv=none; b=dQFf9FUJLstiTu5EBx/Yy7YYnsC6GakQ2aRABG1kSLiS9d/uIIx2r95JoYARojLeugLEJbNWTCX+PFhUaEOFR4F9JPuF1MAfAQMHCXMjdPptipUn7C6GEmrwW89nca9PIAijCMpkdjKfYXDZOZJf7uVgWK8iOLopPoHZYzlIj/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716211619; c=relaxed/simple; bh=Bp5+ddPO3oY5d6Y4HWGFFKko18BikL+HuJJMIuI9WTc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=CxFlnKdN2HTCdUDBuYS/M/CbC0FWr2q8AVFTmUTCqNKX3bnWxxoeTp5IcZEHTpvsmPncRxBdC2pHCU+Q67btzOcfZBirFJ8qo8h7zcZjrWwIJyoqNQwABkY8c0sWidUNCMVUE4dhEUEI9nwtUogEvhmso7919Fp9CZoPYixfujw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=VBlu7leL; arc=none smtp.client-ip=209.85.214.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VBlu7leL" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1f05b669b6cso72025165ad.3; Mon, 20 May 2024 06:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716211617; x=1716816417; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=aifCUaK8ycM8ZmIgqu2a8d63Rnfm4Ic3U3SghkzNkDg=; b=VBlu7leLMvsMzO4RvEBKbSEg7lUZVwG517MBbwamTrUyUgwHWDGeND14KBnMQRG5rj WppvHIhY+mgLSX/mJ3cP/bqldXNdv2jLJKhiXoIDTJe98n1R0juUFIpxbRks7cm3e2ZO qy9dNFqghwrGbTwTf0UOzC0lArFqj29GFCkn1Sz8JlU5tHign84WCTDukSgvqp5mun93 jx3OUQxm+8eOFIjjO96BZasFX2Cw4BmOCZPKhSn1wRv/ugH0ZrYGEATjkUKTp+7ib2Li 6LWSlYELk6KOYiWniYpzTOk6WNnXIWZQwU1ZndbZ2wp+s6eW5Y3uaxgDC9uTWaijgKyR d3mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716211617; x=1716816417; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aifCUaK8ycM8ZmIgqu2a8d63Rnfm4Ic3U3SghkzNkDg=; b=w5VzDWB9jiIlUOVeiOV0b5mEkTnKeXvJNstL9WJ2eQJLAijri7fnNS9w7XjnYLywcJ U0y4GgEpw35iH3fD246OfUigD04hMe3jkpW1/XkRpun/FKXitT9IqM4YpEm70boP6qtg SEBM6aWvOW8zSWc3AOXBsVJkyVTT4hAj/aQlsYjfHUfrzoYXRVRl9hKIaxiCHNJygaiV InSc1wBxBQu+d2HoCUBuUNPovu58FaPXpNKwaUqAUwfn+ROf6zvw97cZl2hnuLAu6CSW ozmvPDSPDPVJhBLOEO+pAtc8ABcLbSDA+aCXDzRjVnVWYuG5TZEJOCBLG8cs9eJj21Zg HRTQ== X-Forwarded-Encrypted: i=1; AJvYcCVsj40qzFC2GOzgbQs/4/Es93o8iL+IRp+7HJPNiMOjXXpea5O9WqfJSssA5wjCOdKlrZkqBHKAnsVY12VNMYZSt/pdgi72qu6X/pCW X-Gm-Message-State: AOJu0YysX559tynucqaEdB9C0sSytH+nJKJxi5lYPLYjqAgxkOTL4869 /vC4EUlCj2CuXUjwNR2Jcq1WvkzYNSdGeEajJnXx1qSszhQ1bZbv X-Google-Smtp-Source: AGHT+IGvh8bM0dmIPutZvCeHdO5spWa/oDTfvmy6PSH9aarOfm/9orXe4fF4OhD9MXoELviUmUZpUA== X-Received: by 2002:a17:90a:e50c:b0:2bd:5337:989b with SMTP id 98e67ed59e1d1-2bd533798d3mr6817260a91.35.1716211617380; Mon, 20 May 2024 06:26:57 -0700 (PDT) Received: from carrot.. (i222-151-4-139.s42.a014.ap.plala.or.jp. [222.151.4.139]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2b628849c40sm22011380a91.18.2024.05.20.06.26.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 May 2024 06:26:56 -0700 (PDT) From: Ryusuke Konishi To: Andrew Morton Cc: linux-nilfs@vger.kernel.org, syzbot , syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org, sjb7183@psu.edu Subject: [PATCH 2/3] nilfs2: fix unexpected freezing of nilfs_segctor_sync() Date: Mon, 20 May 2024 22:26:20 +0900 Message-Id: <20240520132621.4054-3-konishi.ryusuke@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240520132621.4054-1-konishi.ryusuke@gmail.com> References: <0000000000001a167a05ebc4f62b@google.com> <20240520132621.4054-1-konishi.ryusuke@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A potential and reproducible race issue has been identified where nilfs_segctor_sync() would block even after the log writer thread writes a checkpoint, unless there is an interrupt or other trigger to resume log writing. This turned out to be because, depending on the execution timing of the log writer thread running in parallel, the log writer thread may skip responding to nilfs_segctor_sync(), which causes a call to schedule() waiting for completion within nilfs_segctor_sync() to lose the opportunity to wake up. The reason why waking up the task waiting in nilfs_segctor_sync() may be skipped is that updating the request generation issued using a shared sequence counter and adding an wait queue entry to the request wait queue to the log writer, are not done atomically. There is a possibility that log writing and request completion notification by nilfs_segctor_wakeup() may occur between the two operations, and in that case, the wait queue entry is not yet visible to nilfs_segctor_wakeup() and the wake-up of nilfs_segctor_sync() will be carried over until the next request occurs. Fix this issue by performing these two operations simultaneously within the lock section of sc_state_lock. Also, following the memory barrier guidelines for event waiting loops, move the call to set_current_state() in the same location into the event waiting loop to ensure that a memory barrier is inserted just before the event condition determination. Signed-off-by: Ryusuke Konishi Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Tested-by: Ryusuke Konishi Cc: stable@vger.kernel.org --- fs/nilfs2/segment.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 4e274bc8eb79..99c78a49e432 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -2168,19 +2168,28 @@ static int nilfs_segctor_sync(struct nilfs_sc_info = *sci) struct nilfs_segctor_wait_request wait_req; int err =3D 0; =20 - spin_lock(&sci->sc_state_lock); init_wait(&wait_req.wq); wait_req.err =3D 0; atomic_set(&wait_req.done, 0); + init_waitqueue_entry(&wait_req.wq, current); + + /* + * To prevent a race issue where completion notifications from the + * log writer thread are missed, increment the request sequence count + * "sc_seq_request" and insert a wait queue entry using the current + * sequence number into the "sc_wait_request" queue at the same time + * within the lock section of "sc_state_lock". + */ + spin_lock(&sci->sc_state_lock); wait_req.seq =3D ++sci->sc_seq_request; + add_wait_queue(&sci->sc_wait_request, &wait_req.wq); spin_unlock(&sci->sc_state_lock); =20 - init_waitqueue_entry(&wait_req.wq, current); - add_wait_queue(&sci->sc_wait_request, &wait_req.wq); - set_current_state(TASK_INTERRUPTIBLE); wake_up(&sci->sc_wait_daemon); =20 for (;;) { + set_current_state(TASK_INTERRUPTIBLE); + if (atomic_read(&wait_req.done)) { err =3D wait_req.err; break; --=20 2.34.1 From nobody Wed Feb 11 05:43:43 2026 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 167E31369A1; Mon, 20 May 2024 13:27:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716211622; cv=none; b=hoExJhkoMPvEk/tJioAwse2TDHDqbaXw3m8mKHJLD4WPlpUyX5O36tJQGlR0hx7bfe7UZ9uGgJq1z8i4C2G2wYrT51uzDOwLXIuHbUjqKTcr384EJW91+XDlj7Fs8DXzJQ4Xpz0fL9kf7nGWUKnivSxqBOrwzbnts7aQiML0c/A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716211622; c=relaxed/simple; bh=0pWZhWs3EMPgwiv2J/jv7QnmCej/OqSCgrcNLJE+h5Y=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=k9BnqzgT+5IUGeyxha90MTIy+bqYExnImtqv6qu77Ckw7XFG+wpGOQoxicQB1wUWqQaINxLn9yh0E55fKmG1ePPX3BH4tCARgtiD0CiGn2k3vP80HUDyMupm9jhu+viXH63bGG4EKYj2AmS/JOa6YL4qsdhy1+/7XEMQwnMC6hU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=L3NkJ8AJ; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="L3NkJ8AJ" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1eb0e08bfd2so76609325ad.1; Mon, 20 May 2024 06:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716211620; x=1716816420; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=96ExljQ2zVirPNQa+ZzfNLvxLXxlK8xHce/amt9Pe0M=; b=L3NkJ8AJgS9UwRJzKKIfk8jQ36FZtwwt1c/I+nPLW1Fw/xcAdcAPQ8mgMvOUR+9z1c /ct2FKgQe3k7B/gu2B8nkecxGZwYXYExYF84auteQSTXOAqaq3zgCTEeK44a+uVuv2CP XbIaWOsfKuGqcBePgD0Kub/HvEoc+sOAR2PS4XgfRHyE3gmNCFF7Kn37M8drZJ/9PuTp L8gIfH0ZBp/ze1EPqIaWDZnW0qMQPZFdF+XO7viiXhH2wx80fkhPDt45BtA6pUzDrY7B pdROYvYxBimJcf5PFTipx1izMqPkpCVjDoU4AsMblR2wzSuJpfnN02kS5COuxBCwSPVD Rq8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716211620; x=1716816420; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=96ExljQ2zVirPNQa+ZzfNLvxLXxlK8xHce/amt9Pe0M=; b=mBR7SI+qd1QnINI2velzUDA4av8tDa0P6sceyDnfapH3hHuDs8ZchcDskbvtHtFuzv ZJsSD1n6ik0SOELBnlBht+sNDJt0DHva985pfWWuK4bAXNc1E9pmm1OaT422JZSGRnPo eQoxiCXYpyJeNfZyF5fPKnBBtc5rIXa717ZlJ8RLDDScG7bO3ldrHiHia9fJ9JsWV9gH nrm+eQbBULi14j6lSQ2oTHz69UC8TP3DhFIwV4IvCWESE74ggbblRUAo4DcIfpgKf1mC TkS3UiKlC8lYpn5kq1EpxEQyqOG3l15qGOQ+3c1pz1qb1oSKjH/wwxq6zkmYyUePuThh JzRQ== X-Forwarded-Encrypted: i=1; AJvYcCWZ2GMLRvMH/Xn4W5sB7BSYDyvEGWimipgei1tZ7Sn7M6CHXIiux1q1afKTi9i1dky1e4LwAapfAkw39NDPL0mfJ5sAr3Xeb9++1vuS X-Gm-Message-State: AOJu0YxodhpdYawEUjWvVYXTuuhPYzEFsiVeRagMkOYvf7hXMHlDBkSQ C0ltYsr+sNwenPfR+WoN3VwcwLHePV3ULpNVJEua25YDdnoRkv2x X-Google-Smtp-Source: AGHT+IGbyOUs1EhYzCeml++ycEXgnW9tLpQUKE0JgndaN/V4OMsLmhiL6BPpSZ8uUt5XV8TWCUbRIA== X-Received: by 2002:a17:90a:5901:b0:2b3:28be:dd6e with SMTP id 98e67ed59e1d1-2b6ccd6baedmr25282210a91.33.1716211620226; Mon, 20 May 2024 06:27:00 -0700 (PDT) Received: from carrot.. (i222-151-4-139.s42.a014.ap.plala.or.jp. [222.151.4.139]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2b628849c40sm22011380a91.18.2024.05.20.06.26.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 May 2024 06:26:59 -0700 (PDT) From: Ryusuke Konishi To: Andrew Morton Cc: linux-nilfs@vger.kernel.org, syzbot , syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org, sjb7183@psu.edu Subject: [PATCH 3/3] nilfs2: fix potential hang in nilfs_detach_log_writer() Date: Mon, 20 May 2024 22:26:21 +0900 Message-Id: <20240520132621.4054-4-konishi.ryusuke@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240520132621.4054-1-konishi.ryusuke@gmail.com> References: <0000000000001a167a05ebc4f62b@google.com> <20240520132621.4054-1-konishi.ryusuke@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount. Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below: nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread *** DEADLOCK *** Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates. The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy(). Signed-off-by: Ryusuke Konishi Reported-by: syzbot+e3973c409251e136fdd0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3De3973c409251e136fdd0 Tested-by: Ryusuke Konishi Cc: stable@vger.kernel.org --- fs/nilfs2/segment.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 99c78a49e432..c27f0daec9af 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -2190,6 +2190,14 @@ static int nilfs_segctor_sync(struct nilfs_sc_info *= sci) for (;;) { set_current_state(TASK_INTERRUPTIBLE); =20 + /* + * Synchronize only while the log writer thread is alive. + * Leave flushing out after the log writer thread exits to + * the cleanup work in nilfs_segctor_destroy(). + */ + if (!sci->sc_task) + break; + if (atomic_read(&wait_req.done)) { err =3D wait_req.err; break; @@ -2205,7 +2213,7 @@ static int nilfs_segctor_sync(struct nilfs_sc_info *s= ci) return err; } =20 -static void nilfs_segctor_wakeup(struct nilfs_sc_info *sci, int err) +static void nilfs_segctor_wakeup(struct nilfs_sc_info *sci, int err, bool = force) { struct nilfs_segctor_wait_request *wrq, *n; unsigned long flags; @@ -2213,7 +2221,7 @@ static void nilfs_segctor_wakeup(struct nilfs_sc_info= *sci, int err) spin_lock_irqsave(&sci->sc_wait_request.lock, flags); list_for_each_entry_safe(wrq, n, &sci->sc_wait_request.head, wq.entry) { if (!atomic_read(&wrq->done) && - nilfs_cnt32_ge(sci->sc_seq_done, wrq->seq)) { + (force || nilfs_cnt32_ge(sci->sc_seq_done, wrq->seq))) { wrq->err =3D err; atomic_set(&wrq->done, 1); } @@ -2362,7 +2370,7 @@ static void nilfs_segctor_notify(struct nilfs_sc_info= *sci, int mode, int err) if (mode =3D=3D SC_LSEG_SR) { sci->sc_state &=3D ~NILFS_SEGCTOR_COMMIT; sci->sc_seq_done =3D sci->sc_seq_accepted; - nilfs_segctor_wakeup(sci, err); + nilfs_segctor_wakeup(sci, err, false); sci->sc_flush_request =3D 0; } else { if (mode =3D=3D SC_FLUSH_FILE) @@ -2746,6 +2754,13 @@ static void nilfs_segctor_destroy(struct nilfs_sc_in= fo *sci) || sci->sc_seq_request !=3D sci->sc_seq_done); spin_unlock(&sci->sc_state_lock); =20 + /* + * Forcibly wake up tasks waiting in nilfs_segctor_sync(), which can + * be called from delayed iput() via nilfs_evict_inode() and can race + * with the above log writer thread termination. + */ + nilfs_segctor_wakeup(sci, 0, true); + if (flush_work(&sci->sc_iput_work)) flag =3D true; =20 --=20 2.34.1