linux-kernel - Re: [PATCH] fs: iomap: Change return type to vm_fault

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: <CAFqt6zZTqLP2TPE-ANn7HTkakU=zs3hLJ1DC3a2Y=ZR+ASYfuQ@mail.gmail.com>
Date:   Fri, 20 Jul 2018 12:25:26 +0530
From:   Souptick Joarder <jrdr.linux@...il.com>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Christoph Hellwig <hch@...radead.org>,
        Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
        Dave Chinner <dchinner@...hat.com>,
        "Theodore Ts'o" <tytso@....edu>,
        Bob Peterson <rpeterso@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andreas Gruenbacher <agruenba@...hat.com>
Subject: Re: [PATCH] fs: iomap: Change return type to vm_fault_t

On Fri, Jul 20, 2018 at 11:39 AM, Darrick J. Wong
<darrick.wong@...cle.com> wrote:
> On Fri, Jul 20, 2018 at 10:31:30AM +0530, Souptick Joarder wrote:
>> On Wed, Jul 4, 2018 at 3:22 AM, Andreas Gruenbacher <agruenba@...hat.com> wrote:
>> > On 3 July 2018 at 23:39, Darrick J. Wong <darrick.wong@...cle.com> wrote:
>> >> On Mon, Jul 02, 2018 at 07:52:41PM +0200, Andreas Gruenbacher wrote:
>> >>> On 2 July 2018 at 17:43, Souptick Joarder <jrdr.linux@...il.com> wrote:
>> >>> > Return type has been changed to vm_fault_t type for
>> >>> > iomap_page_mkwrite().
>> >>> >
>> >>> > see commit 1c8f422059ae ("mm: change return type to
>> >>> > vm_fault_t") for reference.
>> >>> >
>> >>> > Signed-off-by: Souptick Joarder <jrdr.linux@...il.com>
>> >>> > Reviewed-by: Matthew Wilcox <mawilcox@...rosoft.com>
>> >>
>> >> I don't recall Christoph [now cc'd] rescinding his NAK of the previous
>> >> version of this patch[1].  Has he changed his mind since May?
>> >                                      /|\
>> > Oops, a reply gone wrong -- I was me  |   to reply to Souptick
>> > Joarder's gfs2 change which I've add  |   the gfs2 for-next branch.
>> > Not the iomap change. Sorry for the   |  sion.
>> >                                       |
>> >> [1] https://spinics.net/lists/linux  |  vel/msg126032.html
>> >>                                      |
>> >> Now granted I didn't have a problem  |   the code (and applied the xfs
>> >> version to 4.18 after monitoring to  |  sfy myself that nothing
>> >> particularly weird happened during   |   but seeing as most of the iomap
>> >> changes have gone through hch's rev  |  nd landed via the xfs tree...
>                                           |
> --D                                       |
>                                           |
> I wasn't planning on it, due to aforementioned NAK still being in place
> to the best of my knowledge, at least for the iomap patch.
>
>> Darrick, is this patch going to 4.19 through xfs tree ?

Well,  the original patch was NAK by Christoph because he wanted
to see the complete vm_fault_t migration picture in a patch series
where Matthew mentioned to send one patch per driver through
different maintainers tree to upstream the changes. This discussion
went on into two separate mail threads.

At this point we are almost done with vm_fault_t migration in all drivers/fs
except 3 patches and all the changes will be available in 4.19-rc1. We followed
one patch per driver mechanism and I believe we not are going to adopt other
mechanism (patch series) to upstream these vm_fault_t patches.

This particular patch is struggling for more than 3 months now.

Christoph, would you still like to maintain NAK on this patch ? :-)