On Wed, Jul 06, 2022 at 11:26:35AM -0700, Alexei Starovoitov wrote: > On Wed, Jul 06, 2022 at 07:21:29PM +0100, Matthew Wilcox wrote: > > On Wed, Jul 06, 2022 at 11:05:25AM -0700, Alexei Starovoitov wrote: > > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote: > > > > For example, I assume that a BPF program > > > > has a fairly tight limit on how much memory it can cause to be allocated. > > > > Right? > > > > > > No. It's constrained by memcg limits only. It can allocate gigabytes. > > > > I'm confused. A BPF program is limited to executing 4096 insns and > > using a maximum of 512 bytes of stack space, but it can allocate an > > unlimited amount of heap? That seems wrong. > > 4k insn limit was lifted years ago. You might want to update the documentation. https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html still says 4096. > bpf progs are pretty close to be at parity with kernel modules. > Except that they are safe, portable, and users have full visibility into them. > It's not a blob of bytes unlike .ko. It doesn't seem unreasonable to expect them to behave like kernel modules, then. If they want to allocate memory in NMI context, then they should get to preallocate it before they go into NMI context.