Re: Re: can enbd server run in kernel?

"Peter T. Breuer" <[email protected]>
Newsgroups gmane.linux.enbd.general
Message-ID <[email protected]>
"Also sprach Ming Zhang:"
> 
> The msync() function shall fail if:
> 
> [EBUSY] 
>         Some or all of the addresses in the range starting at addr and
>         continuing for len bytes are locked, and MS_INVALIDATE is
>         specified.
> 
> googled. :P
> 
> but locked by whom?

Well, the resource looks not locked.  The locks that are made are on
parts of shared memory based on /dev/zero, which is used as a common
reservoir for request results in case of a repeat being required:

  ...
  fcntl(5, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=4, len=0}) = 0 <0.000011>
  fcntl(5, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=4, len=0}) = 0 <0.000016>
  fcntl(5, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=4, len=0}) = 0 <0.000013>
  ...

All uses of fcntl are on FD 5, and 5 points to /dev/zero (which mapped
anonymously elsewhere in the code):

  lrwx------  1 root root 64 Nov 28 11:37 /proc/26927/fd/5 -> /dev/zero

But the mmap is on FDs 10 and 11 (which are the resources):

  ...
  msync(0x40381000, 49152, MS_INVALIDATE) = -1 EBUSY (Device or resource busy) <0.000010>
  msync(0x4038d000, 16384, MS_INVALIDATE) = -1 EBUSY (Device or resource busy) <0.000009>
  ...
  munmap(0x401d1000, 1818624)             = 0 <0.000419>
  munmap(0x4038d000, 344064)              = 0 <0.000102>
  old_mmap(NULL, 1249280, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = 0x401d1000 <0.000359>
  munmap(0x401d1000, 1249280)             = 0 <0.000277>
  old_mmap(NULL, 2162688, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0x31000) = 0x401d1000 <0.000570>
  munmap(0x401d1000, 2162688)             = 0 <0.000386>
  old_mmap(NULL, 2162688, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0x141000) = 0x401d1000 <0.000575>
  ...

  lrwx------  1 root root 64 Nov 28 11:46 /proc/26927/fd/10 -> /var/tmp/core0
  lrwx------  1 root root 64 Nov 28 11:47 /proc/26927/fd/11 -> /var/tmp/core1


This might be complicated - the server closes the resource after
inactivity in order to avoid interfering with removable devices like
floppies and cdroms. But I'll try and absolutely eliminate the
posssibility that the resource is locked. Obviously it isn't locked
when not open :-). Or maybe the EBUSY means something else.



Peter
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.