On Tue, Feb 16, 2021 at 04:34:27PM +0100, Greg KH wrote: > On Tue, Feb 16, 2021 at 04:15:46PM +0100, David Sterba wrote: > > On Tue, Feb 16, 2021 at 03:50:36PM +0100, Greg KH wrote: > > > On Tue, Feb 16, 2021 at 02:40:31PM +0000, fdmanana@xxxxxxxxxx wrote: > > > As this is a one-off patch, I need the btrfs maintainers to ack this and > > > really justify why we can't take the larger patch or patch series here > > > instead, as that is almost always the correct thing to do instead. > > > > Acked-by: David Sterba <dsterba@xxxxxxxx> > > > > The full backport would be patches > > > > ecfdc08b8cc6 btrfs: remove dio iomap DSYNC workaround > > a42fa643169d btrfs: call iomap_dio_complete() without inode_lock > > 502756b38093 btrfs: remove btrfs_inode::dio_sem > > e9adabb9712e btrfs: use shared lock for direct writes within EOF > > c35237063340 btrfs: push inode locking and unlocking into buffered/direct write > > a14b78ad06ab btrfs: introduce btrfs_inode_lock()/unlock() > > b8d8e1fd570a btrfs: introduce btrfs_write_check() > > > > and maybe more. > > > > $ git diff b8d8e1fd570a^..ecfdc08b8cc6 | diffstat > > btrfs_inode.h | 10 - > > ctree.h | 8 + > > file.c | 338 +++++++++++++++++++++++++++------------------------------- > > inode.c | 96 +++++++--------- > > transaction.h | 1 > > 5 files changed, 213 insertions(+), 240 deletions(-) > > > > That seems too much for a backport, the fix Filipe implemented is > > simpler and IMO qualifies as the exceptional stable-only patch. > > Why is that too much? For 7 patches that's a small overall diffstat. > And you match identically what is upstream in Linus's tree. That means > over time, backporting fixing is much easier, and understanding the code > for everyone is simpler. The changes are not trivial and touch eg. inode locking and other subsystems (iomap), so they're not self contained inside btrfs. And the list of possibly related patches is not entirely known at this moment, the above is an example that was obvious, but Filipe has expressed doubts that it's complete and I agree. Backporting them to 5.10.x would need same amount of testing and validation that the 5.11 version got during the whole development cycle. > It's almost always better to track what is in Linus's tree than to do > one-off patches as 95% of the time we do one-off patches they are buggy > and cause problems as no one else is running them. While I understand that concern in general, in this case it's trading changes by lots of code with a targeted fix with a reproducer, basically fixing the buggy error handling path. > So how about sending the above backported series instead please. Considering the risk I don't want to do that.
