On 12/5/19 3:58 PM, Qian Cai wrote: > > >> On Dec 5, 2019, at 6:24 PM, John Hubbard <jhubbard@xxxxxxxxxx> wrote: >> >> Let's check in the fix that is clearly correct and non-controversial, in one >> patch. Then another patch can be created for the other case. This allows forward >> progress and quick resolution of the user's bug report, while still dealing >> with all the problems. >> >> If you try to fix too many problems in one patch (and remember, sometimes ">1" >> is too many), then things bog down. It's always a judgment call, but what's >> unfolding here is quite consistent with the usual judgment calls in this area. >> >> I don't think anyone is saying, "don't work on the second problem", it's just >> that it's less urgent, due to no reports from the field. If you are passionate >> about fixing the second problem (and are ready and willing to handle the fallout >> from user space, if it occurs), then I'd encourage you to look into it. >> >> It could turn out to be one of those "cannot change this because user space expectations >> have baked and hardened, and changes would break user space" situations, just to >> warn you in advance, though. > > There is no need to paper over the underlying issue. One can think there is only one problem. The way move_pages() deal with pages are already in the desired node. Then, I don’t see there is any controversy that it was broken for so long and just restore it to according to the manpage. If you worried about people has already depended on the broken behavior, it could stay in linux-next for many releases to gather feedback. In any case, I don’t see it need to hurry to fix this until someone can show the real world use case for it apart from some random test code. > Felix's code is not random test code. It's code he wrote and he expected it to work. Anyway, I've explained what I want here, and done my best to explain it. So I'm dropping off now. :) thanks, -- John Hubbard NVIDIA
