From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E5F1C369AB for ; Tue, 15 Apr 2025 11:17:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABEFE2800E0; Tue, 15 Apr 2025 07:17:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A6E352800BD; Tue, 15 Apr 2025 07:17:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C1182800E0; Tue, 15 Apr 2025 07:17:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6A9722800BD for ; Tue, 15 Apr 2025 07:17:36 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 02AFA121230 for ; Tue, 15 Apr 2025 11:17:36 +0000 (UTC) X-FDA: 83336027754.01.CD70A07 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf01.hostedemail.com (Postfix) with ESMTP id A0C2540008 for ; Tue, 15 Apr 2025 11:17:34 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=yVw1bluX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=AwZv7N+J; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=yVw1bluX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=AwZv7N+J; dmarc=none; spf=pass (imf01.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744715855; a=rsa-sha256; cv=none; b=Q10oSm8ngAS5lYJ4CbbGZaAqVDxmwQvtEyFlU5BQWnPI4nCEVR92Ue3MgnNbFeVPi1pHnW D8jZdYEd+f0Gm5GXFn1ciD+QMkdCA2Z7T1PZtx6ambaLZyWjDNBmyIxmwrmSWP8+OpCof3 vVKdSVU5msLJ9TsLssYIVaOlT709Q7g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744715855; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/GvslLrS6yzAU1HTA1lFcJoSPQOpIR7dPkztEx/wErA=; b=34opGirVfRD7VuxGjUjzJPYbJJsnPy1NvKhO0Wl9IIYtIwJucSZaLYF/VDbjuv8jV7I2Ye pj2ZVEIKFanKv+tL2LayQh8fIbGaS5+h0LufkZ2mi7IWINM8n/14TdnR60m/qyYXETZqRB MT1gvdYgz+v4fc70RYCKqrOglgUToM4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=yVw1bluX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=AwZv7N+J; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=yVw1bluX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=AwZv7N+J; dmarc=none; spf=pass (imf01.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=jack@suse.cz Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B2F161F38D; Tue, 15 Apr 2025 11:17:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1744715852; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/GvslLrS6yzAU1HTA1lFcJoSPQOpIR7dPkztEx/wErA=; b=yVw1bluXlIPW04+c0uRSmRxLmU/S5ps6gxL/BXeGQIJAsYRYnu8J6t48a7oP3zbR1oDC2U ZlR3I9/U6JrA93d6AtmXvjA351LV/N1yEzAFhJ4QCx63+x1JAB8IZBmMlt/O3TGntGIeQy WKJIMlJt3oxSZnhDYsWCP3ybsw4r6nE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1744715852; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/GvslLrS6yzAU1HTA1lFcJoSPQOpIR7dPkztEx/wErA=; b=AwZv7N+JXO9aMqVwoSYYuvg+sjJ8dw9wMYZbwgqFZckyoBFHWXb95x4bubtDhQeRjes/ml rFvYsBbphrY5hRDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1744715852; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/GvslLrS6yzAU1HTA1lFcJoSPQOpIR7dPkztEx/wErA=; b=yVw1bluXlIPW04+c0uRSmRxLmU/S5ps6gxL/BXeGQIJAsYRYnu8J6t48a7oP3zbR1oDC2U ZlR3I9/U6JrA93d6AtmXvjA351LV/N1yEzAFhJ4QCx63+x1JAB8IZBmMlt/O3TGntGIeQy WKJIMlJt3oxSZnhDYsWCP3ybsw4r6nE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1744715852; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/GvslLrS6yzAU1HTA1lFcJoSPQOpIR7dPkztEx/wErA=; b=AwZv7N+JXO9aMqVwoSYYuvg+sjJ8dw9wMYZbwgqFZckyoBFHWXb95x4bubtDhQeRjes/ml rFvYsBbphrY5hRDA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A1917137A5; Tue, 15 Apr 2025 11:17:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 8R9tJ0xA/mfreQAAD6G6ig (envelope-from ); Tue, 15 Apr 2025 11:17:32 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 57650A0947; Tue, 15 Apr 2025 13:17:28 +0200 (CEST) Date: Tue, 15 Apr 2025 13:17:28 +0200 From: Jan Kara To: Luis Chamberlain Cc: Jan Kara , brauner@kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, riel@surriel.com, dave@stgolabs.net, willy@infradead.org, hannes@cmpxchg.org, oliver.sang@intel.com, david@redhat.com, axboe@kernel.dk, hare@suse.de, david@fromorbit.com, djwong@kernel.org, ritesh.list@gmail.com, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org, gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com, syzbot+f3c6fda1297c748a7076@syzkaller.appspotmail.com Subject: Re: [PATCH v2 1/8] migrate: fix skipping metadata buffer heads on migration Message-ID: <6qzm6z64hcrhbapzekg2eil5poi34tngghrumwoiaz2x25ogce@gatjy6egc2n3> References: <20250410014945.2140781-1-mcgrof@kernel.org> <20250410014945.2140781-2-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A0C2540008 X-Stat-Signature: 1embgc3t3kqh1kgtgft3dwnm1howpen8 X-Rspam-User: X-HE-Tag: 1744715854-444346 X-HE-Meta: U2FsdGVkX1+86uIjl7PSkSkak9piipvRkmqbZd8PbiC44FIW1ZtJ83nTzTnLgBsMl0baCnDdS3LnTVA7a/3iPe+aoi0Kivq+J4aKC0yWsavBbvITXeLrYk9RacIQCkrh/0jONBtY2tFDoAN3XcZeFIayHwmdQlBPbaHrs3hAV02phFiYmXDDxotOgj6x3a+osXLzFwDoKAsb/0p4eFmi31QeEDM+Z5soAshvNKGL/TduY4W1sRCqFjVtukVaxFT90PGC/h8Sv46+B5ENKB3d6xFJrn2jPqoFDLZgbSZVhn55XKwv7DjUqvWYz6p33oNPFpVnqwwzi2swfNtOwD+UVjG8yReWde0RaxVxnsGGlz5/BnMOrUmThIAoGJz4672hG4fPjppzzi//4bJPpnopEkW1refXs59CC1ZytYyvOnALg9thcqnQ4oaBni+5CvOGtxrwaBr/G9g0hV30R+MQqz8e325z4clbK+C3p7xvPETq07Uiabr3JTB7X+tNth04c0J+63bmrY8MUp5z7bdLvATYgQoqJGzo3MaU7Slp9d1/80t2BS+PMxeSVIMhTx2ubvP8VavctbjUUqTrYsab0FZzJdQNxaUrtykIYw/gIIBZTkgCxdVs17A5hzlpw4hhpk3ctSib3kX+6Vx40HnQIPR2syp+ooyFHqfq0tg2O2LlXkvTvHjVwaTRDOzLBn1fWqQV1Sd9KIFjEwvvMeSl0KWHUiKPZkO15t84J8xbovj0nOD84c99F2Ie11zlgNxIeVCPN3+1HIMexTeSwpJw0hfq+N2/Y/5ovoXLe1OaaZuJAGW+XJ+JaRmB8jxNkVZCRCbzA1VGBsqkavPQjLhPXN2I+J2+03e7H5Xplz+a/mGgKwNbRuDQjAtO0xZb7GuXASeJOR33Jw/VzCrMqL2P1lKEdGg6SF6D7/lkoGVgaHGuH8DPyoI2xd5dvoNKEAlEnqG0MZSvqwKsnQpb1l2 AUf8Hmce Qc6PhZoVi0wnP/yNUW42x+trMrB4b9w2D3F8H0JPJzYE/y1EworYXq6jKgTt9pJlCSTAu3Lrc6RKk8uJ21/eSyfqofRQpjojTrMRE7TK65ieOo/C5y5nI1izbg//MfAyvSuGG1NmbIEc5OlNX92rXNYanmqXhj2XcqVOJG6AOFTOw3mtWA9EUHzu7XZ0/wAudzTg7a0yseznukiGincOphFGt+hJRc+s8N+NYFZzhA4dtcy+EfVfhVs7sUlBNYCNHf5bh+lleYet42oEYkZcIvbNNbGWcr9GoA2x3Au119/xm7dIcK8IJbPi4nYg/OY960HgGZvftH3CCWlzGgCOOW88blWqx25c3ybudoq8BLeNKcOJh48umEx+z36/BYtlQd9CjX6JRLRbn75LjdAvpOO2/HAH65pZR0Zl/9+FH73P3G5Z/QaQ81oI25w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon 14-04-25 15:19:33, Luis Chamberlain wrote: > On Mon, Apr 14, 2025 at 02:09:46PM -0700, Luis Chamberlain wrote: > > On Thu, Apr 10, 2025 at 02:05:38PM +0200, Jan Kara wrote: > > > > @@ -859,12 +862,12 @@ static int __buffer_migrate_folio(struct address_space *mapping, > > > > } > > > > bh = bh->b_this_page; > > > > } while (bh != head); > > > > + spin_unlock(&mapping->i_private_lock); > > > > > > No, you've just broken all simple filesystems (like ext2) with this patch. > > > You can reduce the spinlock critical section only after providing > > > alternative way to protect them from migration. So this should probably > > > happen at the end of the series. > > > > So you're OK with this spin lock move with the other series in place? > > > > And so we punt the hard-to-reproduce corruption issue as future work > > to do? Becuase the other alternative for now is to just disable > > migration for jbd2: > > > > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > > index 1dc09ed5d403..ef1c3ef68877 100644 > > --- a/fs/ext4/inode.c > > +++ b/fs/ext4/inode.c > > @@ -3631,7 +3631,6 @@ static const struct address_space_operations ext4_journalled_aops = { > > .bmap = ext4_bmap, > > .invalidate_folio = ext4_journalled_invalidate_folio, > > .release_folio = ext4_release_folio, > > - .migrate_folio = buffer_migrate_folio_norefs, > > .is_partially_uptodate = block_is_partially_uptodate, > > .error_remove_folio = generic_error_remove_folio, > > .swap_activate = ext4_iomap_swap_activate, > > BTW I ask because.. are your expectations that the next v3 series also > be a target for Linus tree as part of a fix for this spinlock > replacement? I have no problem with this (the use of data=journal mode is rare) but I suspect this won't fix the corruption you're seeing because that happens in the block device mapping. So to fix that you'd have to disable page migration for block device mappings (i.e., do the above with def_blk_aops) and *that* will make a lot of people unhappy. Honza -- Jan Kara SUSE Labs, CR