Miklos Szeredi <[email protected]> writes:
> Right. But the devil is in the details, and (as you correctly point
> out later) to implement this, the whole locking scheme needs to be
> overhauled. Problems:
>
> - Using the queue lock to make the dequeue and the fd detach atomic
> wrt the GC is difficult, if not impossible: they are are far from
> each other with various magic in between. It would need thorough
> understanding of these functions and _big_ changes to implement.
>
> - Sleeping on u->readlock in GC is currently not possible, since that
> could deadlock with unix_dgram_recvmsg(). That function could
> probably be modified to release u->readlock, while waiting for
> data, similarly to unix_stream_recvmsg() at the cost of some added
> complexity.
>
> - Sleeping on u->readlock is also impossible, because GC is holding
> unix_table_lock for the whole operation. We could release
> unix_table_lock, but then would have to cope with sockets coming
> and going, making the current socket iterator unworkable.
>
> So theoretically it's quite simple, but it needs big changes. And
> this wouldn't even solve all the problems with the GC, like being a
> possible DoS vector.
Making the GC fully incremental will solve the DoS vector problem as
well. Basically you do a fixed amount of reclaim in the new socket
allocation code.
It appears clear that since we can't stop the world and garbage
collect we need an incremental collector.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
