linux-kernel - Re: [PATCH 1/1] ACPI: bus.c, fix error handling in acpi_bus

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: <499FFC1A.7010906@gmail.com>
Date:	Sat, 21 Feb 2009 14:05:30 +0100
From:	Jiri Slaby <jirislaby@...il.com>
To:	Len Brown <lenb@...nel.org>
CC:	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] ACPI: bus.c, fix error handling in acpi_bus_init

On 21.2.2009 05:58, Len Brown wrote:
> On Sun, 15 Feb 2009, Jiri Slaby wrote:
>
>> There was a misplaced status test. Move it to correct place and
>> rollback appropriately.
>
> hmm, looks like this has been broken since the day
> acpi_os_initialize1() was invented in 2004.

It comes from bitkeeper times, I checked, it looked like a typo.

> Turns out that the bug and its fix are moot, however,
> as acpi_os_initialize1() is hard-coded to return success,
> opting for BUG_ON() if it sees a failure...

BUG_ON is not noreturn e.g. on embedded, anyway it would crash later in 
this case. I was thinking about returning a failure when one of them is 
NULL, but fell back to not do so and check only retval in the caller.

> So unless that changes, I'd prefer to keep the code
> simple and just not check its status -- which is effectively
> what we're doing right now.

Ok, no problem. Will repost.

Thanks.
--
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/