On Mon, May 07, 2018 at 01:27:38PM -0700, Kees Cook wrote: > On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > Yes. And today with kvmalloc. However, I proposed to Linus that > > kvmalloc() shouldn't allow it -- we should have kvmalloc_large() which > > would, but kvmalloc wouldn't. He liked that idea, so I'm going with it. > > How would we handle size calculations for _large? I'm not sure we should, at least initially. The very few places which need a large kvmalloc really are special and can do their own careful checking. Because, as Linus pointed out, we shouldn't be letting the user ask us to allocate a terabyte of RAM. We should just fail that. let's see how those users pan out, and then see what we can offer in terms of safety. > > There are very, very few places which should need kvmalloc_large. > > That's one million 8-byte pointers. If you need more than that inside > > the kernel, you're doing something really damn weird and should do > > something that looks obviously different. > > I'm CCing John since I remember long ago running into problems loading > the AppArmor DFA with kmalloc and switching it to kvmalloc. John, how > large can the DFAs for AppArmor get? Would an 8MB limit be a problem? Great! Opinions from people who'll use this interface are exceptionally useful. > And do we have any large IO or network buffers >8MB? Not that get allocated with kvmalloc ... because you can't DMA map vmalloc (without doing some unusual contortions). > > but I thought of another problem with array_size. We already have > > ARRAY_SIZE and it means "the number of elements in the array". > > > > so ... struct_bytes(), array_bytes(), array3_bytes()? > > Maybe "calc"? struct_calc(), array_calc(), array3_calc()? This has the > benefit of actually saying more about what it is doing, rather than > its return value... In the end, I don't care. :) I don't have a strong feeling on this either. > > Keeping our focus on allocations ... do we have plain additions (as > > opposed to multiply-and-add?) And subtraction? > > All I've seen are just rare "weird" cases of lots of mult/add. Some > are way worse than others: > http://www.ozlabs.org/~akpm/mmotm/broken-out/exofs-avoid-vla-in-structures.patch > > Just having the mult/add saturation would be lovely. Ow. My brain just oozed out of my ears.
