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
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
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
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,
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;
>>
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;
>>
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
>> >
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
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
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
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
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
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
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
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) +
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*
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,
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,
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
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
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,
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,
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,
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,
26 matches
Mail list logo