All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Carlos Maiolino <cem@kernel.org>, linux-xfs@vger.kernel.org
Subject: Re: cleanup log item formatting
Date: Thu, 19 Jun 2025 16:58:47 +1000	[thread overview]
Message-ID: <aFO1J-1SO2Sn6GgV@dread.disaster.area> (raw)
In-Reply-To: <20250610051644.2052814-1-hch@lst.de>

On Tue, Jun 10, 2025 at 07:14:57AM +0200, Christoph Hellwig wrote:
> Hi all,
> 
> I dug into a rabit hole about the log item formatting recently,
> and noticed that the handling of the opheaders is still pretty
> ugly because it leaks pre-delayed logging implementation
> details into the log item implementations.
> 
> The core of this series is to remove the to reserve space in the
> CIL buffers/shadow buffers for the opheaders that already were
> generated more or less on the fly by the lowlevel log write
> code anyway, but there's lots of other cleanups around it.

Another journal header corruption failure - I've hit the original
one I reported and this one a few times today:

[ 2217.226513] XFS (loop220): bad number of regions (33206) in inode log format  
[ 2217.231292] XFS: Assertion failed: 0, file: fs/xfs/xfs_log_recover.c, line: 2220
[ 2217.236193] ------------[ cut here ]------------                              
[ 2217.239216] kernel BUG at fs/xfs/xfs_message.c:102!                           
[ 2217.253064] Oops: invalid opcode: 0000 [#1] SMP NOPTI                         
[ 2217.253224] XFS (loop390): Unmounting Filesystem d3058266-1835-4b17-a51a-7276edbea3e9
[ 2217.267570] CPU: 31 UID: 0 PID: 1291175 Comm: mount Not tainted 6.15.0-dgc+ #339 PREEMPT(full) 
[ 2217.267574] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 2217.267577] RIP: 0010:assfail+0x3a/0x40                                       
[ 2217.267588] Code: 89 f1 48 89 fe 48 c7 c7 8a f7 ed 82 48 c7 c2 f2 85 e8 82 e8 c8 fc ff ff 80 3d 19 b6 50 03 01 74 09 0f 0b 5d c3 cc cc cc cc cc <0f> 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
[ 2217.285594] RSP: 0018:ffffc90028293980 EFLAGS: 00010246                       
[ 2217.285598] RAX: ad5e2cca7393a700 RBX: 0000000000000000 RCX: ad5e2cca7393a700 
[ 2217.285600] RDX: ffffc90028293848 RSI: 000000000000000a RDI: ffffffff82edf78a 
[ 2217.285602] RBP: ffffc90028293980 R08: 0000000000000000 R09: 000000000000000a 
[ 2217.285603] R10: 0000000000000000 R11: 0000000000000021 R12: ffff8888e4108c80 
[ 2217.285605] R13: 00000000000000b0 R14: ffff8889008165c0 R15: ffff8889008165f0 
[ 2217.285609] FS:  00007fc3143ce840(0000) GS:ffff88909a83e000(0000) knlGS:0000000000000000
[ 2217.285612] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033                 
[ 2217.285614] CR2: 00007ff4b56f0000 CR3: 000000013aaab000 CR4: 0000000000350ef0 
[ 2217.285619] Call Trace:                                                       
[ 2217.285622]  <TASK>                                                           
[ 2217.285625]  xlog_recover_add_to_trans+0x24e/0x2a0                            
[ 2217.294934]  xlog_recovery_process_trans+0x67/0x100                           
[ 2217.294937]  xlog_recover_process_ophdr+0xdd/0x140                            
[ 2217.294939]  xlog_recover_process_data+0x9b/0x160                             
[ 2217.294942]  xlog_recover_process+0xb2/0x110                                  
[ 2217.294943]  xlog_do_recovery_pass+0x685/0x900                                
[ 2217.294946]  xlog_do_log_recovery+0x43/0xb0                                   
[ 2217.306831]  xlog_do_recover+0x2c/0x190                                       
[ 2217.306834]  xlog_recover+0x165/0x180                                         
[ 2217.306835]  xfs_log_mount+0x14d/0x270                                        
[ 2217.306843]  xfs_mountfs+0x3aa/0x990                                          
[ 2217.306846]  xfs_fs_fill_super+0x701/0x870                                    
[ 2217.306850]  ? __pfx_xfs_fs_fill_super+0x10/0x10                              
[ 2217.321294]  get_tree_bdev_flags+0x120/0x1a0                                  
[ 2217.321314]  get_tree_bdev+0x10/0x20                                          
[ 2217.321316]  xfs_fs_get_tree+0x15/0x20                                        
[ 2217.321319]  vfs_get_tree+0x28/0xe0                                           
[ 2217.321321]  vfs_cmd_create+0x5f/0xd0                                         
[ 2217.321326]  vfs_fsconfig_locked+0x50/0x130                                   
[ 2217.321329]  __se_sys_fsconfig+0x349/0x3d0                                    
[ 2217.321332]  __x64_sys_fsconfig+0x25/0x30                                     
[ 2217.321336]  x64_sys_call+0x3be/0x2f60 

I'm going to stop testing this branch now and leave it until the
next version is posted for review.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

      parent reply	other threads:[~2025-06-19  6:58 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-10  5:14 cleanup log item formatting Christoph Hellwig
2025-06-10  5:14 ` [PATCH 01/17] xfs: don't pass the old lv to xfs_cil_prepare_item Christoph Hellwig
2025-06-10  7:20   ` Carlos Maiolino
2025-06-10  5:14 ` [PATCH 02/17] xfs: cleanup the ordered item logic in xlog_cil_insert_format_items Christoph Hellwig
2025-06-10  7:56   ` Carlos Maiolino
2025-06-10 13:32     ` Christoph Hellwig
2025-06-10 14:00       ` Carlos Maiolino
2025-06-10  5:15 ` [PATCH 03/17] xfs: use better names for size members in xfs_log_vec Christoph Hellwig
2025-06-10  9:07   ` Carlos Maiolino
2025-06-10  5:15 ` [PATCH 04/17] xfs: don't use a xfs_log_iovec for attr_item names and values Christoph Hellwig
2025-06-10  9:17   ` Carlos Maiolino
2025-06-10 13:33     ` Christoph Hellwig
2025-06-10  5:15 ` [PATCH 05/17] xfs: don't use a xfs_log_iovec for ri_buf in log recovery Christoph Hellwig
2025-06-11 10:33   ` Carlos Maiolino
2025-06-10  5:15 ` [PATCH 06/17] xfs: improve the ->iop_format interface Christoph Hellwig
2025-06-10  5:15 ` [PATCH 07/17] xfs: add a xlog_write_one_vec helper Christoph Hellwig
2025-06-10  5:15 ` [PATCH 08/17] xfs: set lv_bytes in xlog_write_one_vec Christoph Hellwig
2025-06-10  5:15 ` [PATCH 09/17] xfs: create ophdrs on the fly in xlog_write Christoph Hellwig
2025-06-10  5:15 ` [PATCH 10/17] xfs: special case continuation records in xlog_write_region a litte less Christoph Hellwig
2025-06-10  5:15 ` [PATCH 11/17] xfs: factor the split iclog handling out of xlog_write_partial Christoph Hellwig
2025-06-10  5:15 ` [PATCH 12/17] xfs: remove xlog_write_full Christoph Hellwig
2025-06-10  5:15 ` [PATCH 13/17] xfs: improve argument handling for the xlog_write helpers Christoph Hellwig
2025-06-10  5:15 ` [PATCH 14/17] xfs: remove the xlog_op_header_t typedef Christoph Hellwig
2025-06-10  5:15 ` [PATCH 15/17] xfs: remove the xfs_trans_header_t typedef Christoph Hellwig
2025-06-10  5:15 ` [PATCH 16/17] xfs: move the XLOG_REG_ constants out of xfs_log_format.h Christoph Hellwig
2025-06-10  5:15 ` [PATCH 17/17] xfs: move struct xfs_log_vec to xfs_log_priv.h Christoph Hellwig
2025-06-17 22:35 ` cleanup log item formatting Dave Chinner
2025-06-18  4:50   ` Christoph Hellwig
2025-06-18  9:24 ` Dave Chinner
2025-06-24 14:38   ` Christoph Hellwig
2025-06-19  6:58 ` Dave Chinner [this message]

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=aFO1J-1SO2Sn6GgV@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=cem@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    /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.