Changes

m
no edit summary
Line 3: Line 3:  
This page contains project ideas for upcoming Google Summer of Code.
 
This page contains project ideas for upcoming Google Summer of Code.
   −
== Contacts ==
+
== Contact ==
   −
Please contact the respective mentor for the idea you are interested in. For general questions feel free to send an email to the [mailto:criu@lists.linux.dev mailing list] or write in [https://gitter.im/save-restore/criu gitter].
+
First, make sure to go through the [[GSoC Students Recommendations]]. Once you build CRIU locally and C/R a simple process successfully, please contact the respective mentor for the idea you are interested in. For general questions feel free to send an email to the [mailto:criu@lists.linux.dev mailing list] or write in [https://gitter.im/save-restore/criu gitter].
    
== Project ideas ==
 
== Project ideas ==
Line 27: Line 27:  
* Expected size: 350 hours
 
* Expected size: 350 hours
 
* Suggested by: Andrei Vagin <avagin@gmail.com>
 
* Suggested by: Andrei Vagin <avagin@gmail.com>
* Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Andrei Vagin <avagin@gmail.com>
+
* Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Alexander Mikhalitsyn <alexander@mihalicyn.com>, Andrei Vagin <avagin@gmail.com>
    
=== Use eBPF to lock and unlock the network ===
 
=== Use eBPF to lock and unlock the network ===
Line 103: Line 103:  
* Language: C
 
* Language: C
 
* Expected size: 350 hours
 
* Expected size: 350 hours
* Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Pavel Tikhomirov <ptikhomirov@virtuozzo.com>, Prajwal S N <prajwalnadig21@gmail.com>
+
* Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
 
* Suggested by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
 
* Suggested by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
   Line 121: Line 121:  
but will require a lot of effort to understand Linux kernel and
 
but will require a lot of effort to understand Linux kernel and
 
glibc support patches. We have a good example of support for
 
glibc support patches. We have a good example of support for
x86 shadow stack [4] thanks to Mike.
+
x86 shadow stack [4].
    
'''Links:'''
 
'''Links:'''
Line 127: Line 127:  
* [2] libc support https://inbox.sourceware.org/libc-alpha/20250117174119.3254972-1-yury.khrustalev@arm.com
 
* [2] libc support https://inbox.sourceware.org/libc-alpha/20250117174119.3254972-1-yury.khrustalev@arm.com
 
* [3] libc tests https://inbox.sourceware.org/libc-alpha/20250210114538.1723249-1-yury.khrustalev@arm.com
 
* [3] libc tests https://inbox.sourceware.org/libc-alpha/20250210114538.1723249-1-yury.khrustalev@arm.com
* [4] x86 support (a great reference!) https://github.com/checkpoint-restore/criu/pull/2306
+
* [4] x86 support https://github.com/checkpoint-restore/criu/pull/2306
 
   
 
   
 
'''Details:'''
 
'''Details:'''
Line 234: Line 234:  
the queue is written into the image and is restored into the socket (with the CORK
 
the queue is written into the image and is restored into the socket (with the CORK
 
bit set too).
 
bit set too).
 +
 +
'''Notes:'''
 +
 +
We already had a couple (3) of tries for this problem:
 +
 +
* UDP_REPAIR approach didn't succeed: https://lore.kernel.org/netdev/721a2e32-c930-ad6b-5055-631b502ed11b@gmail.com/, https://lore.kernel.org/netdev/?q=udp_repair
 +
* eBPF (CRIB) approach, socket queue iterator was not merged: https://lore.kernel.org/netdev/AM6PR03MB5848EDA002E3D7EACA7C6BDA99A52@AM6PR03MB5848.eurprd03.prod.outlook.com/, and we have general objections to CRIB approach https://lore.kernel.org/bpf/CAHk-=wjLWFa3i6+Tab67gnNumTYipj_HuheXr2RCq4zn0tCTzA@mail.gmail.com/
 +
 +
We still have one idea we didn't try, as UDP allows packets to be lost on the way on restore we can somehow mark the socket to drop all data before UNCORK. This way we don't really need to restore contents of UDP CORK-ed sockets send queue.
 
   
 
   
 
'''Links:'''
 
'''Links:'''
509

edits