On Fri, May 4, 2018 at 8:35 AM, Linus Torvalds
wrote:
> On Fri, May 4, 2018 at 3:14 AM Matthew Wilcox wrote:
>
>> > In fact, the conversion I saw was buggy. You can *not* convert a
> GFP_ATOMIC
>> > user of kmalloc() to use kvmalloc.
>
>> Not sure which conversion you're referring to; not one of
On Fri, May 4, 2018 at 3:14 AM Matthew Wilcox wrote:
> > In fact, the conversion I saw was buggy. You can *not* convert a
GFP_ATOMIC
> > user of kmalloc() to use kvmalloc.
> Not sure which conversion you're referring to; not one of mine, I hope?
I was thinking of the coccinelle patch in this th
On Fri, May 04, 2018 at 07:42:52AM +, Linus Torvalds wrote:
> On Wed, Feb 14, 2018 at 8:27 AM Matthew Wilcox wrote:
> > +static inline __must_check
> > +void *kvmalloc_ab_c(size_t n, size_t size, size_t c, gfp_t gfp)
> > +{
> > + if (size != 0 && n > (SIZE_MAX - c) / size)
> > +
On Wed, Feb 14, 2018 at 8:27 AM Matthew Wilcox wrote:
> +static inline __must_check
> +void *kvmalloc_ab_c(size_t n, size_t size, size_t c, gfp_t gfp)
> +{
> + if (size != 0 && n > (SIZE_MAX - c) / size)
> + return NULL;
> +
> + return kvmalloc(n * size + c, gfp);
Ok, so
On Thu, May 3, 2018 at 5:36 PM, Kees Cook wrote:
> On Thu, May 3, 2018 at 4:00 PM, Rasmus Villemoes
> wrote:
>> On 2018-05-01 19:00, Kees Cook wrote:
>>> On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes
>>> wrote:
gcc 5.1+ (I think) have the __builtin_OP_overflow checks that should
>>
On Thu, May 3, 2018 at 4:00 PM, Rasmus Villemoes
wrote:
> On 2018-05-01 19:00, Kees Cook wrote:
>> On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes
>> wrote:
>>>
>>> gcc 5.1+ (I think) have the __builtin_OP_overflow checks that should
>>> generate reasonable code. Too bad there's no completely g
On 2018-05-01 19:00, Kees Cook wrote:
> On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes
> wrote:
>>
>> gcc 5.1+ (I think) have the __builtin_OP_overflow checks that should
>> generate reasonable code. Too bad there's no completely generic
>> check_all_ops_in_this_expression(a+b*c+d/e, or_jump_he
On Tue, 1 May 2018, Kees Cook wrote:
> On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes
> wrote:
> > On 2018-04-30 22:16, Matthew Wilcox wrote:
> >> On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote:
> >>>
> >>> Getting the constant ordering right could be part of the macro
> >>> defin
On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes
wrote:
> On 2018-04-30 22:16, Matthew Wilcox wrote:
>> On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote:
>>>
>>> Getting the constant ordering right could be part of the macro
>>> definition, maybe? i.e.:
>>>
>>> static inline void *kmallo
On Mon, Apr 30, 2018 at 11:29:04PM +0200, Rasmus Villemoes wrote:
> On 2018-04-30 22:16, Matthew Wilcox wrote:
> > On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote:
> >> (I just wish C had a sensible way to catch overflow...)
> >
> > Every CPU I ever worked with had an "overflow" bit ...
On Mon, Apr 30, 2018 at 1:16 PM, Matthew Wilcox wrote:
> On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote:
>> For any longer multiplications, I've only found[1]:
>>
>> drivers/staging/rtl8188eu/os_dep/osdep_service.c: void **a =
>> kzalloc(h * sizeof(void *) + h * w * size, GFP_KERN
On 2018-04-30 22:16, Matthew Wilcox wrote:
> On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote:
>>
>> Getting the constant ordering right could be part of the macro
>> definition, maybe? i.e.:
>>
>> static inline void *kmalloc_ab(size_t a, size_t b, gfp_t flags)
>> {
>> if (__builtin_co
On Mon, Apr 30, 2018 at 12:02:14PM -0700, Kees Cook wrote:
> On Sun, Apr 29, 2018 at 1:30 PM, Matthew Wilcox wrote:
> > On Sun, Apr 29, 2018 at 09:59:27AM -0700, Kees Cook wrote:
> >> Did this ever happen?
> >
> > Not yet. I brought it up at LSFMM, and I'll repost the patches soon.
> >
> >> I'd a
On Sun, Apr 29, 2018 at 1:30 PM, Matthew Wilcox wrote:
> On Sun, Apr 29, 2018 at 09:59:27AM -0700, Kees Cook wrote:
>> Did this ever happen?
>
> Not yet. I brought it up at LSFMM, and I'll repost the patches soon.
>
>> I'd also like to see kmalloc_array_3d() or
>> something that takes three size
On Sun, Apr 29, 2018 at 09:59:27AM -0700, Kees Cook wrote:
> Did this ever happen?
Not yet. I brought it up at LSFMM, and I'll repost the patches soon.
> I'd also like to see kmalloc_array_3d() or
> something that takes three size arguments. We have a lot of this
> pattern too:
>
> kmalloc(size
On Tue, Mar 13, 2018 at 11:32 AM, Matthew Wilcox wrote:
> On Tue, Mar 13, 2018 at 06:19:51PM +0100, Julia Lawall wrote:
>> On Thu, 8 Mar 2018, Matthew Wilcox wrote:
>> > On Thu, Mar 08, 2018 at 07:24:47AM +0100, Julia Lawall wrote:
>> > > Thanks. So it's OK to replace kmalloc and kzalloc, even th
On Tue, Mar 13, 2018 at 06:19:51PM +0100, Julia Lawall wrote:
> On Thu, 8 Mar 2018, Matthew Wilcox wrote:
> > On Thu, Mar 08, 2018 at 07:24:47AM +0100, Julia Lawall wrote:
> > > Thanks. So it's OK to replace kmalloc and kzalloc, even though they
> > > didn't previously consider vmalloc and even th
On Tue, 13 Mar 2018, Matthew Wilcox wrote:
> On Tue, Mar 13, 2018 at 06:19:51PM +0100, Julia Lawall wrote:
> > On Thu, 8 Mar 2018, Matthew Wilcox wrote:
> > > On Thu, Mar 08, 2018 at 07:24:47AM +0100, Julia Lawall wrote:
> > > > Thanks. So it's OK to replace kmalloc and kzalloc, even though the
On Thu, 8 Mar 2018, Matthew Wilcox wrote:
> On Thu, Mar 08, 2018 at 07:24:47AM +0100, Julia Lawall wrote:
> > On Wed, 7 Mar 2018, Matthew Wilcox wrote:
> > > On Wed, Mar 07, 2018 at 10:18:21PM +0100, Julia Lawall wrote:
> > > > > Otherwise, yes, please. We could build a coccinelle rule for
> > >
On Thu, 8 Mar 2018, Matthew Wilcox wrote:
> On Thu, Mar 08, 2018 at 07:24:47AM +0100, Julia Lawall wrote:
> > On Wed, 7 Mar 2018, Matthew Wilcox wrote:
> > > On Wed, Mar 07, 2018 at 10:18:21PM +0100, Julia Lawall wrote:
> > > > > Otherwise, yes, please. We could build a coccinelle rule for
> > >
On Thu, Mar 08, 2018 at 07:24:47AM +0100, Julia Lawall wrote:
> On Wed, 7 Mar 2018, Matthew Wilcox wrote:
> > On Wed, Mar 07, 2018 at 10:18:21PM +0100, Julia Lawall wrote:
> > > > Otherwise, yes, please. We could build a coccinelle rule for
> > > > additional replacements...
> > >
> > > A potential
On Wed, 7 Mar 2018, Matthew Wilcox wrote:
> On Wed, Mar 07, 2018 at 10:18:21PM +0100, Julia Lawall wrote:
> > > Otherwise, yes, please. We could build a coccinelle rule for
> > > additional replacements...
> >
> > A potential semantic patch and the changes it generates are attached
> > below. H
On Wed, Mar 07, 2018 at 10:18:21PM +0100, Julia Lawall wrote:
> > Otherwise, yes, please. We could build a coccinelle rule for
> > additional replacements...
>
> A potential semantic patch and the changes it generates are attached
> below. Himanshu Jha helped with its development. Working on thi
On Wed, 14 Feb 2018, Kees Cook wrote:
> On Wed, Feb 14, 2018 at 10:26 AM, Matthew Wilcox wrote:
> > From: Matthew Wilcox
> >
> > We have kvmalloc_array in order to safely allocate an array with a
> > number of elements specified by userspace (avoiding arithmetic overflow
> > leading to a buffe
On Thu, Feb 15, 2018 at 9:06 AM, Christopher Lameter wrote:
> On Thu, 15 Feb 2018, Matthew Wilcox wrote:
>
>> I dunno. Yes, there's macro trickery going on here, but it certainly
>> resembles a function. It doesn't fail any of the rules laid out in that
>> chapter of coding-style about unaccepta
On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> I dunno. Yes, there's macro trickery going on here, but it certainly
> resembles a function. It doesn't fail any of the rules laid out in that
> chapter of coding-style about unacceptable uses of macros.
It sure looks like a function but does magic t
On Thu, Feb 15, 2018 at 09:55:11AM -0600, Christopher Lameter wrote:
> On Wed, 14 Feb 2018, Matthew Wilcox wrote:
>
> > > Uppercase like the similar KMEM_CACHE related macros in
> > > include/linux/slab.h?>
> >
> > Do you think that would look better in the users? Compare:
>
> Does looking matte
On Wed, 14 Feb 2018, Matthew Wilcox wrote:
> > Uppercase like the similar KMEM_CACHE related macros in
> > include/linux/slab.h?>
>
> Do you think that would look better in the users? Compare:
Does looking matter? I thought we had the convention that macros are
uppercase. There are some tricks g
On Wed, Feb 14, 2018 at 01:55:59PM -0600, Christopher Lameter wrote:
> On Wed, 14 Feb 2018, Matthew Wilcox wrote:
>
> > +#define kvzalloc_struct(p, member, n, gfp) \
> > + (typeof(p))kvzalloc_ab_c(n, \
> > + sizeof(*(p)->membe
On Wed, 14 Feb 2018, Matthew Wilcox wrote:
> +#define kvzalloc_struct(p, member, n, gfp) \
> + (typeof(p))kvzalloc_ab_c(n, \
> + sizeof(*(p)->member) + __must_be_array((p)->member),\
> + offsetof(typeof(*
On Wed, Feb 14, 2018 at 11:22:38AM -0800, Kees Cook wrote:
> > +/**
> > + * kvmalloc_ab_c() - Allocate memory.
>
> Longer description, maybe? "Allocate a *b + c bytes of memory"?
Done!
> > + * @n: Number of elements.
> > + * @size: Size of each element (should be constant).
> > + * @c: Size of h
On Wed, 14 Feb 2018, Kees Cook wrote:
> On Wed, Feb 14, 2018 at 10:26 AM, Matthew Wilcox wrote:
> > From: Matthew Wilcox
> >
> > We have kvmalloc_array in order to safely allocate an array with a
> > number of elements specified by userspace (avoiding arithmetic overflow
> > leading to a buffe
On Wed, Feb 14, 2018 at 10:26 AM, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> We have kvmalloc_array in order to safely allocate an array with a
> number of elements specified by userspace (avoiding arithmetic overflow
> leading to a buffer overrun). But it's fairly common to have a header
From: Matthew Wilcox
We have kvmalloc_array in order to safely allocate an array with a
number of elements specified by userspace (avoiding arithmetic overflow
leading to a buffer overrun). But it's fairly common to have a header
in front of that array (eg specifying the length of the array), so
34 matches
Mail list logo
