[lkml]   [2003]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: The disappearing sys_call_table export.
On Tue, 2003-05-06 at 11:21, Eric W. Biederman wrote:
> Terje Eggestad <> writes:
> >
> > > I believe the answer on how to do a clean safe interface is
> > > to allocate the memory and tell the card about it in the driver,
> > > and then allow user space to mmap it. With the driver mmap operation
> > > informing the network card of the mapping.
> > >
> >
> > You can't mmap() a buffer every time your going to do a send/recv, it's
> > way to costly.
> Definitely not. But if the memory malloc returns is originally
> from a mmaped buffer area (mmaped from your driver) it can be useful.
> I assume somewhere your card has the smarts to transform virtual to
> physical addresses and this is what the mmap sets up.

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.

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.

> 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.

> > The two used approaches are 1) replace malloc() and friends, which break
> > with fortran 90 compilers 2) tell glibc never to release alloced memory
> > thru sbrk(-n) or munmap() which also break with f90 compilers, and run
> > the risk of bloating memory usage.
> Actually there is a third. Hack the vm layer and require a highly
> patched kernel. That is the approach quadrics was using last time I
> looked although they promised something different in their next major
> rev.
> Is it pgi or intels f90 compilers that break, and how do they break.
> Replacing malloc and friends should be well defined if you simply
> replace or wrap the symbols glibc provides.
> Quite possibly the answer is to call those compilers ABI
> non-conformant and get them fixed. Especially given that they are not
> compatible with g77 in fortran mode there is a good case for this. By
> default the native compiler is correct.
> 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.

> Eric

Terje Eggestad
Scali Scalable Linux Systems

Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal +47 975 31 574 (MOBILE)
N-0619 Oslo fax: +47 22 62 89 51

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.056 / U:5.024 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site