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: <725cb1ad-01b0-42b5-56f0-c08c29804cb4@amd.com>
Date:   Mon, 2 Jul 2018 14:13:42 +0200
From:   Christian König <christian.koenig@....com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        "David (ChunMing) Zhou" <David1.Zhou@....com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Alex Deucher <alexander.deucher@....com>,
        David Airlie <airlied@...ux.ie>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Doug Ledford <dledford@...hat.com>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Mike Marciniszyn <mike.marciniszyn@...el.com>,
        Dennis Dalessandro <dennis.dalessandro@...el.com>,
        Sudeep Dutt <sudeep.dutt@...el.com>,
        Ashutosh Dixit <ashutosh.dixit@...el.com>,
        Dimitri Sivanich <sivanich@....com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        Jérôme Glisse <jglisse@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>, kvm@...r.kernel.org,
        amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
        intel-gfx@...ts.freedesktop.org, linux-rdma@...r.kernel.org,
        xen-devel@...ts.xenproject.org, linux-mm@...ck.org,
        David Rientjes <rientjes@...gle.com>,
        Felix Kuehling <felix.kuehling@....com>
Subject: Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 02.07.2018 um 13:54 schrieb Michal Hocko:
> On Mon 02-07-18 11:14:58, Christian König wrote:
>> Am 27.06.2018 um 09:44 schrieb Michal Hocko:
>>> This is the v2 of RFC based on the feedback I've received so far. The
>>> code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
>>> because I have no idea how.
>>>
>>> Any further feedback is highly appreciated of course.
>> That sounds like it should work and at least the amdgpu changes now look
>> good to me on first glance.
>>
>> Can you split that up further in the usual way? E.g. adding the blockable
>> flag in one patch and fixing all implementations of the MMU notifier in
>> follow up patches.
> But such a code would be broken, no? Ignoring the blockable state will
> simply lead to lockups until the fixup parts get applied.

Well to still be bisect-able you only need to get the interface change 
in first with fixing the function signature of the implementations.

Then add all the new code to the implementations and last start to 
actually use the new interface.

That is a pattern we use regularly and I think it's good practice to do 
this.

> Is the split up really worth it? I was thinking about that but had hard
> times to end up with something that would be bisectable. Well, except
> for returning -EBUSY until all notifiers are implemented. Which I found
> confusing.

It at least makes reviewing changes much easier, cause as driver 
maintainer I can concentrate on the stuff only related to me.

Additional to that when you cause some unrelated side effect in a driver 
we can much easier pinpoint the actual change later on when the patch is 
smaller.

>
>> This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd
>> changes.
> If you are worried to give r-b only for those then this can be done even
> for larger patches. Just make your Reviewd-by more specific
> R-b: name # For BLA BLA

Yeah, possible alternative but more work for me when I review it :)

Regards,
Christian.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ