From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CF56C48BE5 for ; Wed, 16 Jun 2021 01:47:29 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F260561356 for ; Wed, 16 Jun 2021 01:47:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F260561356 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A6E664066F; Wed, 16 Jun 2021 01:47:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caIbuV1X5pY6; Wed, 16 Jun 2021 01:47:27 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp4.osuosl.org (Postfix) with ESMTPS id 2C78840672; Wed, 16 Jun 2021 01:47:27 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id DAD9FC000E; Wed, 16 Jun 2021 01:47:26 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0EE5FC000B for ; Wed, 16 Jun 2021 01:47:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id EA64A83B23 for ; Wed, 16 Jun 2021 01:47:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Goo67T4CyYRR for ; Wed, 16 Jun 2021 01:47:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9250983B0E for ; Wed, 16 Jun 2021 01:47:24 +0000 (UTC) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4G4Sd53PxFz6y5T; Wed, 16 Jun 2021 09:43:21 +0800 (CST) Received: from dggpemm500006.china.huawei.com (7.185.36.236) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 16 Jun 2021 09:47:20 +0800 Received: from [127.0.0.1] (10.174.179.0) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 16 Jun 2021 09:47:19 +0800 Subject: Re: [PATCH 1/1] iommu/arm-smmu-v3: remove unnecessary oom message To: Will Deacon , Robin Murphy References: <20210609125438.14369-1-thunder.leizhen@huawei.com> <20210611103220.GB15274@willie-the-truck> <2a0b7f37-156a-775f-ade4-015cade472c6@huawei.com> <20210615113417.GA20598@willie-the-truck> <20210615115507.GD20598@willie-the-truck> From: "Leizhen (ThunderTown)" Message-ID: Date: Wed, 16 Jun 2021 09:47:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20210615115507.GD20598@willie-the-truck> Content-Language: en-US X-Originating-IP: [10.174.179.0] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected Cc: iommu , linux-arm-kernel X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2021/6/15 19:55, Will Deacon wrote: > On Tue, Jun 15, 2021 at 12:51:38PM +0100, Robin Murphy wrote: >> On 2021-06-15 12:34, Will Deacon wrote: >>> On Tue, Jun 15, 2021 at 07:22:10PM +0800, Leizhen (ThunderTown) wrote: >>>> >>>> >>>> On 2021/6/11 18:32, Will Deacon wrote: >>>>> On Wed, Jun 09, 2021 at 08:54:38PM +0800, Zhen Lei wrote: >>>>>> Fixes scripts/checkpatch.pl warning: >>>>>> WARNING: Possible unnecessary 'out of memory' message >>>>>> >>>>>> Remove it can help us save a bit of memory. >>>>>> >>>>>> Signed-off-by: Zhen Lei >>>>>> --- >>>>>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 8 ++------ >>>>>> 1 file changed, 2 insertions(+), 6 deletions(-) >>>>>> >>>>>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >>>>>> index 2ddc3cd5a7d1..fd7c55b44881 100644 >>>>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >>>>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >>>>>> @@ -2787,10 +2787,8 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu) >>>>>> void *strtab = smmu->strtab_cfg.strtab; >>>>>> cfg->l1_desc = devm_kzalloc(smmu->dev, size, GFP_KERNEL); >>>>>> - if (!cfg->l1_desc) { >>>>>> - dev_err(smmu->dev, "failed to allocate l1 stream table desc\n"); >>>>>> + if (!cfg->l1_desc) >>>>> >>>>> What error do you get if devm_kzalloc() fails? I'd like to make sure it's >>>>> easy to track down _which_ allocation failed in that case -- does it give >>>>> you a line number, for example? >>>> >>>> When devm_kzalloc() fails, the OOM information is printed. No line number information, but the >>>> size(order) and call stack is printed. It doesn't matter which allocation failed, the failure >>>> is caused by insufficient system memory rather than the fault of the SMMU driver. Therefore, >>>> the current printing is not helpful for locating the problem of insufficient memory. After all, >>>> when memory allocation fails, the SMMU driver cannot work at a lower specification. >>> >>> I don't entirely agree. Another reason for the failure is because the driver >>> might be asking for a huge (or negative) allocation, in which case it might >>> be instructive to have a look at the actual caller, particularly if the >>> size is derived from hardware or firmware properties. >> >> Agreed - other than deliberately-contrived situations I don't think I've >> ever hit a genuine OOM, but I definitely have debugged attempts to allocate >> -1 of something. If the driver-specific message actually calls out the >> critical information, e.g. "failed to allocate %d stream table entries", it >> gives debugging a head start since the miscalculation is obvious, but a >> static message that only identifies the callsite really only saves a quick >> trip to scripts/faddr2line, and personally I've never found that >> particularly valuable. > > So it sounds like this particular patch is fine, but the one for smmuv2 > should leave the IRQ allocation message alone (by virtue of it printing > something a bit more useful -- the number of irqs). num_irqs = 0; while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, num_irqs))) { num_irqs++; } As the above code, num_irqs is calculated based on the number of dtb or acpi configuration items, it can't be too large. That is, there is almost zero chance that devm_kcalloc() will fail because num_irqs is too large. > > Will > > . > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30B8FC48BDF for ; Wed, 16 Jun 2021 01:49:40 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E028760E09 for ; Wed, 16 Jun 2021 01:49:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E028760E09 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:CC:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=woVlNx22+CnNDKMVvDt9ZRbVltnpyy4HRmctuawqXsc=; b=qJpMbeGIqxO/hrX0de+cvo/1wq RHY5bKDjEXmhIQa9/C3SJPHOV7nAVVUND8GewqTg6zpImLdyZFsuUU2KUJQ8DQN+ObKFxfcCxO2l3 W9o3IIuvqV1kmWLojAYpqXw929RalhO0vW/R6sNglIjAaKm5fCvQlQT62CxYJ9Fv6R61QecnAhTU3 QOTVl6Fa6kCjF69PLEZTduc9tJzZOkBXHp6pZfdrAzWMSRoPgUGAQzJBECmwbddYYe0fTsb9XP6xp Xi0YINQP6yI+T33QnqBpgwGhLPotZEx3sK8kM9kGB6i2ATWf3EI4AOFN3518c/+4lI6p1Z4AIYTQF jxJ3wBqg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltKeU-004Ovf-Iy; Wed, 16 Jun 2021 01:47:34 +0000 Received: from szxga03-in.huawei.com ([45.249.212.189]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltKeQ-004Ouk-DY for linux-arm-kernel@lists.infradead.org; Wed, 16 Jun 2021 01:47:32 +0000 Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4G4Sd53PxFz6y5T; Wed, 16 Jun 2021 09:43:21 +0800 (CST) Received: from dggpemm500006.china.huawei.com (7.185.36.236) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 16 Jun 2021 09:47:20 +0800 Received: from [127.0.0.1] (10.174.179.0) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 16 Jun 2021 09:47:19 +0800 Subject: Re: [PATCH 1/1] iommu/arm-smmu-v3: remove unnecessary oom message To: Will Deacon , Robin Murphy CC: linux-arm-kernel , Joerg Roedel , iommu References: <20210609125438.14369-1-thunder.leizhen@huawei.com> <20210611103220.GB15274@willie-the-truck> <2a0b7f37-156a-775f-ade4-015cade472c6@huawei.com> <20210615113417.GA20598@willie-the-truck> <20210615115507.GD20598@willie-the-truck> From: "Leizhen (ThunderTown)" Message-ID: Date: Wed, 16 Jun 2021 09:47:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20210615115507.GD20598@willie-the-truck> Content-Language: en-US X-Originating-IP: [10.174.179.0] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210615_184730_847052_A69C741C X-CRM114-Status: GOOD ( 23.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021/6/15 19:55, Will Deacon wrote: > On Tue, Jun 15, 2021 at 12:51:38PM +0100, Robin Murphy wrote: >> On 2021-06-15 12:34, Will Deacon wrote: >>> On Tue, Jun 15, 2021 at 07:22:10PM +0800, Leizhen (ThunderTown) wrote: >>>> >>>> >>>> On 2021/6/11 18:32, Will Deacon wrote: >>>>> On Wed, Jun 09, 2021 at 08:54:38PM +0800, Zhen Lei wrote: >>>>>> Fixes scripts/checkpatch.pl warning: >>>>>> WARNING: Possible unnecessary 'out of memory' message >>>>>> >>>>>> Remove it can help us save a bit of memory. >>>>>> >>>>>> Signed-off-by: Zhen Lei >>>>>> --- >>>>>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 8 ++------ >>>>>> 1 file changed, 2 insertions(+), 6 deletions(-) >>>>>> >>>>>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >>>>>> index 2ddc3cd5a7d1..fd7c55b44881 100644 >>>>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >>>>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >>>>>> @@ -2787,10 +2787,8 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu) >>>>>> void *strtab = smmu->strtab_cfg.strtab; >>>>>> cfg->l1_desc = devm_kzalloc(smmu->dev, size, GFP_KERNEL); >>>>>> - if (!cfg->l1_desc) { >>>>>> - dev_err(smmu->dev, "failed to allocate l1 stream table desc\n"); >>>>>> + if (!cfg->l1_desc) >>>>> >>>>> What error do you get if devm_kzalloc() fails? I'd like to make sure it's >>>>> easy to track down _which_ allocation failed in that case -- does it give >>>>> you a line number, for example? >>>> >>>> When devm_kzalloc() fails, the OOM information is printed. No line number information, but the >>>> size(order) and call stack is printed. It doesn't matter which allocation failed, the failure >>>> is caused by insufficient system memory rather than the fault of the SMMU driver. Therefore, >>>> the current printing is not helpful for locating the problem of insufficient memory. After all, >>>> when memory allocation fails, the SMMU driver cannot work at a lower specification. >>> >>> I don't entirely agree. Another reason for the failure is because the driver >>> might be asking for a huge (or negative) allocation, in which case it might >>> be instructive to have a look at the actual caller, particularly if the >>> size is derived from hardware or firmware properties. >> >> Agreed - other than deliberately-contrived situations I don't think I've >> ever hit a genuine OOM, but I definitely have debugged attempts to allocate >> -1 of something. If the driver-specific message actually calls out the >> critical information, e.g. "failed to allocate %d stream table entries", it >> gives debugging a head start since the miscalculation is obvious, but a >> static message that only identifies the callsite really only saves a quick >> trip to scripts/faddr2line, and personally I've never found that >> particularly valuable. > > So it sounds like this particular patch is fine, but the one for smmuv2 > should leave the IRQ allocation message alone (by virtue of it printing > something a bit more useful -- the number of irqs). num_irqs = 0; while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, num_irqs))) { num_irqs++; } As the above code, num_irqs is calculated based on the number of dtb or acpi configuration items, it can't be too large. That is, there is almost zero chance that devm_kcalloc() will fail because num_irqs is too large. > > Will > > . > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel