MIME-Version: 1.0
References: <20230220135225.91b0f28344c01d5306c31230@linux-foundation.org>
In-Reply-To: <20230220135225.91b0f28344c01d5306c31230@linux-foundation.org>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 23 Feb 2023 17:33:37 -0800
Message-ID: <CAHk-=whAAOVBrzwb2uMjCmdRrtudGesYj0tuqdUgi8X_gbw1jw@mail.gmail.com>
Subject: Re: [GIT PULL] MM updates for 6.3-rc1
To:     Andrew Morton <akpm@linux-foundation.org>, Jan Kara <jack@suse.cz>,
        Vishal Moola <vishal.moola@gmail.com>,
        Paulo Alcantara <pc@cjr.nz>,
        Matthew Wilcox <willy@infradead.org>,
        David Howells <dhowells@redhat.com>,
        Steve French <stfrench@microsoft.com>,
        Huang Ying <ying.huang@intel.com>,
        Baolin Wang <baolin.wang@linux.alibaba.com>,
        Xin Hao <xhao@linux.alibaba.com>
Cc:     linux-mm@kvack.org, mm-commits@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Feb 20, 2023 at 1:52 PM Andrew Morton <akpm@linux-foundation.org> w=
rote:
>
> Linus, please merge this cycle's MM updates.

Ok, finally got around to this one, and I am not thrilled about it.

A few notes:

 - my fs/udf/inode.c is "minimal". Ugly, ugly, I think
udf_adinicb_writepage() should just be made to actually deal with
folios inherently, but I did *NOT* do that, and just did

        struct page *page =3D &folio->page;

   at the top, and left it at that. I'm not proud of it, but I hope
Jan might want to do this properly.

   That conflict wasn't mentioned, and now I wonder if the UDF changes
were in -next at all?

 - the fs/cifs/file.c conflict was a nightmare.

   Yes, I saw David Howells resolution suggestion. I think that one
was buggy. It would wait for a page under writeback, and then go on to
the *next* one without writing it back. I don't thin kthat was right.

   That said, I'm not at all convinced my version is right either. I
can't test it, and that means I probably messed up. It looked sane to
me when I did it, and it builds cleanly, but I honestly doubt myself.

   I think that code should probably use xas_for_each_marked(), but
instead I kept the old model, added a loop like DavidH did, and then
munged the end result until I thought it was palatable.

   NOTE! Don't even try to look at the conflict diff. It makes no
sense at all. But somebody (I'd hope all of DavidH, SteveF and Willy)
should really take a look at my end result.

 - gcc 12.2.1 quite reasonable complains about some of the new MM code:

    mm/migrate.c: In function =E2=80=98__migrate_folio_extract=E2=80=99:
    mm/migrate.c:1050:20: note: randstruct: casting between randomized
structure pointer types (ssa): =E2=80=98struct anon_vma=E2=80=99 and =E2=80=
=98struct
address_space=E2=80=99

     1050 |         *anon_vmap =3D (void *)dst->mapping;
          |         ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

   and while this doesn't cause a build failure ("note" is different
from "warning"), I do think something needs to be done. Gcc is right.
This code seems to *work* simply because it's intentionally
mis-casting pointers, but I think it needs to be seriously looked at
and something done to make gcc happy (and a *LARGE* comment about it).

That last note is not some merge result, it's purely about the new MM code.

Anyway, the merge is done and pushed out, I just am not very confident
about the end result at all. That cifs thing really needs somebody
competent looking at it.

I think I went through three different iterations of my resolution
before I was happy with my approach, and "happy" may end up being more
about having exhausted my will to live, than about the end result
actually being any good.

I saw some noise about ext4 being a nightmare too, but I haven't
gotten that pull request yet.

I'll tackle the non-MM pull next, but I'm taking a break first.
Alcohol may have to be involved.

               Linus