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: <CAHc6FU4sZj4DFbQddXk2Uo5Nh4EOFM6rdAnwD3kmnN2RjvL9OQ@mail.gmail.com>
Date:   Tue, 3 Jul 2018 23:52:04 +0200
From:   Andreas Gruenbacher <agruenba@...hat.com>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     Souptick Joarder <jrdr.linux@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        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>, willy@...radead.org,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH] fs: iomap: Change return type to vm_fault_t

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 meaning to reply to Souptick
Joarder's gfs2 change which I've added to the gfs2 for-next branch.
Not the iomap change. Sorry for the confusion.

> [1] https://spinics.net/lists/linux-fsdevel/msg126032.html
>
> Now granted I didn't have a problem with the code (and applied the xfs
> version to 4.18 after monitoring to satisfy myself that nothing
> particularly weird happened during 4.17) but seeing as most of the iomap
> changes have gone through hch's review and landed via the xfs tree...
>
>> > ---
>> >  fs/iomap.c            | 2 +-
>> >  include/linux/iomap.h | 4 +++-
>> >  2 files changed, 4 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/fs/iomap.c b/fs/iomap.c
>> > index afd1635..58477ee 100644
>> > --- a/fs/iomap.c
>> > +++ b/fs/iomap.c
>> > @@ -443,7 +443,7 @@ static int iomap_dax_zero(loff_t pos, unsigned offset, unsigned bytes,
>> >         return length;
>> >  }
>> >
>> > -int iomap_page_mkwrite(struct vm_fault *vmf, const struct iomap_ops *ops)
>> > +vm_fault_t iomap_page_mkwrite(struct vm_fault *vmf, const struct iomap_ops *ops)
>> >  {
>> >         struct page *page = vmf->page;
>> >         struct inode *inode = file_inode(vmf->vma->vm_file);
>> > diff --git a/include/linux/iomap.h b/include/linux/iomap.h
>> > index 19a07de..666b717 100644
>> > --- a/include/linux/iomap.h
>> > +++ b/include/linux/iomap.h
>> > @@ -3,6 +3,7 @@
>> >  #define LINUX_IOMAP_H 1
>> >
>> >  #include <linux/types.h>
>> > +#include <linux/mm_types.h>
>> >
>> >  struct fiemap_extent_info;
>> >  struct inode;
>> > @@ -88,7 +89,8 @@ int iomap_zero_range(struct inode *inode, loff_t pos, loff_t len,
>> >                 bool *did_zero, const struct iomap_ops *ops);
>> >  int iomap_truncate_page(struct inode *inode, loff_t pos, bool *did_zero,
>> >                 const struct iomap_ops *ops);
>> > -int iomap_page_mkwrite(struct vm_fault *vmf, const struct iomap_ops *ops);
>> > +vm_fault_t iomap_page_mkwrite(struct vm_fault *vmf,
>> > +                       const struct iomap_ops *ops);
>> >  int iomap_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
>> >                 loff_t start, loff_t len, const struct iomap_ops *ops);
>> >  loff_t iomap_seek_hole(struct inode *inode, loff_t offset,
>> > --
>> > 1.9.1
>> >
>>
>> Added to for-next, thanks.
>
> ...this part caused me to sit up and say "Hey what?" :)
>
> Which tree is this? gfs2?
>
> --D
>
>>
>> Andreas