From nobody Mon Feb 9 01:44:22 2026 Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) (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 B505430BB84 for ; Fri, 6 Feb 2026 13:10:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.70 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770383445; cv=none; b=Vm99PShjyhOuFq5XnNz/a/XdsKhe+HFA0Xjbc+vqvwwTsyLr5w+9q70ANiFkr5HGJfF3bODO5jEPy3eohF7YDVACv0us2ExGC5n6n2lJ9BnT2ovfci+mJC0qThFlZZ4ZRP7wE13kzpXvXN/6WeBRyA0OH7z1cJnl8P6H4OvSEmY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770383445; c=relaxed/simple; bh=n4PwZoA38tcGVm7zfjkcQqQHgAGmtgMtDDqsxsDppMY=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=suSWn65hmcYZjxblQuOYYzHXTrnWDiF7ybnYr8Y0q4Cu8xR06Jg68EVEX70/L6kDaVlKgiFRMQ8gsw8tUkBfwJ44SBZiMETkBXOwknnRciwgAkrW4CROM7Gj4FaYf8HDBslFOX384Pyh5PTx7UKc/+NvMtg/dsoNQ28IPfrTOAc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.161.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oo1-f70.google.com with SMTP id 006d021491bc7-662b9af3988so5859510eaf.1 for ; Fri, 06 Feb 2026 05:10:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770383444; x=1770988244; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xeu2/Wg174RUEurJFiMhBUGCWqKLOe9Gtyh4+ZFB4ek=; b=vrOa/yokm+w3dpxa0Lsq5BXlVnMsCSYc4h/hWd0/Xr6BdOFF+ctQbS3THdHKSh7Nhi IICjuDNKl82eYUAbuW6KMl6esbuszFR/g9gjdK18YbjgNp6OQK7qklmceD7hdJUocLcz e0WvIWGF2P3gzdEP4CHYn3f+Q2iTZB2hQKejDo4y5+9vw8rC4oH6f99QHj3Te7vmKQTv oJrYjbS5RoRcXw8w8poJkjp8C2c36aF/YGUZRElhXda59qGL9kLmTtlzKVleZKapAi46 W0EmZdGm3WDiP+A28VtA+UM6RrUPDfYLp7/nM5WegVLSgE2Slapj1E3RJpZzHjuqItzO IBpA== X-Gm-Message-State: AOJu0YyD7LQb44GUIGzzk/st05XRrlnL5fc5o6+O2I7F4fqiBqjWi97/ 9tAVi5h0GttghvuTJYrNT2okVGqMTpynB1RAKrK6w744gPhajGsnKmKPkUaHWgDDR0cDWTWGdXI n6N1WldYegGVJaB8qKJph33yWWcGg4undIp6tol+GJZCWHZkesOAzHGBZN7c= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:2291:b0:662:fd69:e0d5 with SMTP id 006d021491bc7-66d3569f597mr1075828eaf.73.1770383444612; Fri, 06 Feb 2026 05:10:44 -0800 (PST) Date: Fri, 06 Feb 2026 05:10:44 -0800 In-Reply-To: <6980e9ff.050a0220.16b13.00a9.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <6985e854.a00a0220.34fa92.002e.GAE@google.com> Subject: Forwarded: [PATCH] ext4: add debug logging for setattr size operations From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] ext4: add debug logging for setattr size operations Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= master Add debug printk to track when ext4_setattr() is called with ATTR_SIZE, logging the inode number, old size, new size, and whether the inode has inline data flag set. This is a diagnostic patch to investigate the crash reported by syzbot where a BUG_ON() fires in ext4_write_inline_data() due to inodes having the inline data flag set but claiming sizes far exceeding inline capacity. The hypothesis is that truncate() operations that grow file size are not properly converting inline data to extent-based storage, leaving inodes in an inconsistent state (inline flag set + large size). This debug output will confirm whether: 1. ext4_setattr() is called during truncate operations 2. The inline data flag remains set when size grows beyond capacity 3. Conversion to extent-based storage is missing from the truncate path Related-to: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=3D7de5fe447862fc37576f Signed-off-by: Deepanshu Kartikey --- fs/ext4/inode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 0c466ccbed69..ccaef3eb5a46 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -5886,7 +5886,8 @@ int ext4_setattr(struct mnt_idmap *idmap, struct dent= ry *dentry, loff_t oldsize =3D inode->i_size; loff_t old_disksize; int shrink =3D (attr->ia_size < inode->i_size); - + printk(KERN_WARNING "EXT4-fs DEBUG setattr: inode=3D%lu old_size=3D%lld = new_size=3D%lld has_inline=3D%d\n", + inode->i_ino,oldsize,attr->ia_size,ext4_has_inline_data(inode) ? 1 : 0); if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) { struct ext4_sb_info *sbi =3D EXT4_SB(inode->i_sb); =20 --=20 2.43.0