Re: Re: can enbd server run in kernel?

"Also sprach Peter T. Breuer:"
> "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:

OK, got it. The FILE is NOT locked. The MEMORY is. The server process
has its pages locked in memory with mlockall. Removing that mlockall call
allows msync to work.

I suspect that's a mistake - I don't see why one should care if the
address space can be swapped out or not (what mlockall prevents) when
asking to sync different pages of common mmapped memory between
processes.

DESCRIPTION
       mlockall  disables  paging  for  all pages mapped into the
       address space of the calling process.  This  includes  the
       pages  of  the  code,  data  and stack segment, as well as
       shared libraries, user space kernel  data,  shared  memory
       and  memory  mapped files. All mapped pages are guaranteed
       to be resident  in  RAM  when  the  mlockall  system  call
       returns  successfully  and  they are guaranteed to stay in
       RAM until the pages  are  unlocked  again  by  munlock  or
       munlockall  or  until  the  process  terminates  or starts
       another program with exec.  Child processes do not inherit
       page locks across a fork.

I suppose I could try munlock immediately before, followed by mlock
after. Grr ...

Peter