Re: The disappearing sys_call_table export.

[Terje Eggestad]

On Tue, 2003-05-06 at 13:37, Eric W. Biederman wrote:
> Terje Eggestad <[e-mail]> writes:
> > 
> > The problem I've got happen when an app registers the memory with the
> > driver, releases the memory back to the kernel thru sbrk(-n) or
> > munmap()s it. Then get new memory thru sbrk(+n) or mmap() which then get
> > the same vaddr. 
> > 
> > mapping from vaddr to phys addr happen at the registration point. 
> 
> I was talking about an method that does not require a registration
> point.  So it sounds like we are talking past each other on this one.
>  
> > Querying the kernel for a vaddrs  phys addr every time it's used is too
> > costly. There is a better explanantion in a earlier post. 
> 
> There are 2 possible interfaces to get a vaddr to phys addr mapping.
> 1) Register the memory area and pin it down.
> 2) MMap from memory allocated by the driver.
>    In this case the driver is told about every mmap and unmap.
> 
> So I believe that baring the strange issues with hooking malloc
> to call a mmap function on your driver 2 is the correct solution.
> 

Well, since the memory is already alloc'ed as normal user memory, it
gotta be 1), which require a registration point. 
 

> > > That can be handled in user space by querying the mmaped region.  But
> > > if the card does not have the smarts to do the virtual to physical
> > > translation, or at the very least limit the set of physical pages a
> > > user space a do DMA to/from that is a fundamental security issue and
> > > means all of the optimizations are not safe.  And you must enter/exit
> > > the kernel to send a DMA transaction.
> > > 
> > 
> > send/recv don't need kernel interaction on high perf interconnects.
> 
> Agreed.  I was simply mention the requires for that to be safe.
> 
> > > So far the only fortran issues I have seen that could affect malloc
> > > are adding extra under scores.  What issue are you running into?
> > > 
> > 
> > Some don't use (g)libc, but do syscalls directly.
> 
> That is clearly broken code.  A user space application compiled statically is
> one thing.  Directly putting syscalls in libraries other than libc is
> quite bad.  And I currently cannot think of an excuse for it.
> Especially as that will ensure you use the slow syscall path on recent
> kernels. 
> 

Agree, come to think about it, if you write code in fortran it's broken
by default ;-) 

The thing is of course that pesky customers have fortran code they need
to run, and as long there is no g90, and g77 performance sucks, there is
only commercial fortran compilers in play....  

> Eric

TJ

-- 
_________________________________________________________________________

Terje Eggestad                  mailto:[e-mail]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    [phone] (OFFICE)
P.O.Box 150, Oppsal                     [phone]  (MOBILE)
N-0619 Oslo                     fax:    [phone]
NORWAY            
_________________________________________________________________________