linux-kernel - Re: [PATCH -next] orangefs: use vzalloc() instead of vmalloc()/memset(0)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOg9mSSre72QcYjN-=2i49JMfttkBN2KiTo7uSKAgmN7YwA=Pg@mail.gmail.com>
Date:	Wed, 6 Jul 2016 15:01:26 -0400
From:	Mike Marshall <hubcap@...ibond.com>
To:	Joe Perches <joe@...ches.com>, Mike Marshall <hubcap@...ibond.com>
Cc:	weiyj_lk@....com, Wei Yongjun <yongjun_wei@...ndmicro.com.cn>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next] orangefs: use vzalloc() instead of vmalloc()/memset(0)

Joe> That's incorrect.

<blush>... you are right. They mostly return -ENOMEM, but they
mostly don't print an error message. I like printing an error message
when I resolve to an error... a whole bunch of that function is sanity
checking input from userspace, with a specific error message for
any particular failure.

Joe> I don't see how that matters here as there's
Joe> already an OOM on v.alloc failure.

I'd find that if needed, but the first place I'd look when investigating
an Orangefs failure would be the Orangefs logs...

-Mike

On Wed, Jul 6, 2016 at 2:11 PM, Joe Perches <joe@...ches.com> wrote:
> On Wed, 2016-07-06 at 14:00 -0400, Mike Marshall wrote:
>> Hi Joe...
>
> Hi Mike.
>
>> I looked around at other code to see how they were using vzalloc...
>> even if it is just the caller of the function that uses vzalloc, most
>> fs's that use vzalloc print an error message when vzalloc fails...
>
> That's incorrect.
>
> There are 72 v.alloc calls in fs/
> 2 of those calls have a specific OOM message.
> There's 1 in reiserfs (old and unsupported) and 1 in orangefs
>
>>  I sure do
>> like to follow the flow of our kernel module all in one place
>> with the gossip statements...
>
> I don't see how that matters here as there's
> already an OOM on v.alloc failure.
>
> cheers, Joe