Re: *alloc API changes

On Mon, May 7, 2018 at 2:41 PM, Rasmus Villemoes wrote: > If instead we do > > static inline void *kmalloc_array(size_t n, size_t size, gfp_t flags) > { > size_t p; > if (check_mul_overflow(n, size, )) > return NULL; > return

Re: *alloc API changes

On Mon, May 7, 2018 at 2:41 PM, Rasmus Villemoes wrote: > If instead we do > > static inline void *kmalloc_array(size_t n, size_t size, gfp_t flags) > { > size_t p; > if (check_mul_overflow(n, size, )) > return NULL; > return __kmalloc(p, flags); > } > > we'd

Re: *alloc API changes

On 05/07/2018 01:27 PM, Kees Cook wrote: > On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox wrote: >> On Mon, May 07, 2018 at 09:03:54AM -0700, Kees Cook wrote: >>> On Mon, May 7, 2018 at 4:39 AM, Matthew Wilcox wrote: On Fri, May 04, 2018 at

Re: *alloc API changes

On 05/07/2018 01:27 PM, Kees Cook wrote: > On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox wrote: >> On Mon, May 07, 2018 at 09:03:54AM -0700, Kees Cook wrote: >>> On Mon, May 7, 2018 at 4:39 AM, Matthew Wilcox wrote: On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: > On Fri,

Re: *alloc API changes

On 2018-05-05 06:24, Kees Cook wrote: > >> Right, I was thinking: >> >> static inline size_t mul_ab(size_t a, size_t b) >> { >> #if COMPILER_SUPPORTS_OVERFLOW >> unsigned long c; >> if (__builtin_mul_overflow(a, b, )) >> return SIZE_MAX; >> return c; >>

Re: *alloc API changes

On 2018-05-05 06:24, Kees Cook wrote: > >> Right, I was thinking: >> >> static inline size_t mul_ab(size_t a, size_t b) >> { >> #if COMPILER_SUPPORTS_OVERFLOW >> unsigned long c; >> if (__builtin_mul_overflow(a, b, )) >> return SIZE_MAX; >> return c; >>

Re: *alloc API changes

On Mon, May 7, 2018 at 1:49 PM, Matthew Wilcox wrote: > On Mon, May 07, 2018 at 01:27:38PM -0700, Kees Cook wrote: >> On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox wrote: >> > Yes. And today with kvmalloc. However, I proposed to Linus that >> >

Re: *alloc API changes

On Mon, May 7, 2018 at 1:49 PM, Matthew Wilcox wrote: > On Mon, May 07, 2018 at 01:27:38PM -0700, Kees Cook wrote: >> On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox wrote: >> > Yes. And today with kvmalloc. However, I proposed to Linus that >> > kvmalloc() shouldn't allow it -- we should have

Re: *alloc API changes

On Mon, May 07, 2018 at 01:27:38PM -0700, Kees Cook wrote: > On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox 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

Re: *alloc API changes

On Mon, May 07, 2018 at 01:27:38PM -0700, Kees Cook wrote: > On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox 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

Re: *alloc API changes

On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox wrote: > On Mon, May 07, 2018 at 09:03:54AM -0700, Kees Cook wrote: >> On Mon, May 7, 2018 at 4:39 AM, Matthew Wilcox wrote: >> > On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: >> >> On Fri, May

Re: *alloc API changes

On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox wrote: > On Mon, May 07, 2018 at 09:03:54AM -0700, Kees Cook wrote: >> On Mon, May 7, 2018 at 4:39 AM, Matthew Wilcox wrote: >> > On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: >> >> On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox >> >>

Re: *alloc API changes

On Mon, May 07, 2018 at 09:03:54AM -0700, Kees Cook wrote: > On Mon, May 7, 2018 at 4:39 AM, Matthew Wilcox wrote: > > On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: > >> On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: > >> The only

Re: *alloc API changes

On Mon, May 07, 2018 at 09:03:54AM -0700, Kees Cook wrote: > On Mon, May 7, 2018 at 4:39 AM, Matthew Wilcox wrote: > > On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: > >> On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: > >> The only fear I have with the saturating helpers is

Re: *alloc API changes

On Mon, May 7, 2018 at 4:39 AM, Matthew Wilcox wrote: > On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: >> On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: >> The only fear I have with the saturating helpers is that we'll end up >> using

Re: *alloc API changes

On Mon, May 7, 2018 at 4:39 AM, Matthew Wilcox wrote: > On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: >> On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: >> The only fear I have with the saturating helpers is that we'll end up >> using them in places that don't recognize

Re: *alloc API changes

On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: > On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: > The only fear I have with the saturating helpers is that we'll end up > using them in places that don't recognize SIZE_MAX. Like, say: > > size = mul(a, b) +

Re: *alloc API changes

On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: > On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: > The only fear I have with the saturating helpers is that we'll end up > using them in places that don't recognize SIZE_MAX. Like, say: > > size = mul(a, b) + 1; > > then *poof*

Re: *alloc API changes

On Fri, May 04, 2018 at 08:46:46PM -0700, Matthew Wilcox wrote: > On Fri, May 04, 2018 at 06:08:23PM -0700, Kees Cook wrote: > > The number of permutations for our various allocation function is > > rather huge. Currently, it is: > > > > system or wrapper: > > kmem_cache_alloc, kmalloc, vmalloc,

Re: *alloc API changes

On Fri, May 04, 2018 at 08:46:46PM -0700, Matthew Wilcox wrote: > On Fri, May 04, 2018 at 06:08:23PM -0700, Kees Cook wrote: > > The number of permutations for our various allocation function is > > rather huge. Currently, it is: > > > > system or wrapper: > > kmem_cache_alloc, kmalloc, vmalloc,

Re: *alloc API changes

On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: > and if you're counting f2fs_*alloc, there's a metric tonne of *alloc > wrappers out there. Yeah. *sob* > That's a little revisionist ;-) We had kmalloc before we had the slab > allocator (kernel 1.2, I think?). But I

Re: *alloc API changes

On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: > and if you're counting f2fs_*alloc, there's a metric tonne of *alloc > wrappers out there. Yeah. *sob* > That's a little revisionist ;-) We had kmalloc before we had the slab > allocator (kernel 1.2, I think?). But I see your point, and

Re: *alloc API changes

On Fri, May 04, 2018 at 06:08:23PM -0700, Kees Cook wrote: > The number of permutations for our various allocation function is > rather huge. Currently, it is: > > system or wrapper: > kmem_cache_alloc, kmalloc, vmalloc, kvmalloc, devm_kmalloc, > dma_alloc_coherent, pci_alloc_consistent,

Re: *alloc API changes

On Fri, May 04, 2018 at 06:08:23PM -0700, Kees Cook wrote: > The number of permutations for our various allocation function is > rather huge. Currently, it is: > > system or wrapper: > kmem_cache_alloc, kmalloc, vmalloc, kvmalloc, devm_kmalloc, > dma_alloc_coherent, pci_alloc_consistent,

*alloc API changes

Hi, After writing up this email, I think I don't like this idea, but I'm still curious to see what people think of the general observations... The number of permutations for our various allocation function is rather huge. Currently, it is: system or wrapper: kmem_cache_alloc, kmalloc, vmalloc,

*alloc API changes

Hi, After writing up this email, I think I don't like this idea, but I'm still curious to see what people think of the general observations... The number of permutations for our various allocation function is rather huge. Currently, it is: system or wrapper: kmem_cache_alloc, kmalloc, vmalloc,