From: Sasha Levin <sashal@kernel.org>
To: Sasha Levin <sashal@kernel.org>
To: Filipe Manana <fdmanana@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: stable@vger.kernel.org
Subject: Re: [PATCH] Btrfs: fix assertion failure during fsync and use of stale transaction
Date: Thu, 12 Sep 2019 07:30:45 +0000 [thread overview]
Message-ID: <20190912073046.47C2020830@mail.kernel.org> (raw)
In-Reply-To: <20190910142649.19808-1-fdmanana@kernel.org>
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: 4.4+
The bot has tested the following trees: v5.2.14, v4.19.72, v4.14.143, v4.9.192, v4.4.192.
v5.2.14: Build OK!
v4.19.72: Failed to apply! Possible dependencies:
6b5fc433a7ad ("Btrfs: fix fsync after succession of renames of different files")
a3baaf0d786e ("Btrfs: fix fsync after succession of renames and unlink/rmdir")
b8aa330d2acb ("Btrfs: improve performance on fsync of files with multiple hardlinks")
v4.14.143: Failed to apply! Possible dependencies:
0d836392cadd ("Btrfs: fix mount failure after fsync due to hard link recreation")
1f250e929a9c ("Btrfs: fix log replay failure after unlink and link combination")
6b5fc433a7ad ("Btrfs: fix fsync after succession of renames of different files")
8d9e220ca084 ("btrfs: simplify IS_ERR/PTR_ERR checks")
a3baaf0d786e ("Btrfs: fix fsync after succession of renames and unlink/rmdir")
b8aa330d2acb ("Btrfs: improve performance on fsync of files with multiple hardlinks")
v4.9.192: Failed to apply! Possible dependencies:
0b246afa62b0 ("btrfs: root->fs_info cleanup, add fs_info convenience variables")
0d836392cadd ("Btrfs: fix mount failure after fsync due to hard link recreation")
1f250e929a9c ("Btrfs: fix log replay failure after unlink and link combination")
4791c8f19c45 ("btrfs: Make btrfs_check_ref_name_override take btrfs_inode")
6b5fc433a7ad ("Btrfs: fix fsync after succession of renames of different files")
a3baaf0d786e ("Btrfs: fix fsync after succession of renames and unlink/rmdir")
cf8cddd38bab ("btrfs: don't abuse REQ_OP_* flags for btrfs_map_block")
da17066c4047 ("btrfs: pull node/sector/stripe sizes out of root and into fs_info")
db0a669fb002 ("btrfs: Make btrfs_add_link take btrfs_inode")
de143792253e ("btrfs: struct btrfsic_state->root should be an fs_info")
fb456252d3d9 ("btrfs: root->fs_info cleanup, use fs_info->dev_root everywhere")
v4.4.192: Failed to apply! Possible dependencies:
0132761017e0 ("btrfs: fix string and comment grammatical issues and typos")
09cbfeaf1a5a ("mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros")
0b246afa62b0 ("btrfs: root->fs_info cleanup, add fs_info convenience variables")
0d836392cadd ("Btrfs: fix mount failure after fsync due to hard link recreation")
0e749e54244e ("dax: increase granularity of dax_clear_blocks() operations")
1f250e929a9c ("Btrfs: fix log replay failure after unlink and link combination")
44f714dae50a ("Btrfs: improve performance on fsync against new inode after rename/unlink")
4791c8f19c45 ("btrfs: Make btrfs_check_ref_name_override take btrfs_inode")
52db400fcd50 ("pmem, dax: clean up clear_pmem()")
6b5fc433a7ad ("Btrfs: fix fsync after succession of renames of different files")
781feef7e6be ("Btrfs: fix lockdep warning about log_mutex")
a3baaf0d786e ("Btrfs: fix fsync after succession of renames and unlink/rmdir")
b2e0d1625e19 ("dax: fix lifetime of in-kernel dax mappings with dax_map_atomic()")
bb7ab3b92e46 ("btrfs: Fix misspellings in comments.")
cf8cddd38bab ("btrfs: don't abuse REQ_OP_* flags for btrfs_map_block")
d1a5f2b4d8a1 ("block: use DAX for partition table reads")
db0a669fb002 ("btrfs: Make btrfs_add_link take btrfs_inode")
de143792253e ("btrfs: struct btrfsic_state->root should be an fs_info")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
next prev parent reply other threads:[~2019-09-12 7:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-10 14:26 [PATCH] Btrfs: fix assertion failure during fsync and use of stale transaction fdmanana
2019-09-11 16:04 ` Josef Bacik
2019-09-12 7:30 ` Sasha Levin [this message]
2019-09-12 8:02 ` Filipe Manana
2019-09-16 12:59 ` Filipe Manana
2019-09-16 15:13 ` Greg KH
2019-09-12 11:10 ` Nikolay Borisov
2019-09-12 11:24 ` Filipe Manana
2019-09-12 11:35 ` Nikolay Borisov
2019-09-12 11:58 ` Josef Bacik
2019-09-12 13:17 ` Filipe Manana
2019-09-12 12:18 ` Josef Bacik
2019-09-12 13:19 ` Filipe Manana
2019-09-12 15:14 ` Josef Bacik
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=20190912073046.47C2020830@mail.kernel.org \
--to=sashal@kernel.org \
--cc=stable@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.