From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E4FF6A0C45; Thu, 28 Oct 2021 09:53:13 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CE08C4067B; Thu, 28 Oct 2021 09:53:13 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id AD82D4003F for ; Thu, 28 Oct 2021 09:53:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635407592; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MojvogafsZ5X/pgvyaMsgaTSw6poDRY+ZyMpJKaLfAI=; b=g+zDTJDTnvFeDHpuL313hY6l3RCmBSVOdniNLditin/hEt23ydft+qH8pxccLIMyaVKZVD Zg6c11A+QPcpItQtdU4e537kjpR3/8Zf0Iv1+rtFhSuwYnTXuoMmbHiAj9q4wVJ0v6lEZl zWdaOYXfDiUQLLL4p8uHc55TEhHWLNo= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-96-pP-74T0FPm-G3JT5-MdptQ-1; Thu, 28 Oct 2021 03:53:10 -0400 X-MC-Unique: pP-74T0FPm-G3JT5-MdptQ-1 Received: by mail-lf1-f72.google.com with SMTP id k15-20020a0565123d8f00b003ffb31e2ea9so2498876lfv.17 for ; Thu, 28 Oct 2021 00:53:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MojvogafsZ5X/pgvyaMsgaTSw6poDRY+ZyMpJKaLfAI=; b=cmk05SXhISiS/5/V+C7plTuQnX0HtYS0eDaTpB6hA+S2Xyt6CpsfnLx1XOW+y4M+zd 2+/++KibMXJ1wMRp14YVqgMaSUoGX9UhYqNm/A7B7POq/kYnt59hZfDLFYncB5QzIezI 5yh9q0VJW9jfmZ7Jd96liomlrWZwQ9HCbSxjF9bCaZXgzXOfXTeKnGmARwj9UHVkX2CW V7bQZp8HjKFYJGdJF9TD3Pqpv0zrTIBS1XGEjPXIGopPx0Y1w+jekl689OGLPk/WdK+D 04IKRL/23nqKkGlQmnk5wyu7+3jPdsm+DeUkaevHeK4da0bSjfPuNWjDZtOgx+alA+gJ H1tg== X-Gm-Message-State: AOAM531ilHWwZS0N+ykVzsa2b9GJacDcCubPRvSzMyB+FPIdnRWS92q0 e1/iee4NdNUcTvSy+IIKVveKflH4HQarO8sOe3h6sATGbNJKQDwAfXmWztRVh+7Yt11k94C5kmh Z/bO8D5Euyonb9qZ9u/s= X-Received: by 2002:ac2:5d68:: with SMTP id h8mr2732599lft.217.1635407589318; Thu, 28 Oct 2021 00:53:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyV+qAPD6a3Y7xoQ5mKVtAIIwXHgSORwONb5SbOLsfnhF0vmRjYfQiwB7nO+EPFI60SdZn97d64MFxse8UW/fs= X-Received: by 2002:ac2:5d68:: with SMTP id h8mr2732584lft.217.1635407589120; Thu, 28 Oct 2021 00:53:09 -0700 (PDT) MIME-Version: 1.0 References: <8079312ba39435a0ac92e084cc1a3fe291008a47.1635254797.git.anatoly.burakov@intel.com> In-Reply-To: From: David Marchand Date: Thu, 28 Oct 2021 09:52:57 +0200 Message-ID: To: "Burakov, Anatoly" , "Ding, Xuan" Cc: dev , Maxime Coquelin Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v1 1/1] vfio: fix partial unmap check X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Oct 28, 2021 at 8:06 AM Ding, Xuan wrote: > >> Partial unmap support was introduced in commit c13ca4e81cac, and with it > >> was added a check that dereferenced the IOMMU type to determine > >whether > >> partial ummapping is supported for currently configured IOMMU type. In > >> certain circumstances (such as when VFIO is supported, but no devices > >> were bound to the VFIO driver), the IOMMU type pointer can be NULL. > >> > >> However, dereferencing of IOMMU type was guarded by access to the user > >> maps list - that is, we were always checking the user map list first, > >> and then, if we found a memory region that encloses the one we're trying > >> to unmap, we would have performed the IOMMU type check. > >> > >> This ensured that the IOMMU type check will not cause any NULL pointer > >> dereferences, because in order for an IOMMU type check to have been > >> performed, there necessarily must have been at least one memory region > >> that was previously mapped successfully, and that implies having a > >> defined IOMMU type. > >> > >> When 56259f7fc010 was introduced, the IOMMU type check was moved to > >> before we were traversing the user mem maps list, thereby introducing a > >> potential NULL dereference, because the IOMMU type access was no longer > >> guarded by the user mem maps list traversal. > >> > >> Fix the issue by moving the IOMMU type check to after the user mem maps > >> traversal, thereby ensuring that by the time the check happens, the > >> IOMMU type is always valid. > >> > >> Fixes: 56259f7fc010 ("vfio: allow partially unmapping adjacent memory") > >> Cc: xuan.ding@intel.com > >> > >> Signed-off-by: Anatoly Burakov > >Reviewed-by: David Marchand > Tested-by: Xuan Ding Applied, thanks. -- David Marchand