On 07/11/2018 01:33 AM, Linus Torvalds wrote:
NAK.
On Tue, Jul 10, 2018 at 2:56 AM Wei Wang <wei.w.wang@xxxxxxxxx> wrote:
+
+ buf_page = list_first_entry_or_null(pages, struct page, lru);
+ if (!buf_page)
+ return -EINVAL;
+ buf = (__le64 *)page_address(buf_page);
Stop this garbage.
Why the hell would you pass in some crazy "liost of pages" that uses
that lru list?
That's just insane shit.
Just pass in a an array to fill in. No idiotic games like this with
odd list entries (what's the locking?) and crazy casting to
So if you want an array of page addresses, pass that in as such. If
you want to do it in a page, do it with
u64 *array = page_address(page);
int nr = PAGE_SIZE / sizeof(u64);
and now you pass that array in to the thing. None of this completely
insane crazy crap interfaces.
Plus, I still haven't heard an explanation for why you want so many
pages in the first place, and why you want anything but MAX_ORDER-1.
Sorry for missing that explanation.
We only get addresses of the "MAX_ORDER-1" blocks into the array. The
max size of the array that could be allocated by kmalloc is
KMALLOC_MAX_SIZE (i.e. 4MB on x86). With that max array, we could load
"4MB / sizeof(u64)" addresses of "MAX_ORDER-1" blocks, that is, 2TB free
memory at most. We thought about removing that 2TB limitation by passing
in multiple such max arrays (a list of them).
But 2TB has been enough for our use cases so far, and agree it would be
better to have a simpler API in the first place. So I plan to go back to
the previous version of just passing in one simple array
(https://lkml.org/lkml/2018/6/15/21) if no objections.
Best,
Wei
