| Message ID | 20241211232754.1583023-1-kaleshsingh@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm: Introduce arch_mmap_hint() | expand |
+ Lorenzo Can you please Cc the people listed in the maintainers on the files you are submitting against? You seemed to Cc everyone but the mmap.c file maintainers? * Kalesh Singh <kaleshsingh@google.com> [241211 18:28]: > Hi all, > > This is v2 othe the arch_mmap_hint() series. > > Changes in v2: > - MAP_FIXED case is also handled in arch_mmap_hint() since this is just a > special case of the hint addr being "enforced", per Yang Shi. > - Consolidate most of the error handling in arch_mmap_hint(). > - Patch 16 ("mm: Fallback to generic_mmap_hint()") was folded into > Patch 2 ("mm: x86: Introduce arch_mmap_hint()") > > v1: https://lore.kernel.org/r/20241210024119.2488608-1-kaleshsingh@google.com/ > > ======= > > This series introduces arch_mmap_hint() to handle allocating VA space > for the hint address. Why? Could we get more details in your cover letter please? This entire email has as much detail as the subject line. I don't want more arch_ anything. If we can do this in a more generic way, then we should. > > Patches 1-16 introduce this new helper and Patch 17 uses it to fix the > issue of mmap hint being ignored in some cases due to THP alignment [1] > > [1] https://lore.kernel.org/r/20241118214650.3667577-1-kaleshsingh@google.com/ > > Thanks, > Kalesh > > > Kalesh Singh (16): > mm: Introduce generic_mmap_hint() > mm: x86: Introduce arch_mmap_hint() > mm: arm: Introduce arch_mmap_hint() > mm: alpha: Introduce arch_mmap_hint() > mm: arc: Use generic_mmap_hint() > mm: csky: Introduce arch_mmap_hint() > mm: loongarch: Introduce arch_mmap_hint() > mm: mips: Introduce arch_align_mmap_hint() > mm: parisc: Introduce arch_align_mmap_hint() > mm: s390: Use generic_mmap_hint() > mm: sh: Introduce arch_mmap_hint() > mm: sparc32: Introduce arch_mmap_hint() > mm: sparc64: Introduce arch_mmap_hint() > mm: xtensa: Introduce arch_mmap_hint() > mm: powerpc: Introduce arch_mmap_hint() > mm: Respect mmap hint before THP alignment if allocation is possible > > arch/alpha/include/asm/pgtable.h | 1 + > arch/alpha/kernel/osf_sys.c | 31 +++--- > arch/arc/include/asm/pgtable.h | 1 + > arch/arc/mm/mmap.c | 43 +++++---- > arch/arm/include/asm/pgtable.h | 1 + > arch/arm/mm/mmap.c | 107 +++++++++------------ > arch/csky/abiv1/inc/abi/pgtable-bits.h | 1 + > arch/csky/abiv1/mmap.c | 68 +++++++------ > arch/loongarch/include/asm/pgtable.h | 1 + > arch/loongarch/mm/mmap.c | 49 +++++----- > arch/mips/include/asm/pgtable.h | 1 + > arch/mips/mm/mmap.c | 50 +++++----- > arch/parisc/include/asm/pgtable.h | 1 + > arch/parisc/kernel/sys_parisc.c | 53 +++++----- > arch/powerpc/include/asm/book3s/64/slice.h | 1 + > arch/powerpc/mm/book3s64/slice.c | 31 ++++++ > arch/s390/include/asm/pgtable.h | 1 + > arch/s390/mm/mmap.c | 51 +++++----- > arch/sh/include/asm/pgtable.h | 1 + > arch/sh/mm/mmap.c | 83 ++++++---------- > arch/sparc/include/asm/pgtable_32.h | 1 + > arch/sparc/include/asm/pgtable_64.h | 1 + > arch/sparc/kernel/sys_sparc_32.c | 33 ++++--- > arch/sparc/kernel/sys_sparc_64.c | 96 +++++++----------- > arch/x86/include/asm/pgtable_64.h | 1 + > arch/x86/kernel/sys_x86_64.c | 64 ++++++------ > arch/xtensa/kernel/syscall.c | 31 ++++-- > include/linux/sched/mm.h | 9 ++ > mm/huge_memory.c | 17 ++-- > mm/mmap.c | 86 +++++++++++------ > 30 files changed, 491 insertions(+), 424 deletions(-) > > -- > 2.47.0.338.g60cca15819-goog > >
On Wed, Dec 11, 2024 at 03:27:38PM -0800, Kalesh Singh wrote: > Hi all, > > This is v2 othe the arch_mmap_hint() series. > > Changes in v2: > - MAP_FIXED case is also handled in arch_mmap_hint() since this is just a > special case of the hint addr being "enforced", per Yang Shi. > - Consolidate most of the error handling in arch_mmap_hint(). > - Patch 16 ("mm: Fallback to generic_mmap_hint()") was folded into > Patch 2 ("mm: x86: Introduce arch_mmap_hint()") > > v1: https://lore.kernel.org/r/20241210024119.2488608-1-kaleshsingh@google.com/ > > ======= > > This series introduces arch_mmap_hint() to handle allocating VA space > for the hint address. But why? You're basically forcing me to read the entire series to figure out what you're doing and why. I decline. > Patches 1-16 introduce this new helper and Patch 17 uses it to fix the > issue of mmap hint being ignored in some cases due to THP alignment [1] > > [1] https://lore.kernel.org/r/20241118214650.3667577-1-kaleshsingh@google.com/ > > Thanks, > Kalesh > > > Kalesh Singh (16): > mm: Introduce generic_mmap_hint() > mm: x86: Introduce arch_mmap_hint() > mm: arm: Introduce arch_mmap_hint() > mm: alpha: Introduce arch_mmap_hint() > mm: arc: Use generic_mmap_hint() > mm: csky: Introduce arch_mmap_hint() > mm: loongarch: Introduce arch_mmap_hint() > mm: mips: Introduce arch_align_mmap_hint() > mm: parisc: Introduce arch_align_mmap_hint() > mm: s390: Use generic_mmap_hint() > mm: sh: Introduce arch_mmap_hint() > mm: sparc32: Introduce arch_mmap_hint() > mm: sparc64: Introduce arch_mmap_hint() > mm: xtensa: Introduce arch_mmap_hint() > mm: powerpc: Introduce arch_mmap_hint() > mm: Respect mmap hint before THP alignment if allocation is possible > > arch/alpha/include/asm/pgtable.h | 1 + > arch/alpha/kernel/osf_sys.c | 31 +++--- > arch/arc/include/asm/pgtable.h | 1 + > arch/arc/mm/mmap.c | 43 +++++---- > arch/arm/include/asm/pgtable.h | 1 + > arch/arm/mm/mmap.c | 107 +++++++++------------ > arch/csky/abiv1/inc/abi/pgtable-bits.h | 1 + > arch/csky/abiv1/mmap.c | 68 +++++++------ > arch/loongarch/include/asm/pgtable.h | 1 + > arch/loongarch/mm/mmap.c | 49 +++++----- > arch/mips/include/asm/pgtable.h | 1 + > arch/mips/mm/mmap.c | 50 +++++----- > arch/parisc/include/asm/pgtable.h | 1 + > arch/parisc/kernel/sys_parisc.c | 53 +++++----- > arch/powerpc/include/asm/book3s/64/slice.h | 1 + > arch/powerpc/mm/book3s64/slice.c | 31 ++++++ > arch/s390/include/asm/pgtable.h | 1 + > arch/s390/mm/mmap.c | 51 +++++----- > arch/sh/include/asm/pgtable.h | 1 + > arch/sh/mm/mmap.c | 83 ++++++---------- > arch/sparc/include/asm/pgtable_32.h | 1 + > arch/sparc/include/asm/pgtable_64.h | 1 + > arch/sparc/kernel/sys_sparc_32.c | 33 ++++--- > arch/sparc/kernel/sys_sparc_64.c | 96 +++++++----------- > arch/x86/include/asm/pgtable_64.h | 1 + > arch/x86/kernel/sys_x86_64.c | 64 ++++++------ > arch/xtensa/kernel/syscall.c | 31 ++++-- > include/linux/sched/mm.h | 9 ++ > mm/huge_memory.c | 17 ++-- > mm/mmap.c | 86 +++++++++++------ > 30 files changed, 491 insertions(+), 424 deletions(-) > > -- > 2.47.0.338.g60cca15819-goog > >
NACK. Resend this _as an RFC_, _with the correct maintainers and reviewers cc'd_. You've fundamentally violated kernel process and etiquette. I'd be more forgiving, but this is at v2 and you've not cc'd KEY people. Twice. This is totally unacceptable. See [0] if you are unsure of how to do so. You've also sent a 16 patch series (!) immediately prior to the holidays (!!) introducing an arch hook (!!!), which is strictly something we want to try to avoid or lessen in future, which you'd know, had you followed basic kernel etiquette and process and cc'd us on v1. Any discussion that will be had here with others we won't be cc'd on, it's 16 patches, this isn't workable. I'm on holiday from next week, it's not really fair to put this all on Liam immediately prior to Christmas, so let's just examine this as an RFC first. I hate to think that I need to set lei rules to catch stuff like this, but clearly, I do. I will be updating these to check on all relevant files. Sigh. [0]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#select-the-recipients-for-your-patch On Thu, Dec 12, 2024 at 04:02:31PM -0500, Liam R. Howlett wrote: > > + Lorenzo > > Can you please Cc the people listed in the maintainers on the files you > are submitting against? You seemed to Cc everyone but the mmap.c file > maintainers? Thanks Liam. Also +Jann, another reviewer Kalesh missed (he only got Vlastimil and Andrew so 2/5... of those required...) > > > * Kalesh Singh <kaleshsingh@google.com> [241211 18:28]: > > Hi all, > > > > This is v2 othe the arch_mmap_hint() series. > > > > Changes in v2: > > - MAP_FIXED case is also handled in arch_mmap_hint() since this is just a > > special case of the hint addr being "enforced", per Yang Shi. > > - Consolidate most of the error handling in arch_mmap_hint(). > > - Patch 16 ("mm: Fallback to generic_mmap_hint()") was folded into > > Patch 2 ("mm: x86: Introduce arch_mmap_hint()") > > > > v1: https://lore.kernel.org/r/20241210024119.2488608-1-kaleshsingh@google.com/ > > > > ======= > > > > This series introduces arch_mmap_hint() to handle allocating VA space > > for the hint address. > > Why? Could we get more details in your cover letter please? This > entire email has as much detail as the subject line. Yes the cover letter is ridiculously small for what that is doing. > > I don't want more arch_ anything. If we can do this in a more generic > way, then we should. ENTIRELY agreed. > > > > > Patches 1-16 introduce this new helper and Patch 17 uses it to fix the > > issue of mmap hint being ignored in some cases due to THP alignment [1] > > > > [1] https://lore.kernel.org/r/20241118214650.3667577-1-kaleshsingh@google.com/ > > > > Thanks, > > Kalesh > > > > > > Kalesh Singh (16): > > mm: Introduce generic_mmap_hint() > > mm: x86: Introduce arch_mmap_hint() > > mm: arm: Introduce arch_mmap_hint() > > mm: alpha: Introduce arch_mmap_hint() > > mm: arc: Use generic_mmap_hint() > > mm: csky: Introduce arch_mmap_hint() > > mm: loongarch: Introduce arch_mmap_hint() > > mm: mips: Introduce arch_align_mmap_hint() > > mm: parisc: Introduce arch_align_mmap_hint() > > mm: s390: Use generic_mmap_hint() > > mm: sh: Introduce arch_mmap_hint() > > mm: sparc32: Introduce arch_mmap_hint() > > mm: sparc64: Introduce arch_mmap_hint() > > mm: xtensa: Introduce arch_mmap_hint() > > mm: powerpc: Introduce arch_mmap_hint() > > mm: Respect mmap hint before THP alignment if allocation is possible > > > > arch/alpha/include/asm/pgtable.h | 1 + > > arch/alpha/kernel/osf_sys.c | 31 +++--- > > arch/arc/include/asm/pgtable.h | 1 + > > arch/arc/mm/mmap.c | 43 +++++---- > > arch/arm/include/asm/pgtable.h | 1 + > > arch/arm/mm/mmap.c | 107 +++++++++------------ > > arch/csky/abiv1/inc/abi/pgtable-bits.h | 1 + > > arch/csky/abiv1/mmap.c | 68 +++++++------ > > arch/loongarch/include/asm/pgtable.h | 1 + > > arch/loongarch/mm/mmap.c | 49 +++++----- > > arch/mips/include/asm/pgtable.h | 1 + > > arch/mips/mm/mmap.c | 50 +++++----- > > arch/parisc/include/asm/pgtable.h | 1 + > > arch/parisc/kernel/sys_parisc.c | 53 +++++----- > > arch/powerpc/include/asm/book3s/64/slice.h | 1 + > > arch/powerpc/mm/book3s64/slice.c | 31 ++++++ > > arch/s390/include/asm/pgtable.h | 1 + > > arch/s390/mm/mmap.c | 51 +++++----- > > arch/sh/include/asm/pgtable.h | 1 + > > arch/sh/mm/mmap.c | 83 ++++++---------- > > arch/sparc/include/asm/pgtable_32.h | 1 + > > arch/sparc/include/asm/pgtable_64.h | 1 + > > arch/sparc/kernel/sys_sparc_32.c | 33 ++++--- > > arch/sparc/kernel/sys_sparc_64.c | 96 +++++++----------- > > arch/x86/include/asm/pgtable_64.h | 1 + > > arch/x86/kernel/sys_x86_64.c | 64 ++++++------ > > arch/xtensa/kernel/syscall.c | 31 ++++-- > > include/linux/sched/mm.h | 9 ++ > > mm/huge_memory.c | 17 ++-- > > mm/mmap.c | 86 +++++++++++------ > > 30 files changed, 491 insertions(+), 424 deletions(-) Yuck. Is this copy/paste really necessary... > > > > -- > > 2.47.0.338.g60cca15819-goog > > > >
On Thu, 12 Dec 2024 22:51:34 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > You've fundamentally violated kernel process and etiquette. I'd be more > forgiving, but this is at v2 and you've not cc'd KEY people. Twice. This is > totally unacceptable. See [0] if you are unsure of how to do so. This feels excessive to me. linux-mm averages a mere 140 mesages/day and it seems reasonable to assume that key people are spending their 5 minutes to scroll through the email subjects.
On Thu, Dec 12, 2024 at 05:36:09PM -0800, Andrew Morton wrote: > On Thu, 12 Dec 2024 22:51:34 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > > > You've fundamentally violated kernel process and etiquette. I'd be more > > forgiving, but this is at v2 and you've not cc'd KEY people. Twice. This is > > totally unacceptable. See [0] if you are unsure of how to do so. > > This feels excessive to me. linux-mm averages a mere 140 mesages/day > and it seems reasonable to assume that key people are spending their 5 > minutes to scroll through the email subjects. In practice we did all miss it, and I don't think it's unreasonable to ask people to run get_maintainers.pl to avoid this. In any case, I truly do think this series works better as RFC, I mean Liam has already voiced the kind of disagreements I share with it, and we need to rethink how to approach it in general. So if this is simply sent as RFC with the correct cc's (and ideally with some review feedback applied - a better cover letter, etc.) then it makes everything easier. As mentioned the timing is unfortunate here, this is a series we really want to make sure is properly reviewed before any chance of merge so again this points to RFC being the way forward.
On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > > On Thu, Dec 12, 2024 at 05:36:09PM -0800, Andrew Morton wrote: > > On Thu, 12 Dec 2024 22:51:34 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > > > > > You've fundamentally violated kernel process and etiquette. I'd be more > > > forgiving, but this is at v2 and you've not cc'd KEY people. Twice. This is > > > totally unacceptable. See [0] if you are unsure of how to do so. > > > > This feels excessive to me. linux-mm averages a mere 140 mesages/day > > and it seems reasonable to assume that key people are spending their 5 > > minutes to scroll through the email subjects. > > In practice we did all miss it, and I don't think it's unreasonable to ask > people to run get_maintainers.pl to avoid this. > > In any case, I truly do think this series works better as RFC, I mean Liam > has already voiced the kind of disagreements I share with it, and we need > to rethink how to approach it in general. > > So if this is simply sent as RFC with the correct cc's (and ideally with > some review feedback applied - a better cover letter, etc.) then it makes > everything easier. > > As mentioned the timing is unfortunate here, this is a series we really > want to make sure is properly reviewed before any chance of merge so again > this points to RFC being the way forward. Hi everyone, Sorry for the delayed response -- I was traveling and didn’t have access to email. Thank you for the feedback. I realize I missed some key reviewers in the CC list for this patch. When I ran get_maintainer.pl, it returned a large list of recipients. To avoid over-CC’ing people (which has been an issue for me in the past), I tried to trim it down to maintainers and a few others I thought would be interested. Clearly, I got it wrong and missed some key folks. That was not my intention, and I’ll make sure to fix it when I resend the patch as an RFC. On the technical side, Liam is right that the copy-pasted arch code has inconsistencies (missing checks, order of checks, ...). I agree there’s room for further consolidation. I’ll take another stab at it and resend it as an RFC with an updated cover letter, as Lorenzo and others suggested. Thanks, Kalesh
On Fri, Dec 13, 2024 at 10:06:55AM -0500, Kalesh Singh wrote: > On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes > <lorenzo.stoakes@oracle.com> wrote: > > > > On Thu, Dec 12, 2024 at 05:36:09PM -0800, Andrew Morton wrote: > > > On Thu, 12 Dec 2024 22:51:34 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > > > > > > > You've fundamentally violated kernel process and etiquette. I'd be more > > > > forgiving, but this is at v2 and you've not cc'd KEY people. Twice. This is > > > > totally unacceptable. See [0] if you are unsure of how to do so. > > > > > > This feels excessive to me. linux-mm averages a mere 140 mesages/day > > > and it seems reasonable to assume that key people are spending their 5 > > > minutes to scroll through the email subjects. > > > > In practice we did all miss it, and I don't think it's unreasonable to ask > > people to run get_maintainers.pl to avoid this. > > > > In any case, I truly do think this series works better as RFC, I mean Liam > > has already voiced the kind of disagreements I share with it, and we need > > to rethink how to approach it in general. > > > > So if this is simply sent as RFC with the correct cc's (and ideally with > > some review feedback applied - a better cover letter, etc.) then it makes > > everything easier. > > > > As mentioned the timing is unfortunate here, this is a series we really > > want to make sure is properly reviewed before any chance of merge so again > > this points to RFC being the way forward. > > Hi everyone, > > Sorry for the delayed response -- I was traveling and didn’t have > access to email. Ack. > > Thank you for the feedback. I realize I missed some key reviewers in > the CC list for this patch. > When I ran get_maintainer.pl, it returned a large list of recipients. > To avoid over-CC’ing people (which has been an issue for me in the > past), I tried to trim it down to maintainers and a few others I > thought would be interested. Clearly, I got it wrong and missed some > key folks. That was not my intention, and I’ll make sure to fix it > when I resend the patch as an RFC. Sure thanks :) Much appreciated. Sorry to be so curt there, just I think important to underline. We just want to make sure we can find a way to get this series sorted out so we can get it merged in a form that makes sense overall, ultimately! :) > > On the technical side, Liam is right that the copy-pasted arch code > has inconsistencies (missing checks, order of checks, ...). I agree > there’s room for further consolidation. I’ll take another stab at it > and resend it as an RFC with an updated cover letter, as Lorenzo and > others suggested. The most useful thing here as well to help us understand would be to write more in the cover letter to expand on what it is you ultimately what to achieve here - it seems like an extension on the existing THP work on a per-arch basis (I may be wrong)? So adding more detail would be super useful here! :) We do hope to avoid arch hooks if at all possible explicitly for the reason that they can be applied at unfortunate times in terms of locking/whether the objects in question are fully/partially instantiated, VMA visibility etc. etc. based on having had issues in these areas before. Also if a hook means 'anything' can happen at a certain point, it means we can't make any assumptions about what has/hasn't and have to account for anything which seriously complicates things. Ideally we'd find a means to achieve the same thing while also exposing us as little as possible to what may be mutated. > > Thanks, > Kalesh Thanks!
* Lorenzo Stoakes <lorenzo.stoakes@oracle.com> [241213 10:16]: > On Fri, Dec 13, 2024 at 10:06:55AM -0500, Kalesh Singh wrote: > > On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes > > <lorenzo.stoakes@oracle.com> wrote: ... > > > > On the technical side, Liam is right that the copy-pasted arch code > > has inconsistencies (missing checks, order of checks, ...). I agree > > there’s room for further consolidation. I’ll take another stab at it > > and resend it as an RFC with an updated cover letter, as Lorenzo and > > others suggested. Thanks. Can you please include what platforms you have tested in your cover letter (and level of testing - booting, running something, etc). If you have not tested them, then it might be worth it to have it as an RFC to point this out - at least initially. Some of these are very difficult to set up for testing, but it is also possible that you did that and the maintainers/people who usually test these things will assume it's fine if you don't spell out what's going on. > > The most useful thing here as well to help us understand would be to write > more in the cover letter to expand on what it is you ultimately what to > achieve here - it seems like an extension on the existing THP work on a > per-arch basis (I may be wrong)? So adding more detail would be super > useful here! :) > > We do hope to avoid arch hooks if at all possible explicitly for the reason > that they can be applied at unfortunate times in terms of locking/whether > the objects in question are fully/partially instantiated, VMA visibility > etc. etc. based on having had issues in these areas before. > > Also if a hook means 'anything' can happen at a certain point, it means we > can't make any assumptions about what has/hasn't and have to account for > anything which seriously complicates things. > > Ideally we'd find a means to achieve the same thing while also exposing us > as little as possible to what may be mutated. Yes, I'm not sure of what your plans are, but I would like to see all of these custom functions removed, if at all possible. Thanks, Liam
On Fri, Dec 13, 2024 at 11:45 AM 'Liam R. Howlett' via kernel-team <kernel-team@android.com> wrote: > > * Lorenzo Stoakes <lorenzo.stoakes@oracle.com> [241213 10:16]: > > On Fri, Dec 13, 2024 at 10:06:55AM -0500, Kalesh Singh wrote: > > > On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes > > > <lorenzo.stoakes@oracle.com> wrote: > > ... > > > > > > > On the technical side, Liam is right that the copy-pasted arch code > > > has inconsistencies (missing checks, order of checks, ...). I agree > > > there’s room for further consolidation. I’ll take another stab at it > > > and resend it as an RFC with an updated cover letter, as Lorenzo and > > > others suggested. > > Thanks. Can you please include what platforms you have tested in your > cover letter (and level of testing - booting, running something, etc). > > If you have not tested them, then it might be worth it to have it as an > RFC to point this out - at least initially. Some of these are very > difficult to set up for testing, but it is also possible that you did > that and the maintainers/people who usually test these things will > assume it's fine if you don't spell out what's going on. > I build-tested most of these except (csky and loongarch) and ran android runtime (ART) tests on arm64 and x86. I can try to spin up a few of the others and will add it to the description. > > > > The most useful thing here as well to help us understand would be to write > > more in the cover letter to expand on what it is you ultimately what to > > achieve here - it seems like an extension on the existing THP work on a > > per-arch basis (I may be wrong)? So adding more detail would be super > > useful here! :) > > > > We do hope to avoid arch hooks if at all possible explicitly for the reason > > that they can be applied at unfortunate times in terms of locking/whether > > the objects in question are fully/partially instantiated, VMA visibility > > etc. etc. based on having had issues in these areas before. > > > > Also if a hook means 'anything' can happen at a certain point, it means we > > can't make any assumptions about what has/hasn't and have to account for > > anything which seriously complicates things. > > > > Ideally we'd find a means to achieve the same thing while also exposing us > > as little as possible to what may be mutated. > > > Yes, I'm not sure of what your plans are, but I would like to see all of > these custom functions removed, if at all possible. Initially I think we can remove the mmap hint portion of the logic; and follow up with removing arch_get_unmapped_area[_topdown](). Some of those may not make sense to consolidate e.g. powerpc's slice_get_unmapped_area() which doesn't share much in common with the rest. Thanks, Kalesh > > Thanks, > Liam > > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >
Hi all, This is v2 othe the arch_mmap_hint() series. Changes in v2: - MAP_FIXED case is also handled in arch_mmap_hint() since this is just a special case of the hint addr being "enforced", per Yang Shi. - Consolidate most of the error handling in arch_mmap_hint(). - Patch 16 ("mm: Fallback to generic_mmap_hint()") was folded into Patch 2 ("mm: x86: Introduce arch_mmap_hint()") v1: https://lore.kernel.org/r/20241210024119.2488608-1-kaleshsingh@google.com/ ======= This series introduces arch_mmap_hint() to handle allocating VA space for the hint address. Patches 1-16 introduce this new helper and Patch 17 uses it to fix the issue of mmap hint being ignored in some cases due to THP alignment [1] [1] https://lore.kernel.org/r/20241118214650.3667577-1-kaleshsingh@google.com/ Thanks, Kalesh Kalesh Singh (16): mm: Introduce generic_mmap_hint() mm: x86: Introduce arch_mmap_hint() mm: arm: Introduce arch_mmap_hint() mm: alpha: Introduce arch_mmap_hint() mm: arc: Use generic_mmap_hint() mm: csky: Introduce arch_mmap_hint() mm: loongarch: Introduce arch_mmap_hint() mm: mips: Introduce arch_align_mmap_hint() mm: parisc: Introduce arch_align_mmap_hint() mm: s390: Use generic_mmap_hint() mm: sh: Introduce arch_mmap_hint() mm: sparc32: Introduce arch_mmap_hint() mm: sparc64: Introduce arch_mmap_hint() mm: xtensa: Introduce arch_mmap_hint() mm: powerpc: Introduce arch_mmap_hint() mm: Respect mmap hint before THP alignment if allocation is possible arch/alpha/include/asm/pgtable.h | 1 + arch/alpha/kernel/osf_sys.c | 31 +++--- arch/arc/include/asm/pgtable.h | 1 + arch/arc/mm/mmap.c | 43 +++++---- arch/arm/include/asm/pgtable.h | 1 + arch/arm/mm/mmap.c | 107 +++++++++------------ arch/csky/abiv1/inc/abi/pgtable-bits.h | 1 + arch/csky/abiv1/mmap.c | 68 +++++++------ arch/loongarch/include/asm/pgtable.h | 1 + arch/loongarch/mm/mmap.c | 49 +++++----- arch/mips/include/asm/pgtable.h | 1 + arch/mips/mm/mmap.c | 50 +++++----- arch/parisc/include/asm/pgtable.h | 1 + arch/parisc/kernel/sys_parisc.c | 53 +++++----- arch/powerpc/include/asm/book3s/64/slice.h | 1 + arch/powerpc/mm/book3s64/slice.c | 31 ++++++ arch/s390/include/asm/pgtable.h | 1 + arch/s390/mm/mmap.c | 51 +++++----- arch/sh/include/asm/pgtable.h | 1 + arch/sh/mm/mmap.c | 83 ++++++---------- arch/sparc/include/asm/pgtable_32.h | 1 + arch/sparc/include/asm/pgtable_64.h | 1 + arch/sparc/kernel/sys_sparc_32.c | 33 ++++--- arch/sparc/kernel/sys_sparc_64.c | 96 +++++++----------- arch/x86/include/asm/pgtable_64.h | 1 + arch/x86/kernel/sys_x86_64.c | 64 ++++++------ arch/xtensa/kernel/syscall.c | 31 ++++-- include/linux/sched/mm.h | 9 ++ mm/huge_memory.c | 17 ++-- mm/mmap.c | 86 +++++++++++------ 30 files changed, 491 insertions(+), 424 deletions(-)