the 4.7 have the same behavior... capture file: https://desycloud.desy.de/public.php?service=files&t=5e26a8d73ed6aacbdbf49e4c8f1cc01a&download Tigran. ----- Original Message ----- > From: "Jeff Layton" <jlayton@xxxxxxxxxxxxxxx> > To: "Mkrtchyan, Tigran" <tigran.mkrtchyan@xxxxxxx>, "Linux NFS Mailing List" <linux-nfs@xxxxxxxxxxxxxxx> > Cc: "Trond Myklebust" <trond.myklebust@xxxxxxxxxxxxxxx> > Sent: Monday, May 30, 2016 7:58:15 PM > Subject: Re: Infinit LAYOUTGET with mmap > On Mon, 2016-05-30 at 17:51 +0200, Mkrtchyan, Tigran wrote: >> >> re-sending, as it never arrived.... >> >> ----- Original Message ----- >> > >> > From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@xxxxxxx> >> > To: "Linux NFS Mailing List" <linux-nfs@xxxxxxxxxxxxxxx> >> > Sent: Monday, May 30, 2016 5:05:59 PM >> > Subject: Infinit LAYOUTGET with mmap >> > >> > Dear NFS developers, >> > >> > On my test system I hit a behavior of the nfs client with >> > kernel 4.4 which I haven't seen before. >> > >> > >> > Here is a minimal example to reproduce the issue: >> > >> > ============= bug.c ===================== >> > >> > #include <stdio.h> >> > #include <stdlib.h> >> > #include <unistd.h> >> > #include <fcntl.h> >> > #include <sys/mman.h> >> > >> > >> > int main(int argc, char* argv[]) >> > { >> > >> > int *m; >> > int fd; >> > int err; >> > >> > fd = open(argv[1], O_CREAT| O_RDWR, O_TRUNC, 0666); >> > if (fd < 0) { >> > perror("failed to open file"); >> > exit(1); >> > } >> > >> > err = ftruncate(fd, 4096); >> > if (err) { >> > perror("cant set filesize"); >> > exit(2); >> > } >> > >> > m = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); >> > if (m == MAP_FAILED) { >> > perror("failed to map the file"); >> > exit(2); >> > } >> > >> > m[1] = 0; >> > >> > err = munmap(m, 4096); >> > if (err) { >> > perror("failed to unmap the file"); >> > } >> > >> > close(fd); >> > } >> > =============== end of example ================ >> > >> > >> > >> > When running this code, client send an OPEN with share_access >> > OPEN4_SHARE_ACCESS_BOTH. But later calient sends LAYOUTGET with >> > IOMODE_READ >> > followed by GETDEVICEINFO. >> > >> > This combination of LG+GDI remain for ever. The capture file is >> > attached. >> > >> > My guess it that client expects RW layout. >> > >> > Kernel: 4.4.9-300.fc23.x86_64. I will try with upstream as well. >> > >> > Thanks a lot, >> > Tigran. > > No capture attached, but 4.7 should be getting a major overhaul to the > LAYOUTGET retry handling code. You may want to re-test with a bleeding > edge kernel and see if the problem is still present. > > Cheers, > -- > Jeff Layton <jlayton@xxxxxxxxxxxxxxx> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
