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, &p))
> return NULL;
> return __kmalloc(p, flags);
> }
>
> we'd
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, Ma
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, &c))
>> return SIZE_MAX;
>> return c;
>> #e
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 k
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
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
>> >>
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 tha
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 SIZE_MA
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* si
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, k
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 t
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, kmem_allo
12 matches
Mail list logo
