linux-kernel - Re: [PATCH v2 1/2] x86: Check return values from early

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 for Android: free password hash cracker in your pocket

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

Message-ID: <267d84e3-3fbe-f010-113a-805763b7a325@oracle.com>
Date:   Thu, 10 Nov 2022 14:30:26 -0500
From:   Ross Philipson <ross.philipson@...cle.com>
To:     Dave Hansen <dave.hansen@...el.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org
Cc:     dpsmith@...rtussolutions.com, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, hpa@...or.com, luto@...capital.net,
        dave.hansen@...ux.intel.com, kanth.ghatraju@...cle.com,
        trenchboot-devel@...glegroups.com, jailhouse-dev@...glegroups.com,
        jan.kiszka@...mens.com, xen-devel@...ts.xenproject.org,
        jgross@...e.com, boris.ostrovsky@...cle.com,
        andrew.cooper3@...rix.com
Subject: Re: [PATCH v2 1/2] x86: Check return values from early_memremap calls

On 11/10/22 11:07, Dave Hansen wrote:
> On 11/10/22 07:45, Ross Philipson wrote:
>>   	dt = early_memremap(initial_dtb, map_len);
>> +	if (!dt) {
>> +		pr_warn("failed to memremap initial dtb\n");
>> +		return;
>> +	}
> 
> Are all of these new pr_warn/err()'s really adding much value?  They all
> look pretty generic.  It makes me wonder if we should just spit out a
> generic message in early_memremap() and save all the callers the trouble.

These changes were prompted by some comments on an earlier patch set I 
sent. It was requested that I fix the other missing checks for NULL 
returns from these functions but I thought that was out of scope for 
that patch set. So I agreed to submit this set and add the checks making 
things consistent.

> 
> Oh, and don't we try to refer to functions() with parenthesis?

Yes I can fix that.

Thanks
Ross

>