------_=_NextPart_001_01BE924D.DBDA3C10
Content-Type: text/plain;
charset="iso-8859-1"
> > process, etc.
> > Without a mechanism to allow the driver to be notified the
> process has died
> > to stop the DMA disk buffers could be destroyed, processes
> overwritten, etc.
> > This is a BAD THING.
>
> When a kernel mapping is created for a given user-page.
> Doesn't the reference
> count for the page be "2", one for the user and one for
> the kernel. Doesn't
> the page structure maintain a reference count ?
> Also when a kernel mapping is created, shouldn't the page
> accquire a property
> of staying around, even if the user mapping goes off ?
> Because when the user
> process goes off the page * should * not go back to the
> free pool, but stay
> around as the "ref cnt" is now "1". Also it should always
> stay in memory, because
> the page is still locked. If a process was the only user
> for the page when
> the memory cleanup occurs as part of exit(), the page
> will go back to the free pool
> and lose its property of being locked.
Yes. Someone please correct me if I'm wrong -- but since I'm using the
PG_locked bit, when the reference count falls to 1 the kernel knows that it
has the other reference, and frees the memory anyway. I have tested
repeated allocations, locks, and killed the process with the buffer locked
-- and the memory usage of the system doesn't go up, which seems to verify
this is the case. Of course, I could get around this by setting
PG_reserved, but that would make the memory unusable until reboot -- which
would be evil. This is precisely the wrong kind of hack that makes Linus'
hair stand up on end, as it should. :-)
> But i do accept one likely problem in such DMA's. In case
> the driver is waiting
> for the DMA to happen/complete and an un-advertised
> exit() happens:
That's why a callback mechanism is necessary; or, alternatively, a way to
access a process's page tables from a kernel thread that will still live
after the process dies (but that also requires that the memory not be freed
until after it's unlocked...)
> This will more likely cause kernel memory VM and the
> pages behind them to be eaten
> up, as there is no one to free them if the process goes
> off un-advertised. This
> is assuming that the process had called exit() in the
> interruptible blocking call
> itself on receipt of say a SIGSEGV ( for a multi-threaded
> case ), or some other
> fatal exit criteria.
>
> I have another question:
> Doesn't the above happen for the case for allocation of
> kernel buffers and mmap
> to the user ? I mean who will free the kernel buffers in
> this case ?
The kernel. The real problem is this-- I need to be able to set a timer to
go off regardless of whether or not the process that locked the pages is
still around. I can't do that from the process context, since it is removed
from the timer queue when the process goes away. A possible solution would
be to do the work from a kernel thread that sleeps and wakes up when a timer
goes off every so often and checks for buffers that have been locked but
have a reference count of '1'. This adds overhead though, so I would think
it would be more efficient to give this job to the swapper since it's
already around...
-- Eric Lowe elowe@systran.com Software Engineer Co-op, Systran Corporation 937-252-5601 x330
------_=_NextPart_001_01BE924D.DBDA3C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: Process VM Addr to Kernel VM Addr at Interrupt Time. > > process, etc.
> > Without a mechanism to allow the driver to = be notified the
> process has died
> > to stop the DMA disk buffers could be = destroyed, processes
> overwritten, etc.
> > This is a BAD THING.
>
> When a kernel mapping = is created for a given user-page.
> Doesn't the reference
> count for the page be = "2", one for the user and one for
> the kernel. Doesn't
> the page structure = maintain a reference count ?
> Also when a kernel = mapping is created, shouldn't the page
> accquire a property
> of staying around, even = if the user mapping goes off ?
> Because when the user
> process goes off the = page * should * not go back to the
> free pool, but stay
> around as the "ref = cnt" is now "1". Also it should always
> stay in memory, because
> the page is still = locked. If a process was the only user
> for the page when
> the memory cleanup = occurs as part of exit(), the page
> will go back to the free pool
> and lose its property = of being locked.Yes. Someone please correct me if I'm wrong -- = but since I'm using the PG_locked bit, when the reference count falls = to 1 the kernel knows that it has the other reference, and frees the = memory anyway. I have tested repeated allocations, locks, and = killed the process with the buffer locked -- and the memory usage of = the system doesn't go up, which seems to verify this is the case. = Of course, I could get around this by setting PG_reserved, but that = would make the memory unusable until reboot -- which would be = evil. This is precisely the wrong kind of hack that makes Linus' = hair stand up on end, as it should. :-)
> But i do accept one = likely problem in such DMA's. In case
> the driver is waiting
> for the DMA to = happen/complete and an un-advertised
> exit() happens:That's why a callback mechanism is necessary; or, = alternatively, a way to access a process's page tables from a kernel = thread that will still live after the process dies (but that also = requires that the memory not be freed until after it's = unlocked...)
> This will more likely = cause kernel memory VM and the
> pages behind them to be eaten
> up, as there is no one = to free them if the process goes
> off un-advertised. This
> is assuming that the = process had called exit() in the
> interruptible blocking call
> itself on receipt of = say a SIGSEGV ( for a multi-threaded
> case ), or some other
> fatal exit = criteria.
>
> I have another = question:
> Doesn't the above = happen for the case for allocation of
> kernel buffers and mmap
> to the user ? I = mean who will free the kernel buffers in
> this case ?The kernel. The real problem is this-- I need = to be able to set a timer to go off regardless of whether or not the = process that locked the pages is still around. I can't do that = from the process context, since it is removed from the timer queue when = the process goes away. A possible solution would be to do the = work from a kernel thread that sleeps and wakes up when a timer goes = off every so often and checks for buffers that have been locked but = have a reference count of '1'. This adds overhead though, so I = would think it would be more efficient to give this job to the swapper = since it's already around...
--
Eric Lowe
elowe@systran.com
Software Engineer Co-op, Systran Corporation
937-252-5601 x330
------_=_NextPart_001_01BE924D.DBDA3C10--- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/