linux-kernel - Re: [PATCH 1/3] regulator: bcm590xx: remove unnecessary OOM messages

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]

Message-ID: <CAD7vxxKT+Wq2ArH9iYLm2OUeBSqKvzORKZ1NnoyPcdcDH6wOKw@mail.gmail.com>
Date:	Mon, 2 Jun 2014 00:12:20 -0700
From:	Tim Kryger <tim.kryger@...il.com>
To:	Jingoo Han <jg1.han@...sung.com>
Cc:	Mark Brown <broonie@...nel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	linux-kernel@...r.kernel.org, Matt Porter <mporter@...aro.org>,
	Tim Kryger <tim.kryger@...aro.org>
Subject: Re: [PATCH 1/3] regulator: bcm590xx: remove unnecessary OOM messages

On Sun, Jun 1, 2014 at 11:27 PM, Jingoo Han <jg1.han@...sung.com> wrote:
> The site-specific OOM messages are unnecessary, because they
> duplicate the MM subsystem generic OOM message.
>
> Signed-off-by: Jingoo Han <jg1.han@...sung.com>
> ---
>  drivers/regulator/bcm590xx-regulator.c |   16 ++++------------
>  1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/regulator/bcm590xx-regulator.c b/drivers/regulator/bcm590xx-regulator.c
> index 57544e2..fb8c6f7 100644
> --- a/drivers/regulator/bcm590xx-regulator.c
> +++ b/drivers/regulator/bcm590xx-regulator.c
> @@ -326,10 +326,8 @@ static struct bcm590xx_board *bcm590xx_parse_dt_reg_data(
>         }
>
>         data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> -       if (!data) {
> -               dev_err(&pdev->dev, "failed to allocate regulator board data\n");
> +       if (!data)
>                 return NULL;
> -       }
>
>         np = of_node_get(np);
>         regulators = of_get_child_by_name(np, "regulators");
> @@ -374,10 +372,8 @@ static int bcm590xx_probe(struct platform_device *pdev)
>                                               &bcm590xx_reg_matches);
>
>         pmu = devm_kzalloc(&pdev->dev, sizeof(*pmu), GFP_KERNEL);
> -       if (!pmu) {
> -               dev_err(&pdev->dev, "Memory allocation failed for pmu\n");
> +       if (!pmu)
>                 return -ENOMEM;
> -       }
>
>         pmu->mfd = bcm590xx;
>
> @@ -385,17 +381,13 @@ static int bcm590xx_probe(struct platform_device *pdev)
>
>         pmu->desc = devm_kzalloc(&pdev->dev, BCM590XX_NUM_REGS *
>                         sizeof(struct regulator_desc), GFP_KERNEL);
> -       if (!pmu->desc) {
> -               dev_err(&pdev->dev, "Memory alloc fails for desc\n");
> +       if (!pmu->desc)
>                 return -ENOMEM;
> -       }
>
>         pmu->info = devm_kzalloc(&pdev->dev, BCM590XX_NUM_REGS *
>                         sizeof(struct bcm590xx_info *), GFP_KERNEL);
> -       if (!pmu->info) {
> -               dev_err(&pdev->dev, "Memory alloc fails for info\n");
> +       if (!pmu->info)
>                 return -ENOMEM;
> -       }
>
>         info = bcm590xx_regs;
>

For the other two drivers touched by this patch series, the probe
methods only include a single dynamic memory allocation.  As such, the
stack trace provided by the generic memory code is sufficient to
quickly identify where the failure occurred.

The probe method of this driver, on the other hand, performs several
allocations and the error messages you intend to remove conveniently
pinpoint which one failed.  While the offsets in the trace could be
used to derive the same information, I am skeptical that is enough to
justify removing the messages.

Thanks,
Tim Kryger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/