Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2078212pxk; Sat, 3 Oct 2020 07:29:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNV/Wxo8pqY2XqBhIUF4MkUz/i+aYjl9VIqfX2PHt+qCv/YGo1oXx/1PwJ+8yQ9KCsKrmz X-Received: by 2002:a17:906:79cf:: with SMTP id m15mr6981146ejo.11.1601735366049; Sat, 03 Oct 2020 07:29:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601735366; cv=none; d=google.com; s=arc-20160816; b=Aj2hoMLLeAU5+TlpUi1jJsXcamKClYqyOiSfTO3nAGhvEIPBY5vN2tPY55uP3S9bkj awhDxH0wLsFGMKXwx1HKA6aYbwkSAf3uO2RHyLQqJ7Y/DfInwoEHIdC7DXT+DsQwrWFQ ChBzOZONmQfZftEH6InsrWoArO2kyydf6/4hC+ugWpku8c+9sTJc9Ahha50CKnqmxb0h 8EMoYFQ/ZoUFlppTeiBYDL7UTN79QjWhkALDpMaPbjp72YrQWKUgiYpIafO/5Vyw3R1K yWFtNLbGtkXZkLwcoEXc5qE00njTo8B6DBY/hgZRp3DvQvxSmK3tJzkLEATLhaPYub06 fIGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject:dkim-signature; bh=WcsBuP3zP0tyQaN/LT3trjYTTJjbx6YMciPdXNhaCSc=; b=KLdCO6GSA1/Qr8fj3UsXbnCP2k1vMpCQMxDPUW26B47hwkxeohlYR7FD6uA3npL0/S PGncEgbSCEApph7XBBfJdobMi8u2EUijSj+9vrASMIVt1zSLy4gdelAI1BYrtjuy8B3N ylIC1usQI6Ft2d1/koroty3z02LmeQ9ArPXNr8A6v+SnplFP1zfCTM3IB3muEQO+evcI XPIUm5Qt4GjQV1XUfqititXT1mnXxoOoyedl61wy38wQcjViyzPDkSJic8fGXjH3wD8u WUbtK/y5tgF48A/yKe89FklRI70Ck2/PxOBpIwovzyD41kXJnNy/WghYo9c+1h1LtFgj q/1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nKVgE5e4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f17si3314408edq.587.2020.10.03.07.29.02; Sat, 03 Oct 2020 07:29:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nKVgE5e4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725822AbgJCO2A (ORCPT + 99 others); Sat, 3 Oct 2020 10:28:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725791AbgJCO2A (ORCPT ); Sat, 3 Oct 2020 10:28:00 -0400 Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9026CC0613D0; Sat, 3 Oct 2020 07:27:59 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id b12so5464395lfp.9; Sat, 03 Oct 2020 07:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WcsBuP3zP0tyQaN/LT3trjYTTJjbx6YMciPdXNhaCSc=; b=nKVgE5e4W8YLfy5meKUdYu8j+1C+p3kRksSQLxOvu8bVkiWnH9Il35e69GQp7tia9o Xg8d5NR8T3ymDHMQzK43jBXe+T+tOBtNKVo7Jp+dgR0804GaXwEBntkEhcxC0BHV50dl g/H7yiPT8KWadrr+2KvR+MJQLuTXdbi/7LD7nIa4FVxxY6pQwln0sECcnQPwT9DMtlJh 3oZJ2mMY2y3yN5xjBGxxUXXJrc2STKAYNSOSDOyWFeh7KJDVNTHwC1xQICyAHY/iuK+P cVg4EYC9ZASmiGfde4HUYunWpmkIUazxQjRqf9ZciYCBbCnmvT+3JELvTNqgKSQpyN89 P3gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WcsBuP3zP0tyQaN/LT3trjYTTJjbx6YMciPdXNhaCSc=; b=U9R5wwpDIVEHKbThfEhwoFL5tV+nbweFLjhOQrcPEmIOyy+W5/HcSGYPhSFPMG1l2N JfhPFzQVHIjSNov72c1jSUQBL/oP1H16cxDJepJMNWAvnYlJO2q0sC8yZlTu5Y43FDVT zLbLM3EgmhVag/dbc+MoRCUcsZdhvq3MppLUtzVGa6nZd3KSZaF9SP+u+hB+cYM1Rgcu 9SD4n4tT8F2KghCGHBLZa7xwdsHf6tQQsM2oWRKimm7G9tDAELEi10rmqtBvBoXUs4bS LqUtwIOlfircud2CDAGozjv+6Wf6Ra7rWHyPlWnQuKWB2b+C5fOqJ01/1gGWlU0Hiqb0 yvag== X-Gm-Message-State: AOAM530V5uMPjsqETZfctada8ZTh/jAQxeYfOgO8BjY3SDFAknjIWFaO D5pnvgn+xf50k4RCKWkJNP0= X-Received: by 2002:ac2:443a:: with SMTP id w26mr674369lfl.435.1601735277910; Sat, 03 Oct 2020 07:27:57 -0700 (PDT) Received: from [192.168.2.145] (109-252-91-252.nat.spd-mgts.ru. [109.252.91.252]) by smtp.googlemail.com with ESMTPSA id p21sm1586032lfo.194.2020.10.03.07.27.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Oct 2020 07:27:57 -0700 (PDT) Subject: Re: [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get From: Dmitry Osipenko To: Nicolin Chen , thierry.reding@gmail.com, joro@8bytes.org Cc: vdumpa@nvidia.com, jonathanh@nvidia.com, linux-tegra@vger.kernel.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, hch@infradead.org References: <20200929061325.10197-1-nicoleotsuka@gmail.com> <20200929061325.10197-2-nicoleotsuka@gmail.com> <35d789ae-7deb-7f8c-0556-98fe73f5999f@gmail.com> Message-ID: <0cc12c08-e2f2-b915-e7b4-8e2e94ea2ac4@gmail.com> Date: Sat, 3 Oct 2020 17:27:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <35d789ae-7deb-7f8c-0556-98fe73f5999f@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 29.09.2020 20:41, Dmitry Osipenko пишет: > 29.09.2020 09:13, Nicolin Chen пишет: >> The tegra_smmu_group_get was added to group devices in different >> SWGROUPs and it'd return a NULL group pointer upon a mismatch at >> tegra_smmu_find_group(), so for most of clients/devices, it very >> likely would mismatch and need a fallback generic_device_group(). >> >> But now tegra_smmu_group_get handles devices in same SWGROUP too, >> which means that it would allocate a group for every new SWGROUP >> or would directly return an existing one upon matching a SWGROUP, >> i.e. any device will go through this function. >> >> So possibility of having a NULL group pointer in device_group() >> is upon failure of either devm_kzalloc() or iommu_group_alloc(). >> In either case, calling generic_device_group() no longer makes a >> sense. Especially for devm_kzalloc() failing case, it'd cause a >> problem if it fails at devm_kzalloc() yet succeeds at a fallback >> generic_device_group(), because it does not create a group->list >> for other devices to match. >> >> This patch simply unwraps the function to clean it up. >> >> Signed-off-by: Nicolin Chen >> --- > > Reviewed-by: Dmitry Osipenko > Tested-by: Dmitry Osipenko