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]
Date:   Thu, 15 Mar 2018 08:57:05 +0200
From:   Gal Hammer <ghammer@...hat.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Or Idgar <idgar@...tualoco.com>, linux-kernel@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>, Or Idgar <oidgar@...hat.com>,
        Or Idgar <oridgar@...il.com>
Subject: Re: [PATCH v5] drivers/misc: vm_gen_counter: initial driver implementation

On Wed, Mar 14, 2018 at 9:25 PM, Michael S. Tsirkin <mst@...hat.com> wrote:
> On Wed, Mar 14, 2018 at 07:25:36PM +0100, Greg KH wrote:
>> On Tue, Mar 13, 2018 at 07:40:51PM +0200, Michael S. Tsirkin wrote:
>> > I think it's a good idea to use sysfs for this. However,
>> > there are a couple of missing interfaces here:
>> >
>> > 1. Userspace needs a way to know when this value changes.
>> >    I see no change notifications here and that does not seem right.
>>
>> How can these change?
>
> It's a hardware register. It changes when hardware feels like it :)
> In particular, it changes whenever VM is migrated or snapshotted.

This value doesn't change when a VM is migrated. It is unlikely that
this value will be changed so frequently that a direct access to the
memory is required. Even in QEMU, the current implementation was
merged without an option to change the generation id on-the-fly. One
must run a new instance in order to set a new value, which means that
no application will be running during that time.

>> > 2. Userspace needs to be able to read these without
>> >    system calls.
>>
>> Ick, what?  Why not?
>>
>> > Pls add mmap support to the raw format.
>>
>> For a single integer?  Why do you need mmap for this?  What is so
>> "performant" that needs to touch a sysfs file?
>> >    (Phys address is not guaranteed to be page-aligned so you will
>> >     probably want an offset attribute for that as well).
>>
>> Ick ick ick, that's why it's good to just stick with a sysfs file.

I agree with Greg here. The user is able to read the value, and then
wait for a notification if she cares about changes.

>> Have you tested just how long this takes to see if the open/read/close
>> is really the bottleneck, or if the io on reading the value is the
>> bottleneck?
>>
>> thanks,
>>
>> greg k-h
>
> Well an application needs to check this value basically after
> every database transaction. So I'm pretty sure it's a performance
> sensitive path. But yes, I didn't profile any apps since they
> are yet to be written to use this interface.
> I'm fine deferring point 2 for now.
>
> --
> MST

Thanks,

    Gal.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ