linux-ext4 - Re: [PATCH v2 1/29] fs: Add FGP

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, 6 Apr 2023 16:08:03 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Theodore Ts'o <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org, Christoph Hellwig <hch@....de>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 1/29] fs: Add FGP_WRITEBEGIN

On Thu, Apr 06, 2023 at 04:04:07PM +0100, Matthew Wilcox wrote:
> On Thu, Apr 06, 2023 at 10:56:19AM -0400, Theodore Ts'o wrote:
> > On Fri, Mar 24, 2023 at 06:01:01PM +0000, Matthew Wilcox wrote:
> > > This particular combination of flags is used by most filesystems
> > > in their ->write_begin method, although it does find use in a
> > > few other places.  Before folios, it warranted its own function
> > > (grab_cache_page_write_begin()), but I think that just having specialised
> > > flags is enough.  It certainly helps the few places that have been
> > > converted from grab_cache_page_write_begin() to __filemap_get_folio().
> > > 
> > > Signed-off-by: Matthew Wilcox (Oracle) <willy@...radead.org>
> > 
> > Hey Willy,
> > 
> > Which commit/branch did you base this patch series on?  This commit
> 
> next-20230321.  I haven't noticed any conflicts while rebasing to
> next-20230404.
> 
> > conflict with Vishal Moola's e8dfc854eef2 ("ext4: convert
> > mext_page_double_lock() to mext_folio_double_lock()") which landed in
> > v6.3-rc1.
> 
> I'm not sure why you're seeing that conflict.  The context lines look
> like it's applied after mext_folio_double_lock, eg:
> 
> @@ -126,7 +126,6 @@ mext_folio_double_lock(struct inode *inode1, struct inode *inode2,

Ah, I see the conflicting patch in -next.  It's hch's

    mm: return an ERR_PTR from __filemap_get_folio

@@ -141,18 +141,18 @@ mext_folio_double_lock(struct inode *inode1, struct inode *inode2,
        flags = memalloc_nofs_save();
        folio[0] = __filemap_get_folio(mapping[0], index1, fgp_flags,
                        mapping_gfp_mask(mapping[0]));
-       if (!folio[0]) {
+       if (IS_ERR(folio[0])) {
                memalloc_nofs_restore(flags);
-               return -ENOMEM;
+               return PTR_ERR(folio[0]);

This is a syntactic, not semantic conflict.  I can fix that up, but of
course it will be a conflict for Linus to resolve.