linux-kernel - Re: [PATCH 01/10] perf, tools: Factor out scale conversion code

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 14 Oct 2016 13:25:11 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Andi Kleen <ak@...ux.intel.com>
Cc:     Andi Kleen <andi@...stfloor.org>, jolsa@...nel.org,
        sukadev@...ux.vnet.ibm.com, eranian@...gle.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/10] perf, tools: Factor out scale conversion code

Em Fri, Oct 14, 2016 at 09:15:16AM -0700, Andi Kleen escreveu:
> On Fri, Oct 14, 2016 at 01:08:42PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 14, 2016 at 08:45:15AM -0700, Andi Kleen escreveu:
> > > > So if we can't convert the scale because of an allocation failure
> > > > related to locale issues we silently trow it away and do no scale at
> > > > all?
> > 
> > > That is right. If your machine is thrashing to death in a OOM this
> > > is your smallest problem.
> > 
> > Please keep it was before, i.e. return an error value, and bail out. It
> > was like that before, why introduce these kinds of silent "do something
> > else in an unlikely case" handling?
> 
> Ok. I will fix it.
> 
> But just for the record I don't think this fine grained memory error
> handling makes any sense for perf. It is needed in the kernel, but
> it's not appropiate for user programs:
> 
> - Usually when you're out of memory then every thing afterward
> that needs memory will fail too, so there's no sane way to continue,
> - When you run out of memory in user space you usually get killed
> at some point anyways because the OOM killer kicks in.
> - The only exception is that you run out of VA space, but then the point
> above applies.
> - These error paths are all untested and most likely a significant
> fraction of them is broken because untested code is often broken.
> 
> What most user space does is to just have malloc wrappers that
> exit when you run out of memory with an error message. That's nearly
> always the right strategy for user programs.

I disagree, and I usually try not to differentiate that much if I'm
programming for the kernel or for userspace, in fact, I try as much as
possible to reduce the gap of writing for the kernel or writing for
userspace.

I tools/ specifically, I try to use the same constructs, list.h, rbtree,
WARN_, pr_, etc, not panic()'ing, etc.

In this specific case, doing a:

   printf("life is hard, I give up"); exit(1);

would be preferrable to silently not doing what was asked for, namely do
the scaling, with that said, please keep the original way of handling it
and just return an error when what was asked for can't be done.

Thanks,

- Arnaldo