From: Dave Chinner <david@fromorbit.com>
To: kernel test robot <yujie.liu@intel.com>
Cc: Dave Chinner <dchinner@redhat.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org,
"Darrick J. Wong" <djwong@kernel.org>,
linux-xfs@vger.kernel.org
Subject: Re: [linus:master] [xfs] 304a68b9c6: WARNING:at_fs/iomap/buffered-io.c:#iomap_write_delalloc_release
Date: Wed, 1 Mar 2023 09:11:07 +1100 [thread overview]
Message-ID: <20230228221107.GD360264@dread.disaster.area> (raw)
In-Reply-To: <202302281653.51938721-yujie.liu@intel.com>
On Tue, Feb 28, 2023 at 04:40:01PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed WARNING:at_fs/iomap/buffered-io.c:#iomap_write_delalloc_release due to commit (built with gcc-11):
>
> commit: 304a68b9c63bbfc1f6e159d68e8892fc54a06067 ("xfs: use iomap_valid method to detect stale cached iomaps")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> [test failed on linux-next/master 058f4df42121baadbb8a980c06011e912784dbd2]
> in testcase: xfstests
> version: xfstests-i386-5a5e419-1_20220926
> with following parameters:
>
> disk: 4HDD
> fs: xfs
> test: generic-group-32
Which fstest was running at the time this warning was thrown?
>
> test-description: xfstests is a regression test suite for xfs and other files ystems.
> test-url: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
> on test machine: 8 threads Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (Skylake) with 28G memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
> [ 78.565703][ T59] ------------[ cut here ]------------
> [ 78.570983][ T59] WARNING: CPU: 4 PID: 59 at fs/iomap/buffered-io.c:984 iomap_write_delalloc_release (buffered-io.c:?)
Well, that's useless without the function offset or line number to
tell us what warning in that function triggered.
> [ 78.581265][ T59] Modules linked in: loop(E) dm_flakey(E) xfs(E) dm_mod(E) intel_rapl_msr(E) intel_rapl_common(E) btrfs(E) blake2b_generic(E) xor(E) raid6_pq(E) zstd_compress(E) x86_pkg_temp_thermal(E) libcrc32c(E) intel_powerclamp(E) crc32c_generic(E) coretemp(E) sd_mod(E) t10_pi(E) ipmi_devintf(E) kvm_intel(E) ipmi_msghandler(E) i915(E) crc64_rocksoft_generic(E) kvm(E) irqbypass(E) crc64_rocksoft(E) crc64(E) drm_buddy(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) drm_display_helper(E) cryptd(E) cec(E) mei_wdt(E) wmi_bmof(E) rapl(E) ahci(E) evdev(E) ttm(E) xhci_pci(E) intel_cstate(E) xhci_hcd(E) libahci(E) i2c_i801(E) mei_me(E) drm_kms_helper(E) syscopyarea(E) intel_uncore(E) usbcore(E) i2c_smbus(E) sysfillrect(E) libata(E) mei(E) sysimgblt(E) intel_pch_thermal(E) fb_sys_fops(E) usb_common(E) video(E) fan(E) thermal(E) wmi(E) acpi_pad(E) button(E) fuse(E) drm(E) configfs(E) autofs4(E)
> [ 78.661092][ T59] CPU: 4 PID: 59 Comm: kworker/u16:2 Tainted: G E 6.1.0-rc4-00008-g304a68b9c63b #1
This looks like a broken kernel install. Why are all the modules
tainted?
> [ 78.671542][ T59] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016
> [ 78.679578][ T59] Workqueue: loop0 loop_rootcg_workfn [loop]
> [ 78.685393][ T59] EIP: iomap_write_delalloc_release (buffered-io.c:?)
> [ 78.691449][ T59] Code: e8 cf 94 ed ff f0 ff 4b 1c 74 45 8b 45 e0 8b 40 20 83 c0 10 e8 ab 93 d8 ff 8d 65 f4 89 f0 5b 5e 5f 5d c3 0f 0b e9 f9 fd ff ff <0f> 0b e9 e0 fd ff ff 0f 0b 8b 45 cc 8b 4d f0 8b 55 d0 39 c8 89 d0
> All code
> ========
> 0: e8 cf 94 ed ff callq 0xffffffffffed94d4
> 5: f0 ff 4b 1c lock decl 0x1c(%rbx)
> 9: 74 45 je 0x50
> b: 8b 45 e0 mov -0x20(%rbp),%eax
> e: 8b 40 20 mov 0x20(%rax),%eax
> 11: 83 c0 10 add $0x10,%eax
> 14: e8 ab 93 d8 ff callq 0xffffffffffd893c4
> 19: 8d 65 f4 lea -0xc(%rbp),%esp
> 1c: 89 f0 mov %esi,%eax
> 1e: 5b pop %rbx
> 1f: 5e pop %rsi
> 20: 5f pop %rdi
> 21: 5d pop %rbp
> 22: c3 retq
> 23: 0f 0b ud2
> 25: e9 f9 fd ff ff jmpq 0xfffffffffffffe23
> 2a:* 0f 0b ud2 <-- trapping instruction
> 2c: e9 e0 fd ff ff jmpq 0xfffffffffffffe11
> 31: 0f 0b ud2
> 33: 8b 45 cc mov -0x34(%rbp),%eax
> 36: 8b 4d f0 mov -0x10(%rbp),%ecx
> 39: 8b 55 d0 mov -0x30(%rbp),%edx
> 3c: 39 c8 cmp %ecx,%eax
> 3e: 89 d0 mov %edx,%eax
>
> Code starting with the faulting instruction
> ===========================================
> 0: 0f 0b ud2
> 2: e9 e0 fd ff ff jmpq 0xfffffffffffffde7
> 7: 0f 0b ud2
> 9: 8b 45 cc mov -0x34(%rbp),%eax
> c: 8b 4d f0 mov -0x10(%rbp),%ecx
> f: 8b 55 d0 mov -0x30(%rbp),%edx
> 12: 39 c8 cmp %ecx,%eax
> 14: 89 d0 mov %edx,%eax
> [ 78.710792][ T59] EAX: 2335a000 EBX: 00000004 ECX: fffffffc EDX: 00000004
> [ 78.717707][ T59] ESI: 2335b000 EDI: 00000000 EBP: c3187c24 ESP: c3187bf0
> [ 78.724624][ T59] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010297
> [ 78.732056][ T59] CR0: 80050033 CR2: b7da00b0 CR3: 02350000 CR4: 003506f0
> [ 78.738971][ T59] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 78.745887][ T59] DR6: fffe0ff0 DR7: 00000400
> [ 78.750389][ T59] Call Trace:
> [ 78.753508][ T59] iomap_file_buffered_write_punch_delalloc (??:?)
> [ 78.760183][ T59] ? xfs_buffered_write_iomap_end (xfs_iomap.c:?) xfs
> [ 78.766541][ T59] xfs_buffered_write_iomap_end (xfs_iomap.c:?) xfs
What's with all the broken/missing function offsets and
file/line numbers in the stack trace?
Please fix your tooling - this report isn't useful with all the
offset/line number information being broken like this
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2023-02-28 22:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 8:40 [linus:master] [xfs] 304a68b9c6: WARNING:at_fs/iomap/buffered-io.c:#iomap_write_delalloc_release kernel test robot
2023-02-28 22:11 ` Dave Chinner [this message]
2023-03-02 8:39 ` Yujie Liu
2023-03-02 22:21 ` Dave Chinner
2023-03-03 6:13 ` Yujie Liu
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=20230228221107.GD360264@dread.disaster.area \
--to=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=yujie.liu@intel.com \
/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.