On Tue, Aug 14, 2018 at 11:53 PM, David Sterba <dste...@suse.cz> wrote: > On Tue, Aug 14, 2018 at 12:04:05PM -0700, Omar Sandoval wrote: >> On Mon, Jun 18, 2018 at 01:06:16PM +0200, David Sterba wrote: >> > On Fri, Jun 15, 2018 at 05:19:07PM +0100, Filipe Manana wrote: >> > > On Fri, Jun 15, 2018 at 4:54 PM, David Sterba <dste...@suse.cz> wrote: >> > > > On Mon, Jun 11, 2018 at 07:24:28PM +0100, fdman...@kernel.org wrote: >> > > >> From: Filipe Manana <fdman...@suse.com> >> > > >> Fixes: 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes") >> > > >> Reported-by: Vijay Chidambaram <vvija...@gmail.com> >> > > >> Signed-off-by: Filipe Manana <fdman...@suse.com> >> > > > >> > > > There are some warnings and possible lock up caused by this patch, the >> > > > 1/2 alone is ok but 1/2 + 2/2 leads to the following warnings. I >> > > > checked >> > > > twice, the patch base was the pull request ie. without any other 4.18 >> > > > stuff. >> > > >> > > Are you sure it's this patch? >> > > On top of for-4.18 it didn't cause any problems here, plus the trace >> > > below has nothing to do with renames, hard links or fsync at all - >> > > everything seems stuck on waiting for IO from dev replace. >> > >> > It was a false alert, sorry. Strange that the warnings appeared only in >> > the VM running both patches and not otherwise. >> > >> > Though the test did not directly use rename, the possible error scenario >> > I had in mind was some leftover from locking, error handling or state >> > that blocked umount of 011. >> >> Dave, are you sending this in for 4.19? I don't see it in your first >> pull request.
In another thread, related to the first patch in the series iirc, I specifically asked to not merge it. That's because I run twice (in the long period of nearly 2 months now) into a hang which could be caused by this patch. The traces were weird and only contained inexact lines that showed only the transaction kthread waiting forever on transaction commit. I recently found that I have hardware problems that were causing issues with qemu (stalls, ocassional crashes) so I'm hoping that's the cause but I still need to test it with long stress tests on good hardware. I don't mind getting it to linux-next in the meanwhile, but for 4.19 I would prefer to not include yet. > > Will send it in 2nd pull for 4.19. The patch is 2 months old and I don't > remember where it was lost on the way. I had some suspicions but turned > out to be false. Thanks for the reminder.