Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1040048ybx; Thu, 31 Oct 2019 04:56:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqy6s1hXdIP0CIHNbmlzCaBDGFaLq/k7tvs3S4VBHot2m+m/adwcfTkvM/T8o20jM5pcHhDg X-Received: by 2002:a05:6402:797:: with SMTP id d23mr5490765edy.83.1572522960018; Thu, 31 Oct 2019 04:56:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572522960; cv=none; d=google.com; s=arc-20160816; b=DyYDSeXT2KmdENyTjruljx9L7TdAhySvefpD2r5BsfpSvBr6dYoBfzCkKDQqtp6vDv 4ctJtpMwGFPJAShuWeB9vbXF5G7qBmnGhM3kQ2/jxjmhHuJLVshi2YTxzbK4C1v9A89B cmMdd3wLpdJqBIeY375LfXcMAe2sZ1XXQDSxBwBBwAsHFkhKE5jzehwimMJ3KwC6j2m+ imItrK8D95jmzhSLrCjesCtwFLT7x+HhGt4WjG5CrkraCd+xOXuHLBXJ+BHO/DAYg56D 5IMxdSriFX0Ac0lWVhGAk+z9LTNSJ1ZItorvH0LmoDvkTYPIvTploCaSnuq9WAWRqQEr 5mMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :references:subject:cc:to:mime-version:user-agent:from:date :message-id; bh=U4hAoryPGxk5eziSamx+tifZ3j4dftr3OuQmBYkp25A=; b=heiuas9uixd418BJl2E6koBBYSlWSBrAYwtxECuqVEhB2hCRjsjDLVyBhuf6ATeOE1 Ql0LhjFTN9Ut32R1r91FqowgNrdJN4KLQUlgQTf6SzqnfGQ20JpiVPrRz8L6XMyRIRS3 YkReCTJQe4vO1D/6cj8B99aoV/IiBEOzT0v63/FY1Ajs3NfpyL5uBopG8NK4+tFGVwFp +FilkcMXr39eMJ1jG4+bGT77urt3xiXregOAyAgZCutWRzt7FjC85O46qyNWOuYeHkbh xprdDfwPqJ8IaPw1ARffX3sxEzOVm2X3yVD7UVov5UamHccY51Zhwke998UQEOXv+e1c tYFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id qw5si3331033ejb.91.2019.10.31.04.55.36; Thu, 31 Oct 2019 04:56:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726840AbfJaLyT (ORCPT + 99 others); Thu, 31 Oct 2019 07:54:19 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:5670 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726462AbfJaLyS (ORCPT ); Thu, 31 Oct 2019 07:54:18 -0400 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id AFEB454D48C72B19E600; Thu, 31 Oct 2019 19:54:14 +0800 (CST) Received: from [127.0.0.1] (10.133.219.218) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.439.0; Thu, 31 Oct 2019 19:54:10 +0800 Message-ID: <5DBACB61.90809@huawei.com> Date: Thu, 31 Oct 2019 19:54:09 +0800 From: zhong jiang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Borislav Petkov CC: , , , , , , Subject: Re: [PATCH] mm/ioremap: Use WARN_ONCE instead of printk() + WARN_ON_ONCE() References: <1572425838-39158-1-git-send-email-zhongjiang@huawei.com> <20191031110304.GE21133@nazgul.tnic> In-Reply-To: <20191031110304.GE21133@nazgul.tnic> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.133.219.218] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/10/31 19:03, Borislav Petkov wrote: > On Wed, Oct 30, 2019 at 04:57:18PM +0800, zhong jiang wrote: >> WARN_ONCE is more clear and simpler. Just replace it. >> >> Signed-off-by: zhong jiang >> --- >> arch/x86/mm/ioremap.c | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c >> index a39dcdb..3b74599 100644 >> --- a/arch/x86/mm/ioremap.c >> +++ b/arch/x86/mm/ioremap.c >> @@ -172,9 +172,8 @@ static void __ioremap_check_mem(resource_size_t addr, unsigned long size, >> return NULL; >> >> if (!phys_addr_valid(phys_addr)) { >> - printk(KERN_WARNING "ioremap: invalid physical address %llx\n", >> - (unsigned long long)phys_addr); >> - WARN_ON_ONCE(1); >> + WARN_ONCE(1, "ioremap: invalid physical address %llx\n", >> + (unsigned long long)phys_addr); > Does > WARN_ONCE(!phys_addr_valid(phys_addr), > "ioremap: invalid physical address %llx\n", > (unsigned long long)phys_addr); > > work too? > Look at this again, It should not works. Because that will change the logical. if phys_addr_valid is false, we should drop out in time. WARN_ONCE should be just visible for user not should to handle with address. Thanks, zhong jiang