On Wed, Sep 8, 2021 at 10:55 PM Nathan Chancellor wrote:
> On Tue, Sep 07, 2021 at 11:11:17AM +0200, Arnd Bergmann wrote:
> > On Tue, Sep 7, 2021 at 4:32 AM Nathan Chancellor wrote:
function 'rtw_aes_decrypt' [-Werror,-Wframe-larger-than]
> > > arm32-fedora.log:
> > > drivers/gpu/drm/amd/amdgpu/
On Wed, Sep 8, 2021 at 10:59 PM Christoph Hellwig wrote:
>
> While we're at it, with -Werror something like this is really futile:
Yeah, I'm thinking we could do
-Wno-error=cpp
to at least allow the cpp warnings to come through without being fatal.
Because while they can be annoying too, they
On Thu, Sep 9, 2021 at 4:43 AM Marco Elver wrote:
>
> Sure, but the reality is that the real stack size is already doubled
> for KASAN. And that should be reflected in Wframe-larger-than.
I don't think that's true.
Quite the reverse, in fact.
Yes, the *dynamic* stack size is doubled due to KASA
On 9/9/21 12:30 AM, Christian König wrote:
Am 09.09.21 um 08:07 schrieb Guenter Roeck:
On 9/8/21 10:58 PM, Christoph Hellwig wrote:
On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
It'd be good to avoid. It has helped uncover build issues with KASAN in
the past. Or at least make it
On Thu, Sep 9, 2021 at 1:43 PM Marco Elver wrote:
> On Thu, 9 Sept 2021 at 13:00, Arnd Bergmann wrote:
> > On Thu, Sep 9, 2021 at 12:54 PM Marco Elver wrote:
> > > On Thu, 9 Sept 2021 at 07:59, Christoph Hellwig
> > > wrote:
> > > > On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
On Thu, Sep 9, 2021 at 12:54 PM Marco Elver wrote:
> On Thu, 9 Sept 2021 at 07:59, Christoph Hellwig wrote:
> > On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
> > > It'd be good to avoid. It has helped uncover build issues with KASAN in
> > > the past. Or at least make it dependent
Am 09.09.21 um 08:07 schrieb Guenter Roeck:
On 9/8/21 10:58 PM, Christoph Hellwig wrote:
On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
It'd be good to avoid. It has helped uncover build issues with KASAN in
the past. Or at least make it dependent on the problematic
architecture.
On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
> It'd be good to avoid. It has helped uncover build issues with KASAN in
> the past. Or at least make it dependent on the problematic architecture.
> For example if arm is a problem, something like this:
I'm also seeing quite a few stac
On 9/8/21 10:58 PM, Christoph Hellwig wrote:
On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
It'd be good to avoid. It has helped uncover build issues with KASAN in
the past. Or at least make it dependent on the problematic architecture.
For example if arm is a problem, something li
On 2021-09-08 12:41 a.m., Linus Torvalds wrote:
> On Tue, Sep 7, 2021 at 8:52 PM Harry Wentland wrote:
>>
>> Attached patches fix these x86_64 ones reported by Nick:
>
> Hmm.
>
> You didn't seem to fix up the calling convention for print__xyz(),
> which still take those xyz structs as pass-by
On Tue, Sep 7, 2021 at 10:10 AM Linus Torvalds
wrote:
>
> Do I know why? No. I do note that that code is disgusting.
>
> It's passing one of those structs around by value, for example. That's
> a 72-byte structure that is copied on the stack due to stupid calling
> conventions. Maybe clang generat
On Tue, Sep 7, 2021 at 8:52 PM Harry Wentland wrote:
>
> Attached patches fix these x86_64 ones reported by Nick:
Hmm.
You didn't seem to fix up the calling convention for print__xyz(),
which still take those xyz structs as pass-by-value.
Obviously it would be good to do things incrementally, s
On 2021-09-07 5:07 p.m., Harry Wentland wrote:
>
>
> On 2021-09-07 1:33 p.m., Linus Torvalds wrote:
>> On Tue, Sep 7, 2021 at 10:10 AM Linus Torvalds
>> wrote:
>>>
>>> Do I know why? No. I do note that that code is disgusting.
>>>
>>> It's passing one of those structs around by value, for exam
On 2021-09-07 1:33 p.m., Linus Torvalds wrote:
> On Tue, Sep 7, 2021 at 10:10 AM Linus Torvalds
> wrote:
>>
>> Do I know why? No. I do note that that code is disgusting.
>>
>> It's passing one of those structs around by value, for example. That's
>> a 72-byte structure that is copied on the sta
14 matches
Mail list logo
