From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (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 A09B12941A for ; Thu, 20 Aug 2026 03:39:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787197199; cv=none; b=QjEQomF7PViOMsqHokFlCvrzTxvVfbLJW7KgYjK+toKZdcXkvzo2phexxg3c48ecDY0ZBfjnug7OV+zd+U55ygAtABhwOagx9+0/QBjYlRbwQsFhh61wK+3eX1I3KlWJPbFWIt9Sz+DuNR7OvSxSik9pwtEyFc18vEh1oEBDnB8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787197199; c=relaxed/simple; bh=Qr6IQ6xpPxoUEkJ+MXW19NTLP4tT18ZCQ5KBOS/0iK8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iq81SlCv58l50SLvOhrBnKThtOkInIBiGjm4hsE3US6vFovNkJQikjxQlhpvxO5zR1+yfI6hcENzAfsnTzgm5hVahPYBzBUKBQxTfbRvhDjjI+4WfFiMwnOcM6wwwEJCqCYQXRSyMa8SSUbY3Gsw+Wf9xiMpbQb3C4jS13MpP5s= 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=pGFKhHab; arc=none smtp.client-ip=209.85.210.178 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="pGFKhHab" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-84a2c90e383so360252b3a.0 for ; Wed, 19 Aug 2026 20:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787197198; x=1787801998; 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:content-type; bh=7E/S4XB2acY/X3wyUH1G5tFQ1Y+acuzsI52bp9Wzh/E=; b=pGFKhHabPWnyWjjiRhFSefW6SDt5dmk3UEXD4pFQh2dMPZ29x7JS+EQ0evCYjFacgP /T67vZgAYHTJ0+i1oDoJ227ngVqM3OGS0Xy8CVWx2KwbIh8ApC7DDvxEoWKwlPKa7r5S UdQ53zmKRJfikZE5s+gMz/dc9iGEvLQUdn3ZiQFIpM8laLH7My8QU//8viSO1fhpD+4V 039Z4R4VdSKA8Jhr0yFF8DFD+pKID592bd0P9XZQTBaothQFjPn4LrSGpxanJszGPc3b zCmYUbIOye9XDXNA3AgDEkUeZ9yjMzIsjUY3adVnqrAZuMXyJ7CC5a3gKbq+CkVvttvH IDBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787197198; x=1787801998; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=7E/S4XB2acY/X3wyUH1G5tFQ1Y+acuzsI52bp9Wzh/E=; b=bPV0yzoq/W+GGBNJ+CJq6BK0H7fX6WyxAuCxWHNXNlCudwH2vEpSVpmfdYlgUuMpcE KMTiTaPWaB/TNiiRE7pxdyqFmPbX8iMwLTcppILci7stnJX5xf0xRbc3bHBOOl2Hl9k/ NpiMO5coDCs0mBdDnUbp05DvVZFaKXeDpfQZEeC/E9PgLNCtiKwnQAtF2rjEiZoHB6Ur xkqFy6fmh+aDCjc9cE2lNL20HT5+kqOwBC9q7kLQbeX0nEic0ouV2tIGlIasFkCw9aMk ejSUSt/vgbtsAa7qHA35PuXQcTVkjDWs9nam0bPmha239VQ3zwDEBP7mzHr4/h8aGFiM 9IlQ== X-Forwarded-Encrypted: i=1; AHgh+RpOkHsqD7oR4Owen1KaMbCjRSvqhNjBUdWWVt1Cfnb/KvUAF7dXNLHFoVCUrsMkfZZb9TySrK/MaqyPxCw=@vger.kernel.org X-Gm-Message-State: AOJu0YypKsbm0+x3fWeGorQsc4LINU/alIUtwjWt2lYlozlf1saNdram t35smYLVJR8mWBNyeRZ+dnunGP2Jox3BeCZUBt6K5CUEbkQ/RIDwZh4IM/tdb1E4 X-Gm-Gg: AR+sD13gOZECQnUVWTDE5bLrwh3olqWPIYfGdrqz4WLvDQtMSR0CzZlWhuoPDg6bI/N WOY0UdSqQXLPnKeJST+wC57gm+DYNDEFPhc9CknT/N+zEWeBtylbnd0AuS6/4ctGaPt9V7yp7WH SIMDOGpPRHtibtfftetTKBQ+J8BH41eLbvFd3OQI7hQxKKsbHLljEUGl+tYBiXDNNKXn1v2OY57 p1H9ctENbZDtWa8vYovaFBUA12J0/wi+Y4XJUHL3EPGKHVZtP09Vb6NQSiTuICjyUciLkzL2q6+ hOv2xoDRB25Eo2FMww7prHUKzykq9Ng2MhzIrq9TCz42yqfOPoF2F8S73F4ju1pWq+S3yydNUuy wNG4qk66wcU+jZMlDT/hDlLv/jF/ja6RnxJ73qET0Tn0+ViGvmPoLf8yRDo0fxCVpWYTaUB9wgQ L4kn0vKwkaxR5qd01oQUr0V9QAQ2im8xgrkl9PbPtMQwpTNQ4/1S5yuhvyAjja/JrpD4Bt/2xJ X-Received: by 2002:a05:6a00:f0c:b0:848:48d0:934 with SMTP id d2e1a72fcca58-851dfa91bbfmr3900215b3a.18.1787197197723; Wed, 19 Aug 2026 20:39:57 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cc1556a093dsm1260765a12.29.2026.08.19.20.39.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2026 20:39:57 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: Jaeyoung Chung , dwmw2@infradead.org, linux-mtd@lists.infradead.org, richard@nod.at Cc: Zhan Xusheng , kees@kernel.org, linux-kernel@vger.kernel.org, eulgyukim@snu.ac.kr Subject: Re: [BUG] general protection fault in jffs2_xattr_delete_inode Date: Thu, 20 Aug 2026 11:39:49 +0800 Message-ID: <20260820033950.1045382-1-zhanxusheng@xiaomi.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260819182805.4020838-1-jjy600901@snu.ac.kr> References: <20260819182805.4020838-1-jjy600901@snu.ac.kr> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Thu, 20 Aug 2026 03:28:04 +0900, Jaeyoung Chung wrote: > We have not analyzed the root cause, so we do not have a proposed fix > to offer. f->inocache is never initialised, and jffs2_new_inode() has two error paths that evict the inode before it gets assigned. Your log says it outright. RSI is the ic argument: RSI: 6464646464646464 RBX: 646464646464648c 1f: 48 8d 5e 28 lea 0x28(%rsi),%rbx 0x64 is 'd', and th_churn() does memset(p + 1, 'a' + (idx & 7), 3998) with idx 3. So ic is not a stale pointer to anything, it is the pathname bytes that thread left lying in the page the inode was later carved from. With CONFIG_JFFS2_FS_XATTR the 0x28 is pino_nlink, so the faulting access is the ic->pino_nlink of xattr.c:602. Nothing initialises that field. jffs2_inode_cachep has a constructor, and jffs2_i_init_once() only does mutex_init(), target = NULL and inode_init_once(). jffs2_alloc_inode() allocates with plain GFP_KERNEL, so no zeroing. jffs2_init_inode_info() sets seven fields and inocache is not among them. inocache also sits before vfs_inode in the struct, so inode_init_always() does not reach it. On this path f->inocache is assigned only by jffs2_do_new_inode(), write.c:35. Both of these return before that, and both then do make_bad_inode() and iput(): fs.c:459 jffs2_init_acl_pre() fails fs.c:466 jffs2_do_new_inode() fails in jffs2_alloc_inode_cache(), write.c:28 Either is an allocation failure, so fail-nth reaches both. The inode is unhashed, so inode_generic_drop() makes iput() evict it, which is the evict() -> jffs2_do_clear_inode() -> jffs2_xattr_delete_inode() in your trace. The mdelay() before new_inode() gives the churn threads a window to leave their bytes where the inode is then carved from. mtd/next has the same jffs2_init_inode_info(), so: --- a/fs/jffs2/os-linux.h +++ b/fs/jffs2/os-linux.h @@ -55,6 +55,7 @@ static inline void jffs2_init_inode_info(struct jffs2_inode_info *f) f->metadata = NULL; f->dents = NULL; f->target = NULL; + f->inocache = NULL; f->flags = 0; f->usercompr = 0; } Both callers assign inocache immediately afterwards, jffs2_do_read_inode() at readinode.c:1335 as its first act and jffs2_do_new_inode() at write.c:35, and jffs2_xattr_delete_inode() returns early on a NULL ic, so the read path is unaffected. I have not run your reproducer, so please confirm it on your setup before this goes out as a patch. Thanks, Zhan Xusheng