[PATCH] perf: disable parallelism for 'make clean'

much by explicitly disabling the parallelism for the clean target, and it makes automated builds much more reliable. Signed-off-by: Rasmus Villemoes --- Another option is to add -ignore_readdir_race to all find commands, but that's a lot more invasive and only works properly together with -delete

Re: sparse warnings in overflow.h

On 2018-06-07 20:35, Kees Cook wrote: > On Thu, Jun 7, 2018 at 4:01 AM, Miroslav Benes wrote: >> >> Hi Kees, >> >> sparse (make C=1) gives me this warnings today... >> >> ./include/linux/overflow.h:254:13: error: undefined identifier >> '__builtin_mul_overflow' >>

Re: sparse warnings in overflow.h

On 2018-06-07 20:35, Kees Cook wrote: > On Thu, Jun 7, 2018 at 4:01 AM, Miroslav Benes wrote: >> >> Hi Kees, >> >> sparse (make C=1) gives me this warnings today... >> >> ./include/linux/overflow.h:254:13: error: undefined identifier >> '__builtin_mul_overflow' >>

Re: [PATCH 04/13] mm: Use array_size() helpers for kmalloc()

On 2018-05-09 20:07, Kees Cook wrote: > On Wed, May 9, 2018 at 11:00 AM, Rasmus Villemoes > <li...@rasmusvillemoes.dk> wrote: > Okay, consensus is to remove new SIZE_MAX checks, then? Yes, don't add such to static inlines. But the out-of-line implementations do need an audit (as

Re: [PATCH 04/13] mm: Use array_size() helpers for kmalloc()

On 2018-05-09 20:07, Kees Cook wrote: > On Wed, May 9, 2018 at 11:00 AM, Rasmus Villemoes > wrote: > Okay, consensus is to remove new SIZE_MAX checks, then? Yes, don't add such to static inlines. But the out-of-line implementations do need an audit (as you've observed) for unsafe a

Re: [PATCH 03/13] overflow.h: Add allocation size calculation helpers

On 2018-05-09 02:42, Kees Cook wrote: > In preparation for replacing unchecked overflows for memory allocations, > this creates helpers for the 3 most common calculations: > > array_size(a, b): 2-dimensional array > array3_size(a, b, c): 2-dimensional array yeah... complete confusion... > +/**

Re: [PATCH 03/13] overflow.h: Add allocation size calculation helpers

On 2018-05-09 02:42, Kees Cook wrote: > In preparation for replacing unchecked overflows for memory allocations, > this creates helpers for the 3 most common calculations: > > array_size(a, b): 2-dimensional array > array3_size(a, b, c): 2-dimensional array yeah... complete confusion... > +/**

Re: [PATCH 04/13] mm: Use array_size() helpers for kmalloc()

On 2018-05-09 13:34, Matthew Wilcox wrote: > On Tue, May 08, 2018 at 05:42:20PM -0700, Kees Cook wrote: >> @@ -499,6 +500,8 @@ static __always_inline void *kmalloc_large(size_t size, >> gfp_t flags) >> */ >> static __always_inline void *kmalloc(size_t size, gfp_t flags) >> { >> +if (size

Re: [PATCH 04/13] mm: Use array_size() helpers for kmalloc()

On 2018-05-09 13:34, Matthew Wilcox wrote: > On Tue, May 08, 2018 at 05:42:20PM -0700, Kees Cook wrote: >> @@ -499,6 +500,8 @@ static __always_inline void *kmalloc_large(size_t size, >> gfp_t flags) >> */ >> static __always_inline void *kmalloc(size_t size, gfp_t flags) >> { >> +if (size

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: [PATCH v5 2/2] dt/bindings: Add bindings for Layerscape external irqs

On 2018-03-02 20:49, Rob Herring wrote: > On Fri, Feb 23, 2018 at 10:09:00PM +0100, Rasmus Villemoes wrote: >> This adds Device Tree binding documentation for the external interrupt >> lines with configurable polarity present on some Layerscape SOCs. >> >> Sign

Re: [PATCH v5 2/2] dt/bindings: Add bindings for Layerscape external irqs

On 2018-03-02 20:49, Rob Herring wrote: > On Fri, Feb 23, 2018 at 10:09:00PM +0100, Rasmus Villemoes wrote: >> This adds Device Tree binding documentation for the external interrupt >> lines with configurable polarity present on some Layerscape SOCs. >> >> Sign

Re: [PATCH v5 1/2] irqchip: add support for Layerscape external interrupt lines

On 2018-03-01 13:16, Thomas Gleixner wrote: > On Fri, 23 Feb 2018, Rasmus Villemoes wrote: >> +#include >> +#include >> +#include >> +#include > > of.h is already included from of_irq.h and of_address.h Yes. But if we're ever going to have a chance of reduci

Re: [PATCH v5 1/2] irqchip: add support for Layerscape external interrupt lines

On 2018-03-01 13:16, Thomas Gleixner wrote: > On Fri, 23 Feb 2018, Rasmus Villemoes wrote: >> +#include >> +#include >> +#include >> +#include > > of.h is already included from of_irq.h and of_address.h Yes. But if we're ever going to have a chance of reduci

Re: [PATCH] proc: use #pragma once

On 2018-05-04 00:42, Al Viro wrote: > On Fri, May 04, 2018 at 12:14:57AM +0200, Rasmus Villemoes wrote: > >> FWIW, it's not just removing some identifiers from cpp's hash tables, it >> also reduces I/O: Due to our header mess, we have some cyclic includes, >> e.g mm.h ->

Re: [PATCH] proc: use #pragma once

On 2018-05-04 00:42, Al Viro wrote: > On Fri, May 04, 2018 at 12:14:57AM +0200, Rasmus Villemoes wrote: > >> FWIW, it's not just removing some identifiers from cpp's hash tables, it >> also reduces I/O: Due to our header mess, we have some cyclic includes, >> e.g mm.h ->

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

On 2018-05-01 19:00, Kees Cook wrote: > On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes > <li...@rasmusvillemoes.dk> wrote: >> >> gcc 5.1+ (I think) have the __builtin_OP_overflow checks that should >> generate reasonable code. Too bad

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

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_op

Re: [PATCH] proc: use #pragma once

On 2018-05-02 00:13, Andrew Morton wrote: > On Thu, 26 Apr 2018 22:24:44 +0300 Alexey Dobriyan > wrote: > >>> The LOC argument also does not sound very convincing. >> >> When was the last time you did -80 kLOC patch for free? > > That would be the way to do it - sell the

Re: [PATCH] proc: use #pragma once

On 2018-05-02 00:13, Andrew Morton wrote: > On Thu, 26 Apr 2018 22:24:44 +0300 Alexey Dobriyan > wrote: > >>> The LOC argument also does not sound very convincing. >> >> When was the last time you did -80 kLOC patch for free? > > That would be the way to do it - sell the idea to Linus, send

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

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

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

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

Re: [PATCH v5 10/11] vsprintf: WARN() on invalid pointer access

On 2018-04-25 13:12, Petr Mladek wrote: > > diff --git a/lib/test_printf.c b/lib/test_printf.c > index 45c33143fb4a..74dff6c44ec6 100644 > --- a/lib/test_printf.c > +++ b/lib/test_printf.c > @@ -285,12 +285,19 @@ null_pointer(void) > > #define PTR_INVALID ((void *)0x00ab) > > +extern

Re: [PATCH v5 10/11] vsprintf: WARN() on invalid pointer access

On 2018-04-25 13:12, Petr Mladek wrote: > > diff --git a/lib/test_printf.c b/lib/test_printf.c > index 45c33143fb4a..74dff6c44ec6 100644 > --- a/lib/test_printf.c > +++ b/lib/test_printf.c > @@ -285,12 +285,19 @@ null_pointer(void) > > #define PTR_INVALID ((void *)0x00ab) > > +extern

Re: [PATCH v3 1/6] ilog2: create truly constant version for sparse

On 2018-04-18 23:21, Linus Torvalds wrote: > On Wed, Apr 18, 2018 at 1:12 AM, Martin Wilck wrote: >> >> No, it doesn't (gcc 7.3.0). -> https://paste.opensuse.org/27471594 >> It doesn't even warn on an expression like this: >> >> #define SIZE (1<<10) >> static int

Re: [PATCH v3 1/6] ilog2: create truly constant version for sparse

On 2018-04-18 23:21, Linus Torvalds wrote: > On Wed, Apr 18, 2018 at 1:12 AM, Martin Wilck wrote: >> >> No, it doesn't (gcc 7.3.0). -> https://paste.opensuse.org/27471594 >> It doesn't even warn on an expression like this: >> >> #define SIZE (1<<10) >> static int foo[ilog2(SIZE)]; > > Ok, I

[PATCH v2] Kbuild: fix # escaping in .cmd files for future Make

defconfig with the new make. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap <rdun...@infradead.org> Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> --- v2: - squash the original objtool-only patch with the patch fixing up make-cmd, to avoid r

[PATCH v2] Kbuild: fix # escaping in .cmd files for future Make

defconfig with the new make. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap Signed-off-by: Rasmus Villemoes --- v2: - squash the original objtool-only patch with the patch fixing up make-cmd, to avoid repeating the reference to the Make NEWS. - use $(pound) in .cmd file

Re: [PATCH?] reiserfs: prevent panic: don't allow %-char in journal dev. name

On 2018-04-05 11:04, Rasmus Villemoes wrote: > On 2018-04-05 03:45, Andrew Morton wrote: >> >> Isn't the bug in journal_init_dev()? > > Urgh. At first I was about to reply that the real bug was in reiserfs.h > for failing to annotate __reiserfs_warning with

Re: [PATCH?] reiserfs: prevent panic: don't allow %-char in journal dev. name

On 2018-04-05 11:04, Rasmus Villemoes wrote: > On 2018-04-05 03:45, Andrew Morton wrote: >> >> Isn't the bug in journal_init_dev()? > > Urgh. At first I was about to reply that the real bug was in reiserfs.h > for failing to annotate __reiserfs_warning with

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On 2018-04-06 13:43, Petr Mladek wrote: > On Thu 2018-04-05 16:55:35, Joe Perches wrote: >> On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote: >>> On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote: >>>> Even just git grep -1 -E '%p"$' finds %pt and %po

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On 2018-04-06 13:43, Petr Mladek wrote: > On Thu 2018-04-05 16:55:35, Joe Perches wrote: >> On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote: >>> On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote: >>>> Even just git grep -1 -E '%p"$' finds %pt and %po

Re: [PATCH v4 8/9] vsprintf: Prevent crash when dereferencing invalid pointers

On 2018-04-06 14:26, Petr Mladek wrote: > On Thu 2018-04-05 16:46:23, Rasmus Villemoes wrote: >> On 2018-04-04 10:58, Petr Mladek wrote: >> >>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c >>> index 3551b7957d9e..1a080a75a825 100644 >>> --- a/lib/vsprintf

Re: [PATCH v4 8/9] vsprintf: Prevent crash when dereferencing invalid pointers

On 2018-04-06 14:26, Petr Mladek wrote: > On Thu 2018-04-05 16:46:23, Rasmus Villemoes wrote: >> On 2018-04-04 10:58, Petr Mladek wrote: >> >>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c >>> index 3551b7957d9e..1a080a75a825 100644 >>> --- a/lib/vsprintf

Re: [PATCH v4 8/9] vsprintf: Prevent crash when dereferencing invalid pointers

On 2018-04-04 10:58, Petr Mladek wrote: > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index 3551b7957d9e..1a080a75a825 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -599,12 +599,46 @@ char *__string(char *buf, char *end, const char *s, > struct printf_spec spec) > return

Re: [PATCH v4 8/9] vsprintf: Prevent crash when dereferencing invalid pointers

On 2018-04-04 10:58, Petr Mladek wrote: > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index 3551b7957d9e..1a080a75a825 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -599,12 +599,46 @@ char *__string(char *buf, char *end, const char *s, > struct printf_spec spec) > return

Re: [PATCH 2/1] Kbuild: fix # escaping in .cmd files for future Make

On 2018-03-26 13:48, Masahiro Yamada wrote: > 2018-03-26 8:09 GMT+09:00 Rasmus Villemoes <li...@rasmusvillemoes.dk>: >> The latest official Make release is 4.2.1 from mid-2016, but the current >> git release has this relevant note in the NEWS file: >> >> *

Re: [PATCH 2/1] Kbuild: fix # escaping in .cmd files for future Make

On 2018-03-26 13:48, Masahiro Yamada wrote: > 2018-03-26 8:09 GMT+09:00 Rasmus Villemoes : >> The latest official Make release is 4.2.1 from mid-2016, but the current >> git release has this relevant note in the NEWS file: >> >> * WARNING: Backward-incompati

Re: [PATCH v4 8/9] vsprintf: Prevent crash when dereferencing invalid pointers

On 2018-04-04 10:58, Petr Mladek wrote: > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index 3551b7957d9e..1a080a75a825 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -599,12 +599,46 @@ char *__string(char *buf, char *end, const char *s, > struct printf_spec spec) > return

Re: [PATCH v4 8/9] vsprintf: Prevent crash when dereferencing invalid pointers

On 2018-04-04 10:58, Petr Mladek wrote: > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index 3551b7957d9e..1a080a75a825 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -599,12 +599,46 @@ char *__string(char *buf, char *end, const char *s, > struct printf_spec spec) > return

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On 2018-04-04 10:58, Petr Mladek wrote: > There are few printk formats that make sense only with two or more > specifiers. Also some specifiers make sense only when a kernel feature > is enabled. > > The handling of unknown specifiers is strange, inconsistent, and > even leaking the address. For

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On 2018-04-04 10:58, Petr Mladek wrote: > There are few printk formats that make sense only with two or more > specifiers. Also some specifiers make sense only when a kernel feature > is enabled. > > The handling of unknown specifiers is strange, inconsistent, and > even leaking the address. For

Re: [PATCH v4 3/9] vsprintf: Do not check address of well-known strings

On 2018-04-04 10:58, Petr Mladek wrote: > We are going to check the address using probe_kernel_address(). It will > be more expensive and it does not make sense for well known address. > > This patch splits the string() function. The variant without the check > is then used on locations that

Re: [PATCH v4 3/9] vsprintf: Do not check address of well-known strings

On 2018-04-04 10:58, Petr Mladek wrote: > We are going to check the address using probe_kernel_address(). It will > be more expensive and it does not make sense for well known address. > > This patch splits the string() function. The variant without the check > is then used on locations that

Re: [PATCH?] reiserfs: prevent panic: don't allow %-char in journal dev. name

On 2018-04-05 03:45, Andrew Morton wrote: > On Wed, 4 Apr 2018 18:25:16 -0700 Randy Dunlap wrote: > >> From: Randy Dunlap >> >> If the reiserfs mount option's journal name contains a '%' character, >> it can lead to a WARN_ONCE() in

Re: [PATCH?] reiserfs: prevent panic: don't allow %-char in journal dev. name

On 2018-04-05 03:45, Andrew Morton wrote: > On Wed, 4 Apr 2018 18:25:16 -0700 Randy Dunlap wrote: > >> From: Randy Dunlap >> >> If the reiserfs mount option's journal name contains a '%' character, >> it can lead to a WARN_ONCE() in lib/vsprintf.c::format_decode(), >> saying: "Please remove

Re: [PATCHv3] gpio: Remove VLA from gpiolib

On 2018-03-28 20:18, Laura Abbott wrote: > The new challenge is to remove VLAs from the kernel > (see https://lkml.org/lkml/2018/3/7/621) to eventually > turn on -Wvla. > > Using a kmalloc array is the easy way to fix this but kmalloc is still > more expensive than stack allocation. Introduce a

Re: [PATCHv3] gpio: Remove VLA from gpiolib

On 2018-03-28 20:18, Laura Abbott wrote: > The new challenge is to remove VLAs from the kernel > (see https://lkml.org/lkml/2018/3/7/621) to eventually > turn on -Wvla. > > Using a kmalloc array is the easy way to fix this but kmalloc is still > more expensive than stack allocation. Introduce a

[PATCH 2/1] Kbuild: fix # escaping in .cmd files for future Make

fixing up the .cmd file escaping - without this, make always thinks the command string has changed and hence rebuilds everything. Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> --- So the previous patch made everything build, but building again revealed that this central plac

[PATCH 2/1] Kbuild: fix # escaping in .cmd files for future Make

fixing up the .cmd file escaping - without this, make always thinks the command string has changed and hence rebuilds everything. Signed-off-by: Rasmus Villemoes --- So the previous patch made everything build, but building again revealed that this central place very much also needed fixing.

[PATCH] objtool: fix build with future Make

.FEATURES variable. There are likely other places in the tree that will need fixing, so cc-ing Kbuild, but with this at least a x86-64 defconfig builds. Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> --- tools/objtool/Makefile | 2 +- tools/scripts/Makefile.include

[PATCH] objtool: fix build with future Make

.FEATURES variable. There are likely other places in the tree that will need fixing, so cc-ing Kbuild, but with this at least a x86-64 defconfig builds. Signed-off-by: Rasmus Villemoes --- tools/objtool/Makefile | 2 +- tools/scripts/Makefile.include | 2 ++ 2 files changed, 3 insert

Re: [PATCH 3/4] mm: Add free()

On 2018-03-22 20:58, Matthew Wilcox wrote: > From: Matthew Wilcox > > free() can free many different kinds of memory. I'd be a bit worried about using that name. gcc very much knows about the C standard's definition of that function, as can be seen on godbolt.org by

Re: [PATCH 3/4] mm: Add free()

On 2018-03-22 20:58, Matthew Wilcox wrote: > From: Matthew Wilcox > > free() can free many different kinds of memory. I'd be a bit worried about using that name. gcc very much knows about the C standard's definition of that function, as can be seen on godbolt.org by compiling void free(const

[RFC resend 2/2] modpost: sumversions: try to fix "same dir" logic

le using . as starting point, we include it - otherwise it was found via some -I path, so do not include it". In any case, this is mostly just something I stumbled on because I'm about to change the .o.cmd layout slightly, so I'd like to know what the rules are really supposed to be. Signed-off-b

[RFC resend 2/2] modpost: sumversions: try to fix "same dir" logic

le using . as starting point, we include it - otherwise it was found via some -I path, so do not include it". In any case, this is mostly just something I stumbled on because I'm about to change the .o.cmd layout slightly, so I'd like to know what the rules are really supposed to be. Signed-off-by

[RFC resend 1/2] modpost: delete stale comment

Commit (7840fea200cd "kbuild: Fix computing srcversion for modules") fixed the comment above parse_source_files to refer to the new source_ line, but left this one behind that could still give the impression that drivers/net/dummy.c appears in the deps_ variable. Signed-off-by: Rasmus

[RFC resend 1/2] modpost: delete stale comment

Commit (7840fea200cd "kbuild: Fix computing srcversion for modules") fixed the comment above parse_source_files to refer to the new source_ line, but left this one behind that could still give the impression that drivers/net/dummy.c appears in the deps_ variable. Signed-off-by: Rasmus

[PATCH] MAINTAINERS: Update Kbuild entry with a few paths

/Makefile itself, and add one matching the Kbuild.include file as well. Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> --- Hi Kbuild maintainers. Hope you don't mind me extending this entry a bit. MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff

[PATCH] MAINTAINERS: Update Kbuild entry with a few paths

/Makefile itself, and add one matching the Kbuild.include file as well. Signed-off-by: Rasmus Villemoes --- Hi Kbuild maintainers. Hope you don't mind me extending this entry a bit. MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index

[RFC PATCH 2/2] modpost: sumversions: try to fix "same dir" logic

le using . as starting point, we include it - otherwise it was found via some -I path, so do not include it". In any case, this is mostly just something I stumbled on because I'm about to change the .o.cmd layout slightly, so I'd like to know what the rules are really supposed to be. Signed-off-by:

[RFC PATCH 2/2] modpost: sumversions: try to fix "same dir" logic

le using . as starting point, we include it - otherwise it was found via some -I path, so do not include it". In any case, this is mostly just something I stumbled on because I'm about to change the .o.cmd layout slightly, so I'd like to know what the rules are really supposed to be. Signed-off-by: Ra

[RFC PATCH 1/2] modpost: delete stale comment

Commit (7840fea200cd "kbuild: Fix computing srcversion for modules") fixed the comment above parse_source_files to refer to the new source_ line, but left this one behind that could still give the impression that drivers/net/dummy.c appears in the deps_ variable. Signed-off-by: Rasmus

[RFC PATCH 1/2] modpost: delete stale comment

Commit (7840fea200cd "kbuild: Fix computing srcversion for modules") fixed the comment above parse_source_files to refer to the new source_ line, but left this one behind that could still give the impression that drivers/net/dummy.c appears in the deps_ variable. Signed-off-by: Rasmus

Re: detecting integer constant expressions in macros

On 2018-03-21 00:08, Linus Torvalds wrote: > On Tue, Mar 20, 2018 at 3:13 PM, Uecker, Martin > wrote: >> >> here is an idea: > > That's not "an idea". > > That is either genius, or a seriously diseased mind. > > I can't quite tell which. > >> a test for

Re: detecting integer constant expressions in macros

On 2018-03-21 00:08, Linus Torvalds wrote: > On Tue, Mar 20, 2018 at 3:13 PM, Uecker, Martin > wrote: >> >> here is an idea: > > That's not "an idea". > > That is either genius, or a seriously diseased mind. > > I can't quite tell which. > >> a test for integer constant expressions which

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 2018-03-18 22:33, Linus Torvalds wrote: > On Sun, Mar 18, 2018 at 2:13 PM, Rasmus Villemoes > <li...@rasmusvillemoes.dk> wrote: >> On 2018-03-17 19:52, Linus Torvalds wrote: >>> >>> Ok, so it really looks like that same "__builtin_constant_p() does

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 2018-03-18 22:33, Linus Torvalds wrote: > On Sun, Mar 18, 2018 at 2:13 PM, Rasmus Villemoes > wrote: >> On 2018-03-17 19:52, Linus Torvalds wrote: >>> >>> Ok, so it really looks like that same "__builtin_constant_p() doesn't >>> return a constant&

Re: [PATCH] vfs: make sure struct filename->iname is word-aligned

On 2018-03-01 00:19, Rasmus Villemoes wrote: > I noticed that offsetof(struct filename, iname) is actually 28 on 64 > bit platforms, so we always pass an unaligned pointer to > strncpy_from_user. This is mostly a problem for those 64 bit platforms > without HAVE_EFFICIENT_UNAL

Re: [PATCH] vfs: make sure struct filename->iname is word-aligned

On 2018-03-01 00:19, Rasmus Villemoes wrote: > I noticed that offsetof(struct filename, iname) is actually 28 on 64 > bit platforms, so we always pass an unaligned pointer to > strncpy_from_user. This is mostly a problem for those 64 bit platforms > without HAVE_EFFICIENT_UNAL

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 2018-03-17 19:52, Linus Torvalds wrote: > On Sat, Mar 17, 2018 at 12:27 AM, Kees Cook wrote: >> >> Unfortunately my 4.4 test fails quickly: >> >> ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’: >> ./include/linux/jiffies.h:444: error: first argument to

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 2018-03-17 19:52, Linus Torvalds wrote: > On Sat, Mar 17, 2018 at 12:27 AM, Kees Cook wrote: >> >> Unfortunately my 4.4 test fails quickly: >> >> ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’: >> ./include/linux/jiffies.h:444: error: first argument to >>

Re: [PATCH 1/4] gpio: Remove VLA from gpiolib

On 2018-03-18 15:23, Lukas Wunner wrote: >>> >>> Other random thoughts: maybe two allocations for each loop iteration is >>> a bit much. Maybe do a first pass over the array and collect the maximal >>> chip->ngpio, do the memory allocation and freeing outside the loop (then >>> you'd of course

Re: [PATCH 1/4] gpio: Remove VLA from gpiolib

On 2018-03-18 15:23, Lukas Wunner wrote: >>> >>> Other random thoughts: maybe two allocations for each loop iteration is >>> a bit much. Maybe do a first pass over the array and collect the maximal >>> chip->ngpio, do the memory allocation and freeing outside the loop (then >>> you'd of course

Re: [PATCH][RFC] kernel.h: provide array iterator

On 2018-03-15 11:00, Kieran Bingham wrote: > Simplify array iteration with a helper to iterate each entry in an array. > Utilise the existing ARRAY_SIZE macro to identify the length of the array > and pointer arithmetic to process each item as a for loop. > > Signed-off-by: Kieran Bingham

Re: [PATCH][RFC] kernel.h: provide array iterator

On 2018-03-15 11:00, Kieran Bingham wrote: > Simplify array iteration with a helper to iterate each entry in an array. > Utilise the existing ARRAY_SIZE macro to identify the length of the array > and pointer arithmetic to process each item as a for loop. > > Signed-off-by: Kieran Bingham > ---

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On 2018-03-16 00:46, Linus Torvalds wrote: > On Thu, Mar 15, 2018 at 4:41 PM, Kees Cook wrote: >> >> I much prefer explicit typing, but both you and Rasmus mentioned >> wanting the int/sizeof_t mixing. > > Well, the explicit typing allows that mixing, in that you can just

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On 2018-03-16 00:46, Linus Torvalds wrote: > On Thu, Mar 15, 2018 at 4:41 PM, Kees Cook wrote: >> >> I much prefer explicit typing, but both you and Rasmus mentioned >> wanting the int/sizeof_t mixing. > > Well, the explicit typing allows that mixing, in that you can just > have

[PATCH] x86: vdso: eliminate some redundant loads in update_vsyscall

old new delta update_vsyscall 480 398 -82 (i386) update_vsyscall 304 281 -23 (x86_64) Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> --- Other tricks are possible (reuse the init

[PATCH] x86: vdso: eliminate some redundant loads in update_vsyscall

old new delta update_vsyscall 480 398 -82 (i386) update_vsyscall 304 281 -23 (x86_64) Signed-off-by: Rasmus Villemoes --- Other tricks are possible (reuse the initial monotonic_time computation for th

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On 2018-03-14 15:09, Petr Mladek wrote: > diff --git a/lib/test_printf.c b/lib/test_printf.c > index 71ebfa43ad05..61c05a352d79 100644 > --- a/lib/test_printf.c > +++ b/lib/test_printf.c > @@ -207,14 +207,15 @@ test_string(void) > @@ -256,18 +259,18 @@ plain_hash(void) > * after an address is

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On 2018-03-14 15:09, Petr Mladek wrote: > diff --git a/lib/test_printf.c b/lib/test_printf.c > index 71ebfa43ad05..61c05a352d79 100644 > --- a/lib/test_printf.c > +++ b/lib/test_printf.c > @@ -207,14 +207,15 @@ test_string(void) > @@ -256,18 +259,18 @@ plain_hash(void) > * after an address is

Re: [PATCH] test_rhashtable: avoid gcc-8 -Wformat-overflow warning

On 2018-03-13 14:21, Arnd Bergmann wrote: > gcc-8 warns about a code pattern that is used in the newly added > test_rhashtable code: > > lib/test_rhashtable.c: In function 'print_ht': > lib/test_rhashtable.c:511:21: error: ' > bucket[' directive writing 8 bytes into a region of size between 1 and

Re: [PATCH] test_rhashtable: avoid gcc-8 -Wformat-overflow warning

On 2018-03-13 14:21, Arnd Bergmann wrote: > gcc-8 warns about a code pattern that is used in the newly added > test_rhashtable code: > > lib/test_rhashtable.c: In function 'print_ht': > lib/test_rhashtable.c:511:21: error: ' > bucket[' directive writing 8 bytes into a region of size between 1 and

Re: [PATCH 1/4] gpio: Remove VLA from gpiolib

On 2018-03-13 00:40, Laura Abbott wrote: > On 03/12/2018 08:00 AM, Rasmus Villemoes wrote: >> >> Hm, it seems you're now only clearing the first word of mask, not the >> entire allocation. Why not just use kcalloc() instead of kmalloc_array >> to have it automatically c

Re: [PATCH 1/4] gpio: Remove VLA from gpiolib

On 2018-03-13 00:40, Laura Abbott wrote: > On 03/12/2018 08:00 AM, Rasmus Villemoes wrote: >> >> Hm, it seems you're now only clearing the first word of mask, not the >> entire allocation. Why not just use kcalloc() instead of kmalloc_array >> to have it automatically c

Re: [PATCH 1/4] gpio: Remove VLA from gpiolib

On 2018-03-10 01:10, Laura Abbott wrote: > /* collect all inputs belonging to the same chip */ > first = i; > - memset(mask, 0, sizeof(mask)); > + memset(mask, 0, sizeof(*mask)); see below > @@ -2887,14 +2909,30 @@ void

Re: [PATCH 1/4] gpio: Remove VLA from gpiolib

On 2018-03-10 01:10, Laura Abbott wrote: > /* collect all inputs belonging to the same chip */ > first = i; > - memset(mask, 0, sizeof(mask)); > + memset(mask, 0, sizeof(*mask)); see below > @@ -2887,14 +2909,30 @@ void

Re: a Heisenbug tale

On 2018-03-09 10:45, Ard Biesheuvel wrote: > On 8 March 2018 at 23:19, Rasmus Villemoes <li...@rasmusvillemoes.dk> wrote: >> On 2018-03-07 20:25, Leonard Crestez wrote: >>> Hello, >>> >> >> What we ended up doing was to explicitly set the mtime of ev

Re: a Heisenbug tale

On 2018-03-09 10:45, Ard Biesheuvel wrote: > On 8 March 2018 at 23:19, Rasmus Villemoes wrote: >> On 2018-03-07 20:25, Leonard Crestez wrote: >>> Hello, >>> >> >> What we ended up doing was to explicitly set the mtime of every file in >> the repo to t

a Heisenbug tale (was: Re: arm crypto .S_shipped files sometimes get rebuilt randomly)

On 2018-03-07 20:25, Leonard Crestez wrote: > Hello, > > I am using a toolchain with a broken/old version of perl which doesn't > include integer.pm and I noticed it triggers occasional build failures > on arch/arm64/crypto/sha512-core.S_shipped. Workarounds are easy, but > if the purpose of the

a Heisenbug tale (was: Re: arm crypto .S_shipped files sometimes get rebuilt randomly)

On 2018-03-07 20:25, Leonard Crestez wrote: > Hello, > > I am using a toolchain with a broken/old version of perl which doesn't > include integer.pm and I noticed it triggers occasional build failures > on arch/arm64/crypto/sha512-core.S_shipped. Workarounds are easy, but > if the purpose of the

Re: [PATCH 0/3] Remove accidental VLA usage

On 8 March 2018 at 21:39, Kees Cook <keesc...@chromium.org> wrote: > On Thu, Mar 8, 2018 at 11:57 AM, Rasmus Villemoes > <li...@rasmusvillemoes.dk> wrote: >> On 2018-03-08 16:02, Josh Poimboeuf wrote: >>> On Wed, Mar 07, 2018 at 07:30:44PM -0800,

Re: [PATCH 0/3] Remove accidental VLA usage

On 8 March 2018 at 21:39, Kees Cook wrote: > On Thu, Mar 8, 2018 at 11:57 AM, Rasmus Villemoes > wrote: >> On 2018-03-08 16:02, Josh Poimboeuf wrote: >>> On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote: >>> +extern long __error_incompatible_types_

Re: [PATCH 0/3] Remove accidental VLA usage

On 2018-03-08 16:02, Josh Poimboeuf wrote: > On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote: >> This series adds SIMPLE_MAX() to be used in places where a stack array >> is actually fixed, but the compiler still warns about VLA usage due to >> confusion caused by the safety checks in

Re: [PATCH 0/3] Remove accidental VLA usage

On 2018-03-08 16:02, Josh Poimboeuf wrote: > On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote: >> This series adds SIMPLE_MAX() to be used in places where a stack array >> is actually fixed, but the compiler still warns about VLA usage due to >> confusion caused by the safety checks in

Re: [PATCH v2 1/3] vsprintf: Remove accidental VLA usage

On 2018-03-08 04:30, Kees Cook wrote: > In the quest to remove all stack VLAs from the kernel[1], this introduces > a new "simple max" macro, and changes the "sym" array size calculation to > use it. The value is actually a fixed size, but since the max() macro uses > some extensive tricks for

Re: [PATCH v2 1/3] vsprintf: Remove accidental VLA usage

On 2018-03-08 04:30, Kees Cook wrote: > In the quest to remove all stack VLAs from the kernel[1], this introduces > a new "simple max" macro, and changes the "sym" array size calculation to > use it. The value is actually a fixed size, but since the max() macro uses > some extensive tricks for

Re: [PATCH] staging: lustre: Remove VLA usage

On Wed, Mar 07 2018, Kees Cook <keesc...@chromium.org> wrote: > On Wed, Mar 7, 2018 at 5:10 AM, Rasmus Villemoes > <rasmus.villem...@prevas.dk> wrote: >> On 2018-03-07 06:46, Kees Cook wrote: >>> The kernel would like to remove all VLA usage. This switches to

<    6   7   8   9   10   11   12   13   14   15   >