[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 03/13] libxenguest: deal with log-dirty op stats overflow


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 5 Jul 2021 16:41:38 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tr66IaaFKvdb6843PQjk0JRCDkL/c0JzHSQRIzV86/g=; b=GxZHvKJlLjMWLxQrVu0nqPqs59H7Rj0hjPk/eaEXKmWqrymaRsaMXKcTPXh5R+HY0wy82i17i7yuzmBCNPj2ZWWESUetPOXIUQ71ivvgKILNxcHQLN/0T+ed6ruGw97rX3f5PAtOPpkQIias8W3lQhZZl23HMwSt81b1W1q8ELSJiV2IopB7Tz0NcKtJOFSvDk+hhM+lk/2AMC5h0OB43bTqFh8uVjRpmVyIz0K09KDCE2594+lj6DurF5h+QKCr9TCiI2kO8fOgL0PA77/4G6++JrmkgUNfIskUODA6G5yVb5cY4QQo/fyKlny41jDB5OOh2kMYTVZGKJOa1x9O8Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VBFlchwK0WOftdz0YE4mNUAKcQgitlgF30s/sEOoQvDXRNGfViffGCC9VetwWAYwkQhNSEJviRCmXUbP6Srytqlq0JQXHe8vkKl6p1Yn+qCQtpWrhJ69ehK2VYjx84XUTo58inRVL7FFeZivo7SeeoZy2JxLcMwWO7w0exihE7+Vabd835ajqHXfBMm67tm5BnJD3BluMjJ8ML/xIzNbDu7h1Frpm+FEHJItHyXwZtBFezCXhBSw/LDmhpWqKYJ/1NH06Nomfe9Utd0jnxfK4r7DsA72eda39zSrz1t9omKp8sVqAYEAEdCmV68Ix7eU4bRJviB8WHHdvwMuSHnRqg==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • Delivery-date: Mon, 05 Jul 2021 15:41:59 +0000
  • Ironport-hdrordr: A9a23:6iosoqMDQ4mwtMBcTwj255DYdb4zR+YMi2TDj3oBOSC9Evbow/ xGWc5roCMdiF4qKQkdcKO7SYC9qBLnhLZICOYqTMuftWXdyQ2VxcRZnPrfKl7bam7DH4xmpN hdWox/DNHbBUJmtN396gWjCdosqeP3qZxA7N22pxwBIW8KGsUQiDuRSDzrbHGeLDM2QKbRf6 Dsnfav0gDQBEj/Gf7LfEXtMdKz3uEjoKiWJSIuNloK+QOKhTOt5KXaFQKE0holUz1Jyao/6m Te1yj0/L+qvf2D0RnX23XI45k+orvc4+oGKN2Hj8AULjn2qgKwf4RnRpWJoTAyp4iUmTMXue iJjwYrOsxy73/LXmWtuhvrxizpzToo4W+K8y77vVLT5eDpTjczC85MnrtDdArIzkI8sNZ3wM twrgGkXtdsfEn9dOuU3amHa/nG/XDfnZJ3+9R9s1VvFa8lLJNBp40W+01YVL0aGjjh1YwhGO 5ySOnB+fd/azqhHiPkl1gq5ObpcmU4Hx+ATERHkNeSySJqkHdwyFZd7NADn00H6Ik2R/B/lr T525xT5eNzp/ItHPxA7aY6MJSK41X2ME7x2bepUAXa/KJuAQOBl3e42sR2lbSXkFph9up0pH 2LaiIqiYcIQTOZNSVVtKc7tCwlCF/NLwgF6vsuv6SR6YeMH4YCx0W4OR8Te/XJmYRVPiUtM8 zDdK6/hJTYXD3T8VIj5XyoZ3AVEwhCbOQF/tIgH16eqMPCLYPn8uTdbfbIPbLoVTIpQHn2DH cPVCX6YJwo1DHqZlboxBzKH3/9cE32+px9VKDc4ugI0YAIcolBqBIch1i17tyCbTdCrqs1dk 1jJ66PqNL7mYCSxxeB04xZAGsWMq8O2sSWb5pjn35CD6rbS8d2h+mi
  • Ironport-sdr: k8W6xbtHVd1YajN2LsSwuXP1Ry/QnXS4boS43LMelsSolWTRCF0hiKTm5c9FnQkJIySMNLf1P3 qiVlZc+eq7dwERrx25QYbbsr6Y+s4b7eQ0xCaOofOhIbIOROxMURe7OZgXWBk3vMkDvkzW6y6n umMFKJLMzR/d07iwrqwGJ0D0zroQNMsiPvXFDpnt2rd9Jw6NUtydzfQNCxbbaZtOsKxomOH5ca e65UxkbZM4MIoQotklHyBMsdP2XurpIT+xRZaCxPNi6YvZ74SjmgoTAB9GSQVWmLxewETZd6DQ s48=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 05/07/2021 16:13, Jan Beulich wrote:
> In send_memory_live() the precise value the dirty_count struct field
> gets initialized to doesn't matter much (apart from the triggering of
> the log message in send_dirty_pages(), see below), but it is important
> that it not be zero on the first iteration (or else send_dirty_pages()
> won't get called at all). Saturate the initializer value at the maximum
> value the field can hold.

I've already explained why this is broken...

> While there also initialize struct precopy_stats' respective field to a
> more sane value: We don't really know how many dirty pages there are at
> that point.
>
> In suspend_and_send_dirty() and verify_frames() the local variables
> don't need initializing at all, as they're only an output from the
> hypercall which gets invoked first thing.
>
> In send_checkpoint_dirty_pfn_list() the local variable can be dropped
> altogether: It's optional to xc_logdirty_control() and not used anywhere
> else.

... and why this is broken particularly in the context of a later
change, and ...

>
> Note that in case the clipping actually takes effect, the "Bitmap
> contained more entries than expected..." log message will trigger. This
> being just an informational message, I don't think this is overly
> concerning.

... why this isn't ok.

Why do I bother wasting my time reviewing patches in the first place.

~Andrew




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.