From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C2ED1126F3B for ; Fri, 24 Apr 2026 02:34:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776998046; cv=none; b=cRtyYMEbR1WVY+CcZ34easTFDoJTBH0YkF6KfPE/07+NEtpam5UABd1zDALTXXnq54DnYiKGb8q/NCFarLNXcmHsK8P9jG4c8C9AGID5zzjc0vG7flxnQVL4nDM/j6TzmpTYBPssTZd3U6CA1T3UkiXJu97DQtKBaB2eXST1byM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776998046; c=relaxed/simple; bh=4HoO+TiilUqYRofvchVhUVPT6xynrltiaL0pHQnn1jM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rPofAGlK6ET4ZtNXuUNkl5lyOVCeaiFfIpI9myaLf65bUTyQH4OmYiMdwHyGxRKmfUvTMdtnhYZ5Dsq9QjAjSpehHJhyNwn6gVIW+Vz0Xna1MZSUJOkiqkF972Paw7ZKN+V81mdog9XzZtCtxhhJCINSjQM+W448BGkqno/0g44= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ESfD1taI; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ESfD1taI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776998045; x=1808534045; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=4HoO+TiilUqYRofvchVhUVPT6xynrltiaL0pHQnn1jM=; b=ESfD1taI7/gS51KVA6TnXZ+7ZcJDyadHntmCcFmPchvP11w9hKtqad5r G7YHZ+ckSS9xzOBZtei9/HpYpFdLfHYVCK02XVmGiHhxaK8tiLtbSBBw7 2U8W1r2jFgU4hldLx8usYoYvBWwVaL6BWgO1A3hMPM1XeGgKW8y+NnV4L /8/vtpw5Xk3liqqjt/c34SbcV1NL3HxtjAjfNtG5W4aYUxjN0zRJxqE2z 0WkOY6CcTHFSLuhUvYTfT+ZvjkK58Vj6esYEMgR73W1z19b4w13Yapr8i NdWSP43c+VkegKQhZam6rDyXSNtPJzw0JOtkO0pQFLUBKRQ94pqDYN5Ze g==; X-CSE-ConnectionGUID: 99v3ND2nTziX84/GEGii2A== X-CSE-MsgGUID: nCRt1eocQDqSUViSj4VUYQ== X-IronPort-AV: E=McAfee;i="6800,10657,11765"; a="77679013" X-IronPort-AV: E=Sophos;i="6.23,195,1770624000"; d="scan'208";a="77679013" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2026 19:34:04 -0700 X-CSE-ConnectionGUID: o2pY462DT224npT3EHrYug== X-CSE-MsgGUID: 82L8oYUUTb2cM947U5T3Tg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,195,1770624000"; d="scan'208";a="237822173" Received: from arjan-box.jf.intel.com ([10.88.27.153]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2026 19:34:04 -0700 From: Arjan van de Ven To: linux-mm@kvack.org Cc: syzbot+9722a25de70a85ff48a1@syzkaller.appspotmail.com, akpm@linux-foundation.org, baolin.wang@linux.alibaba.com, hughd@google.com, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [mm?] BUG: sleeping function called from invalid context in shmem_undo_range Date: Thu, 23 Apr 2026 19:34:54 -0700 Message-ID: <20260424023524.322251-1-arjan@linux.intel.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <69eab803.a00a0220.17a17.004b.GAE@google.com> References: <69eab803.a00a0220.17a17.004b.GAE@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This email is created by automation to help kernel developers deal with a large volume of AI generated bug reports by decoding oopses into more actionable information. Decoded Backtrace shmem_undo_range (mm/shmem.c:1108-1151) -- crash site ------------------------------------------------------ 1108 static void shmem_undo_range(struct inode *inode, loff_t lstart, 1109 uoff_t lend, bool unfalloc) 1110 { 1111 struct address_space *mapping = inode->i_mapping; 1112 struct shmem_inode_info *info = SHMEM_I(inode); 1113 pgoff_t start = (lstart + PAGE_SIZE - 1) >> PAGE_SHIFT; 1114 pgoff_t end = (lend + 1) >> PAGE_SHIFT; 1115 struct folio_batch fbatch; 1116 pgoff_t indices[FOLIO_BATCH_SIZE]; 1117 struct folio *folio; 1118 bool same_folio; 1119 long nr_swaps_freed = 0; 1120 pgoff_t index; 1121 int i; ... 1129 folio_batch_init(&fbatch); 1130 index = start; 1131 while (index < end && find_lock_entries(mapping, &index, 1132 end - 1, &fbatch, indices)) { 1133 for (i = 0; i < folio_batch_count(&fbatch); i++) { 1134 folio = fbatch.folios[i]; 1135 if (xa_is_value(folio)) { ... 1143 } 1144 if (!unfalloc || !folio_test_uptodate(folio)) 1145 truncate_inode_folio(mapping, folio); 1146 folio_unlock(folio); 1147 } 1148 folio_batch_remove_exceptionals(&fbatch); 1149 folio_batch_release(&fbatch); 1150 cond_resched(); /* <-- BUG fires here; RCU nest depth=1 */ 1151 } filename_unlinkat (fs/namei.c:5526-5587) -- top-level caller ------------------------------------------------------------- 5526 int filename_unlinkat(int dfd, struct filename *name) 5527 { ... 5545 error = mnt_want_write(path.mnt); /* lock #0 (sb_writers) */ 5546 if (error) 5547 goto exit_path_put; 5548 retry_deleg: 5549 dentry = start_dirop(path.dentry, &last, lookup_flags); ... 5563 inode = dentry->d_inode; 5564 ihold(inode); 5565 error = security_path_unlink(&path, dentry); 5566 if (error) 5567 goto exit_end_dirop; 5568 error = vfs_unlink(mnt_idmap(path.mnt), path.dentry->d_inode, 5569 dentry, &delegated_inode); 5570 exit_end_dirop: 5571 end_dirop(dentry); 5572 iput(inode); /* triggers shmem_evict_inode -> shmem_undo_range */ ... 5579 mnt_drop_write(path.mnt); ... 5587 } Tentative Analysis The crash is triggered by running rm(1) on a tmpfs/shmem file. The call chain is: sys_unlink -> filename_unlinkat -> iput -> iput_final -> evict -> shmem_evict_inode -> shmem_truncate_range -> shmem_undo_range -> cond_resched() <-- BUG fires here At crash time, two locks are held (in acquisition order): #0 sb_writers#5 -- acquired at filename_unlinkat+0x1ad (fs/namei.c:5545 -- mnt_want_write) #1 rcu_read_lock -- acquired at rcu_lock_acquire.constprop.0 (include/linux/rcupdate.h:300) Lock #1 (rcu_read_lock) was acquired AFTER mnt_want_write (lock #0 is always recorded first in the lockdep list) and before the iput() call at line 5572. That window contains start_dirop(), security_path_unlink() and vfs_unlink() (which calls fsnotify_unlink() and d_delete_notify() on the success path). On a PREEMPT(full) kernel, rcu_read_lock() increments current->rcu_read_lock_nesting instead of disabling preemption. cond_resched() -> __cond_resched() -> __might_resched() checks that counter, finds it is 1 (not 0), and fires the BUG. The same leaked rcu_read_lock persists all the way back to userspace ("lock held when returning to user space!"), and a timer interrupt firing during the syscall produces a third warning: "Voluntary context switch within RCU read-side critical section!" All three messages are symptoms of a single rcu_read_lock() call that is never matched by an rcu_read_unlock() somewhere between mnt_want_write and iput in filename_unlinkat. Potential Solution Find the rcu_read_lock() call that is missing its matching rcu_read_unlock() in the vfs_unlink() / fsnotify_unlink() / d_delete_notify() code path. Adding a WARN_ON(rcu_read_lock_held()) to iput() (alongside the existing might_sleep() check) should produce a backtrace pointing at the exact acquisition site on the next reproduction. More information Oops-Analysis: http://oops.fenrus.org/reports/lkml/69eab803.a00a0220.17a17.004b.GAE_google.com/report.html Assisted-by: GitHub Copilot:claude-sonnet-4.6 linux-kernel-oops-x86.