Hi Alexei, Sorry to reply late since I just got back from holiday. On Thu, May 1, 2025 at 12:16 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Wed, Apr 30, 2025 at 3:47 AM Pingfan Liu <piliu@xxxxxxxxxx> wrote: > > > > On Wed, Apr 30, 2025 at 8:04 AM Alexei Starovoitov > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > [...] > > > > Thanks for your suggestion. I originally considered using these kfuncs > > only in kexec context (Later, introducing a dedicated BPF_PROG_TYPE > > for kexec). > > We do not add new prog types anymore. > They're frozen just like the list of helpers. > Got it. > > They are placed under a lock so that a malice attack can > > not exhaust the memory through repeatedly calling to the decompress > > kfunc. > > attack? This is all root only anyway and all memory is counted > towards memcg. > Make sure to use GFP_KERNEL_ACCOUNT and something similar > to bpf_map_get_memcg. > Your clarification makes sense. I will follow that guide. > > To generalize these kfunc, I think I can add some boundary control of > > the memory usage to prevent such attacks. > > Don't reinvent the wheel. memcg is the mechanism. > Sure. Thanks for your insight. It is helpful. Best Regards, Pingfan > > > They also must be KF_SLEEPABLE. > > > Please test your patches with all kernel debugs enabled. > > > Otherwise you would have seen all these "sleeping while atomic" > > > issues yourself. > > > > > > > See, I will have all these debug options for the V3 test. > > > > Appreciate your insight. > > > > Regards, > > > > Pingfan > > >
