Message ID | 20201207183021.22752-1-vgoyal@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | virtiofsd: Fix lo_flush() and inode->posix_lock init | expand |
Patchew URL: https://patchew.org/QEMU/20201207183021.22752-1-vgoyal@redhat.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20201207183021.22752-1-vgoyal@redhat.com Subject: [PATCH 0/3] virtiofsd: Fix lo_flush() and inode->posix_lock init === TEST SCRIPT BEGIN === #!/bin/bash git rev-parse base > /dev/null || exit 0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram ./scripts/checkpatch.pl --mailback base.. === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 From https://github.com/patchew-project/qemu * [new tag] patchew/20201207183021.22752-1-vgoyal@redhat.com -> patchew/20201207183021.22752-1-vgoyal@redhat.com Switched to a new branch 'test' 86f3bb1 virtiofsd: Check file type in lo_flush() 92a5c9d virtiofsd: Disable posix_lock hash table if remote locks are not enabled fbdcaf1 virtiofsd: Set up posix_lock hash table for root inode === OUTPUT BEGIN === 1/3 Checking commit fbdcaf172aed (virtiofsd: Set up posix_lock hash table for root inode) ERROR: suspect code indent for conditional statements (4, 7) #40: FILE: tools/virtiofsd/passthrough_ll.c:3401: + if (lo->root.posix_locks) + g_hash_table_destroy(lo->root.posix_locks); ERROR: braces {} are necessary for all arms of this statement #40: FILE: tools/virtiofsd/passthrough_ll.c:3401: + if (lo->root.posix_locks) [...] total: 2 errors, 0 warnings, 19 lines checked Patch 1/3 has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. 2/3 Checking commit 92a5c9d35c7d (virtiofsd: Disable posix_lock hash table if remote locks are not enabled) 3/3 Checking commit 86f3bb1cf5b8 (virtiofsd: Check file type in lo_flush()) === OUTPUT END === Test command exited with code: 1 The full log is available at http://patchew.org/logs/20201207183021.22752-1-vgoyal@redhat.com/testing.checkpatch/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-devel@redhat.com
Hi Vivek, On 12/07/20 19:30, Vivek Goyal wrote: > Laszlo is writing a virtiofs client for OVMF and noticed that if he > sends fuse FLUSH command for directory object, virtiofsd crashes. > virtiofsd does not expect a FLUSH arriving for a directory object. > > This patch series has one of the patches which fixes that. It also > has couple of posix lock fixes as a result of lo_flush() related debugging. > > Vivek Goyal (3): > virtiofsd: Set up posix_lock hash table for root inode > virtiofsd: Disable posix_lock hash table if remote locks are not > enabled > virtiofsd: Check file type in lo_flush() > > tools/virtiofsd/passthrough_ll.c | 54 +++++++++++++++++++++++--------- > 1 file changed, 39 insertions(+), 15 deletions(-) > I put back the (wrong) FLUSH for the root dir into my code temporarily, to reproduce the crash (it does, with v5.2.0-rc4). Then I applied your series [*], and retested. [*] I'm unsure about the email you sent in response to 1/3, namely <https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg01504.html>; I ignored that when applying the patches. Indeed now I get a graceful -EBADF: [13316825985314] [ID: 00000004] unique: 60, opcode: FLUSH (25), nodeid: 1, insize: 64, pid: 1 [13316825993517] [ID: 00000004] unique: 60, error: -9 (Bad file descriptor), outsize: 16 For whichever patch in the series my testing is relevant: Tested-by: Laszlo Ersek <lersek@redhat.com> (I'm having some difficulty figuring out which patch(es) should carry my T-b. - I think I didn't really test patch#2 with the above, so that one should likely not get the T-b - I think patch#3 is what I really tested. - But, if that's the case, doesn't patch#3 make the fix in patch#1 untestable, in my scenario? I believe the code is no longer reached in lo_flush(), due to patch#3, where the change from patch#1 would matter. Patch#1 seems correct, and the last paragraph of its commit message relevant, but I think my testing currently only covered patch#3. I'll let you decide where to apply my T-b.) Thanks! Laszlo
On Tue, Dec 08, 2020 at 05:51:34AM +0100, Laszlo Ersek wrote: > Hi Vivek, > > On 12/07/20 19:30, Vivek Goyal wrote: > > Laszlo is writing a virtiofs client for OVMF and noticed that if he > > sends fuse FLUSH command for directory object, virtiofsd crashes. > > virtiofsd does not expect a FLUSH arriving for a directory object. > > > > This patch series has one of the patches which fixes that. It also > > has couple of posix lock fixes as a result of lo_flush() related debugging. > > > > Vivek Goyal (3): > > virtiofsd: Set up posix_lock hash table for root inode > > virtiofsd: Disable posix_lock hash table if remote locks are not > > enabled > > virtiofsd: Check file type in lo_flush() > > > > tools/virtiofsd/passthrough_ll.c | 54 +++++++++++++++++++++++--------- > > 1 file changed, 39 insertions(+), 15 deletions(-) > > > > I put back the (wrong) FLUSH for the root dir into my code temporarily, to reproduce the crash (it does, with v5.2.0-rc4). > > Then I applied your series [*], and retested. > > [*] I'm unsure about the email you sent in response to 1/3, namely <https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg01504.html>; I ignored that when applying the patches. Hi Laszlo, Thank you for the testing. I reposed patch 1 to take care of coding style issues. Functionally both the versions are same. > > Indeed now I get a graceful -EBADF: > > [13316825985314] [ID: 00000004] unique: 60, opcode: FLUSH (25), nodeid: 1, insize: 64, pid: 1 > [13316825993517] [ID: 00000004] unique: 60, error: -9 (Bad file descriptor), outsize: 16 > > For whichever patch in the series my testing is relevant: > > Tested-by: Laszlo Ersek <lersek@redhat.com> > > (I'm having some difficulty figuring out which patch(es) should carry my T-b. > > - I think I didn't really test patch#2 with the above, so that one should likely not get the T-b > > - I think patch#3 is what I really tested. > > - But, if that's the case, doesn't patch#3 make the fix in patch#1 untestable, in my scenario? I believe the code is no longer reached in lo_flush(), due to patch#3, where the change from patch#1 would matter. Patch#1 seems correct, and the last paragraph of its commit message relevant, but I think my testing currently only covered patch#3. > > I'll let you decide where to apply my T-b.) David Gilbert can add your Tested-by: while applying this patch series. I think adding it to patch 3 makes most sense. Thanks Vivek