Replace a variable length array in a struct by allocating
the memory for the entire struct in a char array on the stack.
Signed-off-by: Michael Davidson
---
drivers/md/raid10.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
On Thu, Mar 16, 2017 at 05:15:19PM -0700, Michael Davidson wrote:
> Replace a variable length array in a struct by allocating
> the memory for the entire struct in a char array on the stack.
>
> Signed-off-by: Michael Davidson
> ---
> drivers/md/raid10.c | 9 -
> 1 file changed, 4 insert
On Fri, Mar 17, 2017 at 1:08 PM, Peter Zijlstra wrote:
> On Thu, Mar 16, 2017 at 05:15:19PM -0700, Michael Davidson wrote:
>> Replace a variable length array in a struct by allocating
>> the memory for the entire struct in a char array on the stack.
>>
>> Signed-off-by: Michael Davidson
>> ---
>>
On Fri, Mar 17, 2017 at 01:31:23PM +0100, Alexander Potapenko wrote:
> On Fri, Mar 17, 2017 at 1:08 PM, Peter Zijlstra wrote:
> > On Thu, Mar 16, 2017 at 05:15:19PM -0700, Michael Davidson wrote:
> >> Replace a variable length array in a struct by allocating
> >> the memory for the entire struct i
On Fri, Mar 17, 2017 at 1:31 PM, Alexander Potapenko wrote:
> On Fri, Mar 17, 2017 at 1:08 PM, Peter Zijlstra wrote:
>> On Thu, Mar 16, 2017 at 05:15:19PM -0700, Michael Davidson wrote:
>>> Replace a variable length array in a struct by allocating
>>> the memory for the entire struct in a char ar
On Fri, Mar 17, 2017 at 01:32:00PM +0100, Alexander Potapenko wrote:
> > IIUC there's only a handful of VLAIS instances in LLVM code, why not
> Sorry, "kernel code", not "LLVM code".
> > just drop them for the sake of better code portability?
And what happens if someone else adds a variable thing
On Fri, Mar 17, 2017 at 7:03 PM, Borislav Petkov wrote:
> On Fri, Mar 17, 2017 at 01:32:00PM +0100, Alexander Potapenko wrote:
>> > IIUC there's only a handful of VLAIS instances in LLVM code, why not
>> Sorry, "kernel code", not "LLVM code".
>> > just drop them for the sake of better code portabi
On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra wrote:
>
> Be that as it may; what you construct above is disgusting. Surely the
> code can be refactored to not look like dog vomit?
>
> Also; its not immediately obvious conf->copies is 'small' and this
> doesn't blow up the stack; I feel that dese
On Fri, Mar 17, 2017 at 07:47:33PM +0100, Dmitry Vyukov wrote:
> This problem is more general and is not specific to clang. It equally
> applies to different versions of gcc, different arches and different
> configs (namely, anything else than what a developer used for
> testing).
I guess. We do c
On Fri, Mar 17, 2017 at 7:57 PM, Borislav Petkov wrote:
> On Fri, Mar 17, 2017 at 07:47:33PM +0100, Dmitry Vyukov wrote:
>> This problem is more general and is not specific to clang. It equally
>> applies to different versions of gcc, different arches and different
>> configs (namely, anything els
On Fri, Mar 17, 2017 at 11:52:01AM -0700, Michael Davidson wrote:
> On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra wrote:
> >
> > Be that as it may; what you construct above is disgusting. Surely the
> > code can be refactored to not look like dog vomit?
> >
> > Also; its not immediately obvious
On Fri, Mar 17, 2017 at 08:05:16PM +0100, Dmitry Vyukov wrote:
> You can also find some reasons in the Why section of LLVM-Linux project:
> http://llvm.linuxfoundation.org/index.php/Main_Page
>From that:
- LLVM/Clang is a fast moving project with many things fixed quickly
and features added.
On Fri, Mar 17, 2017 at 08:26:42PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 17, 2017 at 08:05:16PM +0100, Dmitry Vyukov wrote:
> > You can also find some reasons in the Why section of LLVM-Linux project:
> > http://llvm.linuxfoundation.org/index.php/Main_Page
>
> From that:
>
> - LLVM/Clang is
On March 17, 2017 12:27:46 PM PDT, Peter Zijlstra wrote:
>On Fri, Mar 17, 2017 at 11:52:01AM -0700, Michael Davidson wrote:
>> On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra
> wrote:
>> >
>> > Be that as it may; what you construct above is disgusting. Surely
>the
>> > code can be refactored to no
Hi Dmitry,
On Fri, Mar 17, 2017 at 08:05:16PM +0100, Dmitry Vyukov wrote:
On Fri, Mar 17, 2017 at 7:57 PM, Borislav Petkov wrote:
On Fri, Mar 17, 2017 at 07:47:33PM +0100, Dmitry Vyukov wrote:
This problem is more general and is not specific to clang. It equally
applies to different versions
On Fri, Mar 17, 2017 at 9:04 PM, wrote:
> On March 17, 2017 12:27:46 PM PDT, Peter Zijlstra
> wrote:
>>On Fri, Mar 17, 2017 at 11:52:01AM -0700, Michael Davidson wrote:
>>> On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra
>> wrote:
>>> >
>>> > Be that as it may; what you construct above is disgu
On Fri, Mar 17, 2017 at 8:29 PM, Peter Zijlstra wrote:
> On Fri, Mar 17, 2017 at 08:26:42PM +0100, Peter Zijlstra wrote:
>> On Fri, Mar 17, 2017 at 08:05:16PM +0100, Dmitry Vyukov wrote:
>> > You can also find some reasons in the Why section of LLVM-Linux project:
>> > http://llvm.linuxfoundation.
On Fri, Mar 24, 2017 at 02:47:15PM +0100, Dmitry Vyukov wrote:
> > Seriously, you should have taken the hack the first time that this
> > needs to be fixed. Just because this is a fairly uncommon construct
> > in the kernel doesn't mean it is not in userspace.
>
> There is a reason why it is fair
On Fri, Mar 24, 2017 at 02:50:24PM +0100, Dmitry Vyukov wrote:
> OK, I guess should not have referenced the llvm-linux page.
> So here are reasons on our side that I am ready to vouch:
>
> - clang make it possible to implement KMSAN (dynamic detection of
> uses of uninit memory)
How does GCC mak
On Fri, Mar 24, 2017 at 3:10 PM, Peter Zijlstra wrote:
> On Fri, Mar 24, 2017 at 02:50:24PM +0100, Dmitry Vyukov wrote:
>> OK, I guess should not have referenced the llvm-linux page.
>> So here are reasons on our side that I am ready to vouch:
>>
>> - clang make it possible to implement KMSAN (dy
20 matches
Mail list logo