* Jeff Xu <jeffxu@xxxxxxxxxxxx> [240830 12:06]: > Hi Liam > > On Thu, Aug 29, 2024 at 9:01 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > > > Changes since v7: > > > > This is all the patches I've sent for v7 fixups plus the return code for > > mseal(). The incorrect return code was introduced in an earlier patch > > and then modified (still incorrectly) later, so this version will > > hopefully bisect cleanly. > > > > - Fixed return type of vms_gather_munmap_vmas() to -ENOMEM or -EPERM > > - Passed through error returned from vms_gather_munmap_vmas() in > > mmap_region() - Thanks Jeff > > I would think it is cleaner to fix the original commit directly > instead of as part of a large patch series, no ? If not possible, > maybe mm-unstable should apply my fix first then you can refactor > based on that ? No, it is not. These patches are not up stream, so the fixes line will be stale before it is even available. No one is affected except the mm-unstable branch and linux-next. Patches to commits that are not upstream can change, and almost always do with fixes like this. What I have done here is to fix the series so that each patch will keep passing the mseal() tests. That way, if there is an issue with mseal(), it can be git bisected to find the problem without finding a fixed problem. If your fix was put into mm-unstable, all linux-next branches would have an intermittent bug present on bisection, and waiting to respin the patches means they miss out on testing time. This is why we squash fixes into patches during development, or ask akpm to do so by replying to the broken patch. Andrew prefers not resending large patch sets because something may be missed, so for smaller changes they are sent with a request to squash them on his side. In this case, there would have been 3 or 4 patches that needed to be updated (two changed, two with merge issues I believe), so I sent a v8 because the alternative would have been confusing. Thanks, Liam
