lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220719201803.GL4609@nvidia.com>
Date:   Tue, 19 Jul 2022 17:18:03 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Yishai Hadas <yishaih@...dia.com>, saeedm@...dia.com,
        kvm@...r.kernel.org, netdev@...r.kernel.org, kuba@...nel.org,
        kevin.tian@...el.com, joao.m.martins@...cle.com, leonro@...dia.com,
        maorg@...dia.com, cohuck@...hat.com,
        Kirti Wankhede <kwankhede@...dia.com>
Subject: Re: [PATCH V2 vfio 03/11] vfio: Introduce DMA logging uAPIs

On Tue, Jul 19, 2022 at 01:57:14PM -0600, Alex Williamson wrote:

> If userspace needs to consider the bitmap undefined for any errno,
> that's a pretty serious usage restriction that may negate the
> practical utility of atomically OR'ing in dirty bits.  

If any report fails it means qemu has lost the ability to dirty track,
so it doesn't really matter if one chunk has gotten lost - we can't
move forward with incomplete dirty data.

Error recovery is to consider all memory dirty and try to restart the
dirty tracking, or to abort/restart the whole migration.

Worrying about the integrity of a single bitmap chunk doesn't seem
worthwhile given that outcome.

Yes, there are cases where things are more deterministic, but it is
not useful information that userspace can do anything with. It can't
just call report again and expect it will work the 2nd time, for
instance.

We do not expect failures here, lets not overdesign things.

> reserve -EIO for such a case.  The driver itself can also gratuitously
> mark ranges dirty itself if it loses sync with the device, and can
> probably do so at a much more accurate granularity than userspace.

A driver that implements such a handling shouldn't return an error
code in the first place.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ