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 4F99B41EAC; Thu, 16 Mar 2023 09:13:55 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DD1B540FDF; Thu, 16 Mar 2023 09:13:54 +0100 (CET) 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 1802140EF1 for ; Thu, 16 Mar 2023 09:13:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678954432; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cEdkPaZx0ODdS2WA2P5N3QDFI+26zHe+h7ILpxzQHs4=; b=U75uehXVSJr5dbo1h4KWZirN9ofjExqKC5Mq3N8Ls4g1cejrhKi0fihMQHvBr7fYa4/Xq/ pMI95x0ATPUoiuBu3U9em3RdNFkVCEVrfvRkUULChu9IHTmF4ucXCAqDDaTONhLDVQu6p7 TniHB3GlaPf/7Rtz9gf57aHjUcIPVZg= Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-124-sxXl1ipHM4m11r4QH2ztRg-1; Thu, 16 Mar 2023 04:13:50 -0400 X-MC-Unique: sxXl1ipHM4m11r4QH2ztRg-1 Received: by mail-pg1-f198.google.com with SMTP id bc19-20020a656d93000000b005072b17a298so319523pgb.14 for ; Thu, 16 Mar 2023 01:13:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678954430; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cEdkPaZx0ODdS2WA2P5N3QDFI+26zHe+h7ILpxzQHs4=; b=x6kAqYHnRnRIvtxmygDaVjheSb17n6r6EDiOCLD6RnRy6L+Pzw5jsrnYian5Ppl3aJ /4LJ0yWoXYtQSQgYBmyBjdBiFp4vPE9fIfXNAVNRMYPe14AqbqUHJIN8amS88ASj4UVm D0TsoJbia5AfZ4qheemV/iSiepFjPO6YE4W4vzC1kP6MdIgW/vjh0v8BcWgI3wUbXchg TPyW3IZ0zJFykuAEnBPaVVLjrrDrdkmPPKIZCX4BAOGD39Dbfit5rQi7JkRySXx/8QFT mR7FAMQhMVr9eZ7buPubVpUsGNcSF0L9WcqIj9atsg5dwYjk0wYH1yzLo9JI5trMNhLB oZ1A== X-Gm-Message-State: AO0yUKX40ges3MmbdwUePVI05UmC7qAdzflG8NnMfrPzmjrDZXTNajaZ G/+uobtzMd/kLou37uwk/PSWBov7Jc4Mri64wJ9cE4mXA76CM18x0jaUrO72WNiDyEk/8CABYz0 DAKprGK2BZWODnyNZe6U= X-Received: by 2002:a17:90a:fa8f:b0:233:cc2c:7dae with SMTP id cu15-20020a17090afa8f00b00233cc2c7daemr819631pjb.8.1678954429837; Thu, 16 Mar 2023 01:13:49 -0700 (PDT) X-Google-Smtp-Source: AK7set8ackuLKrLbOZOpdUqL5FpmK+4b2wxzCpQlKmMeHrBgSOCxUl8TCmO3AKVP7K+MRx+7LaWd1bRlaKWC9t5x4Do= X-Received: by 2002:a17:90a:fa8f:b0:233:cc2c:7dae with SMTP id cu15-20020a17090afa8f00b00233cc2c7daemr819623pjb.8.1678954429518; Thu, 16 Mar 2023 01:13:49 -0700 (PDT) MIME-Version: 1.0 References: <20230315114010.444005-1-maxime.coquelin@redhat.com> In-Reply-To: <20230315114010.444005-1-maxime.coquelin@redhat.com> From: David Marchand Date: Thu, 16 Mar 2023 09:13:38 +0100 Message-ID: Subject: Re: [PATCH v2] vhost: fix madvise IOTLB entries pages overlap check To: Maxime Coquelin Cc: dev@dpdk.org, mkp@redhat.com, chenbo.xia@intel.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Hello Maxime, On Wed, Mar 15, 2023 at 12:40=E2=80=AFPM Maxime Coquelin wrote: > > At removal time, when testing whether the IOTLB entry has > shared pages with the previous and next entries in the > cache, it checks whether the start address of the entry to > be removed is on the same page as the start address of the > next entry in the cache. > > This is not correct, as an entry could cover several page > so the end address of the entry to be remove should be > used. This patch address this issue. I'm trying to understand the logic, so I needed to write this down :-). Let's imagine the cache contained 3 nodes, "prev", "node" and "next". All those nodes (in this example) do not start or end on a page boundary. Prior to touching those entries, all pages of the nodes are marked as DODUM= P. "prev" spans over two pages, "a" and "b". "node" spans over three pages, "b", "c" and "d". "next" spans over two pages, "d" and "e". IOW, "prev" and "node" are sharing the "b" page. IOW, "node" and "next" are sharing the "d" page. Something like (better displayed with fixed-width chars): prev node next <----> <----------> <----> | a | b | c | d | e | Previous to this fix, since we were testing the first page of each node, it resulted in page "b" being marked as DONTDUMP, while it was still in use for "prev". And for the same reason, page "d" would be marked as DONTDUMP too. After this fix, all pages are left with DODUMP. Is my understanding correct? If so, there is still one (minor?) issue to look into: we leave the "c" page as DODUMP while it won't contain useful information. > > Fixes: dea092d0addb ("vhost: fix madvise arguments alignment") > > Signed-off-by: Maxime Coquelin --=20 David Marchand