Re: linux-next: build failure after merge of the mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 23, 2023 at 8:40 PM Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>
> I think Linus may have missed the last 2 changes in this merge
> resolution ...

Well, not exactly missed, in that I didn't actually even look at it,
because that one wasn't one I worried about (unlike the cifs one that
I'm very leery of).

And I actually really dislike your particular resolution and wouldn't
prefer it done that way anyway. It mixes folios and pages in ugly
ways.

Either do it all with the page pointer (like I did), or convert it
*all* to be folios, but don't do that odd "use a mixture of both
intertwined".

Of course, I do see _why_ you are mixing 'page' and 'folio' - there's
no memcpy_to_folio() helper (although once it eventually exists it
might be called "memcpy_to_file_folio()" to match the naming of the
"from" version).

But that's exactly why I stopped where I stopped - I think it's
pointless doing the other conversions when you can't easily do that
memcpy_to_page() one.

So I think the UDF folio conversion needs a bit more infrastructure to
really work well.

(There's also the whole kmap issue - we don't kmap whole folios, only
individual pages, so a "real" folio conversion would have to have a
loop).

End result: I explicitly left it in its minimal form, because I think
anything else is a "future endeavor". The udf code only works with
page-sized folios, and pretending anything else (using
"folio_unlock()" etc) would be just that - pretending

               Linus



[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux