| Message ID | 1464707672-21882-2-git-send-email-catalin.marinas@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Catalin, On Tue, May 31, 2016 at 04:14:30PM +0100, Catalin Marinas wrote: > The for_each_efi_memory_desc_continue() macro and corresponding > "_in_map" allow iterating over an efi_memory_map from a given position. > For code reuse between the existing iterator and the _continue variant, > this patch also introduces efi_memory_desc_next_entry_map(). > > Cc: Matt Fleming <matt@codeblueprint.co.uk> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > --- > include/linux/efi.h | 19 +++++++++++++++++-- > 1 file changed, 17 insertions(+), 2 deletions(-) > > diff --git a/include/linux/efi.h b/include/linux/efi.h > index c2db3ca22217..4b0d880f1cd7 100644 > --- a/include/linux/efi.h > +++ b/include/linux/efi.h > @@ -1002,11 +1002,16 @@ extern int efi_memattr_init(void); > extern int efi_memattr_apply_permissions(struct mm_struct *mm, > efi_memattr_perm_setter fn); > > +/* Find next entry in an efi_memory_map or NULL if md is last */ > +#define efi_memory_desc_next_entry_map(m, md) \ > + ((md) == (efi_memory_desc_t *)((m)->map_end - (m)->desc_size) \ > + ? NULL : (void *)(md) + (m)->desc_size) > + > /* Iterate through an efi_memory_map */ > #define for_each_efi_memory_desc_in_map(m, md) \ > for ((md) = (m)->map; \ > - (md) <= (efi_memory_desc_t *)((m)->map_end - (m)->desc_size); \ > - (md) = (void *)(md) + (m)->desc_size) > + (md); \ > + (md) = efi_memory_desc_next_entry_map(m, md)) As a heads-up, this will conflict with the efi/urgent branch [1], due to commit ee92562e33c516dd ("efi: Fix for_each_efi_memory_desc_in_map() for empty memmaps"). A pull went out for that yesterday [2]. Thanks, Mark. [1] git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git urgent [2] http://lkml.kernel.org/r/1464690224-4503-1-git-send-email-matt@codeblueprint.co.uk
On Wed, Jun 01, 2016 at 11:34:47AM +0100, Mark Rutland wrote: > On Tue, May 31, 2016 at 04:14:30PM +0100, Catalin Marinas wrote: > > The for_each_efi_memory_desc_continue() macro and corresponding > > "_in_map" allow iterating over an efi_memory_map from a given position. > > For code reuse between the existing iterator and the _continue variant, > > this patch also introduces efi_memory_desc_next_entry_map(). > > > > Cc: Matt Fleming <matt@codeblueprint.co.uk> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > > --- > > include/linux/efi.h | 19 +++++++++++++++++-- > > 1 file changed, 17 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/efi.h b/include/linux/efi.h > > index c2db3ca22217..4b0d880f1cd7 100644 > > --- a/include/linux/efi.h > > +++ b/include/linux/efi.h > > @@ -1002,11 +1002,16 @@ extern int efi_memattr_init(void); > > extern int efi_memattr_apply_permissions(struct mm_struct *mm, > > efi_memattr_perm_setter fn); > > > > +/* Find next entry in an efi_memory_map or NULL if md is last */ > > +#define efi_memory_desc_next_entry_map(m, md) \ > > + ((md) == (efi_memory_desc_t *)((m)->map_end - (m)->desc_size) \ > > + ? NULL : (void *)(md) + (m)->desc_size) > > + > > /* Iterate through an efi_memory_map */ > > #define for_each_efi_memory_desc_in_map(m, md) \ > > for ((md) = (m)->map; \ > > - (md) <= (efi_memory_desc_t *)((m)->map_end - (m)->desc_size); \ > > - (md) = (void *)(md) + (m)->desc_size) > > + (md); \ > > + (md) = efi_memory_desc_next_entry_map(m, md)) > > As a heads-up, this will conflict with the efi/urgent branch [1], due to > commit ee92562e33c516dd ("efi: Fix for_each_efi_memory_desc_in_map() for > empty memmaps"). A pull went out for that yesterday [2]. Thanks for the heads up. I'll rebase the patches after -rc2 but anyway I plan to merge them in 4.8 via the arm64 tree, including the patch above if Matt acks it. So there is enough time to fix the conflicts.
On Wed, 01 Jun, at 11:43:26AM, Catalin Marinas wrote: > > Thanks for the heads up. I'll rebase the patches after -rc2 but anyway I > plan to merge them in 4.8 via the arm64 tree, including the patch above > if Matt acks it. So there is enough time to fix the conflicts. I'd really prefer it if you didn't take this series through the arm64 tree, unless there are existing dependencies, of course. There were a number of conflicts in 3 different maintainer trees in linux-next before the most recent merge window opened, and extra work was required to sort that out. I want to avoid that in the future, so expect me to be more insistent about keeping EFI patches in the EFI tree than I have been in the past. Do arm64 prerequisites exist for this series? Or are you planning on adding dependencies on top?
On Thu, Jun 02, 2016 at 03:36:50PM +0100, Matt Fleming wrote: > On Wed, 01 Jun, at 11:43:26AM, Catalin Marinas wrote: > > > > Thanks for the heads up. I'll rebase the patches after -rc2 but anyway I > > plan to merge them in 4.8 via the arm64 tree, including the patch above > > if Matt acks it. So there is enough time to fix the conflicts. > > I'd really prefer it if you didn't take this series through the arm64 > tree, unless there are existing dependencies, of course. > > There were a number of conflicts in 3 different maintainer trees in > linux-next before the most recent merge window opened, and extra work > was required to sort that out. I want to avoid that in the future, so > expect me to be more insistent about keeping EFI patches in the EFI > tree than I have been in the past. > > Do arm64 prerequisites exist for this series? Or are you planning on > adding dependencies on top? I don't know when Jeremy plans to submit his contiguous PTE patches (we rejected them on the grounds of unnecessary huge page splitting, hence this series). If he's not targeting 4.8, I'm happy for the patches to go in via the EFI tree.
On 06/02/2016 11:29 AM, Catalin Marinas wrote: > On Thu, Jun 02, 2016 at 03:36:50PM +0100, Matt Fleming wrote: >> On Wed, 01 Jun, at 11:43:26AM, Catalin Marinas wrote: >>> >>> Thanks for the heads up. I'll rebase the patches after -rc2 but anyway I >>> plan to merge them in 4.8 via the arm64 tree, including the patch above >>> if Matt acks it. So there is enough time to fix the conflicts. >> >> I'd really prefer it if you didn't take this series through the arm64 >> tree, unless there are existing dependencies, of course. >> >> There were a number of conflicts in 3 different maintainer trees in >> linux-next before the most recent merge window opened, and extra work >> was required to sort that out. I want to avoid that in the future, so >> expect me to be more insistent about keeping EFI patches in the EFI >> tree than I have been in the past. >> >> Do arm64 prerequisites exist for this series? Or are you planning on >> adding dependencies on top? > > I don't know when Jeremy plans to submit his contiguous PTE patches (we > rejected them on the grounds of unnecessary huge page splitting, hence > this series). If he's not targeting 4.8, I'm happy for the patches to go > in via the EFI tree. I can re-post them again for 4.8. They seem to get simpler every time!
On Thu, Jun 02, 2016 at 11:31:14AM -0500, Jeremy Linton wrote: > On 06/02/2016 11:29 AM, Catalin Marinas wrote: > >On Thu, Jun 02, 2016 at 03:36:50PM +0100, Matt Fleming wrote: > >>On Wed, 01 Jun, at 11:43:26AM, Catalin Marinas wrote: > >>> > >>>Thanks for the heads up. I'll rebase the patches after -rc2 but anyway I > >>>plan to merge them in 4.8 via the arm64 tree, including the patch above > >>>if Matt acks it. So there is enough time to fix the conflicts. > >> > >>I'd really prefer it if you didn't take this series through the arm64 > >>tree, unless there are existing dependencies, of course. > >> > >>There were a number of conflicts in 3 different maintainer trees in > >>linux-next before the most recent merge window opened, and extra work > >>was required to sort that out. I want to avoid that in the future, so > >>expect me to be more insistent about keeping EFI patches in the EFI > >>tree than I have been in the past. > >> > >>Do arm64 prerequisites exist for this series? Or are you planning on > >>adding dependencies on top? > > > >I don't know when Jeremy plans to submit his contiguous PTE patches (we > >rejected them on the grounds of unnecessary huge page splitting, hence > >this series). If he's not targeting 4.8, I'm happy for the patches to go > >in via the EFI tree. > > I can re-post them again for 4.8. They seem to get simpler every time! I think you should post them fairly soon so that we get a chance to review them and ideally push into next around -rc4. Regarding these efi/arm64 patches, I can push them to a branch (once the conflicting efi/urgent patches hit upstream, I guess around -rc2) that Matt can pull into the EFI tree and I can also pull in the arm64 tree *if* we are to merge the Jeremy's patches. Jeremy, you can base your patches on such branch (I'll follow up with the details if that's ok with Matt).
|-----Original Message----- |From: Catalin Marinas [mailto:catalin.marinas@arm.com] |Sent: Thursday, June 02, 2016 12:12 PM |To: Jeremy Linton |Cc: Matt Fleming; Mark Rutland; linux-efi@vger.kernel.org; Will Deacon; |linux-arm-kernel@lists.infradead.org |Subject: Re: [PATCH 1/3] efi: Introduce *_continue efi_memory_desc |iterators | |On Thu, Jun 02, 2016 at 11:31:14AM -0500, Jeremy Linton wrote: |> On 06/02/2016 11:29 AM, Catalin Marinas wrote: |> >On Thu, Jun 02, 2016 at 03:36:50PM +0100, Matt Fleming wrote: |> >>On Wed, 01 Jun, at 11:43:26AM, Catalin Marinas wrote: |> >>> |> >>>Thanks for the heads up. I'll rebase the patches after -rc2 but |> >>>anyway I plan to merge them in 4.8 via the arm64 tree, including |> >>>the patch above if Matt acks it. So there is enough time to fix the |conflicts. |> >> |> >>I'd really prefer it if you didn't take this series through the |> >>arm64 tree, unless there are existing dependencies, of course. |> >> |> >>There were a number of conflicts in 3 different maintainer trees in |> >>linux-next before the most recent merge window opened, and extra |> >>work was required to sort that out. I want to avoid that in the |> >>future, so expect me to be more insistent about keeping EFI patches |> >>in the EFI tree than I have been in the past. |> >> |> >>Do arm64 prerequisites exist for this series? Or are you planning on |> >>adding dependencies on top? |> > |> >I don't know when Jeremy plans to submit his contiguous PTE patches |> >(we rejected them on the grounds of unnecessary huge page splitting, |> >hence this series). If he's not targeting 4.8, I'm happy for the |> >patches to go in via the EFI tree. |> |> I can re-post them again for 4.8. They seem to get simpler every time! | |I think you should post them fairly soon so that we get a chance to review |them and ideally push into next around -rc4. | |Regarding these efi/arm64 patches, I can push them to a branch (once the |conflicting efi/urgent patches hit upstream, I guess around -rc2) that Matt can |pull into the EFI tree and I can also pull in the arm64 tree |*if* we are to merge the Jeremy's patches. | |Jeremy, you can base your patches on such branch (I'll follow up with the |details if that's ok with Matt). Sure. Most of the delay on posting them generally comes down to how many machines I try to boot them on with a given kernel, which is related to how many ACPI issues I happen to have. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Thu, 02 Jun, at 06:11:52PM, Catalin Marinas wrote: > > I think you should post them fairly soon so that we get a chance to > review them and ideally push into next around -rc4. > > Regarding these efi/arm64 patches, I can push them to a branch (once the > conflicting efi/urgent patches hit upstream, I guess around -rc2) that > Matt can pull into the EFI tree and I can also pull in the arm64 tree > *if* we are to merge the Jeremy's patches. > > Jeremy, you can base your patches on such branch (I'll follow up with > the details if that's ok with Matt). Sure, this works for me. Thanks Catalin.
diff --git a/include/linux/efi.h b/include/linux/efi.h index c2db3ca22217..4b0d880f1cd7 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -1002,11 +1002,16 @@ extern int efi_memattr_init(void); extern int efi_memattr_apply_permissions(struct mm_struct *mm, efi_memattr_perm_setter fn); +/* Find next entry in an efi_memory_map or NULL if md is last */ +#define efi_memory_desc_next_entry_map(m, md) \ + ((md) == (efi_memory_desc_t *)((m)->map_end - (m)->desc_size) \ + ? NULL : (void *)(md) + (m)->desc_size) + /* Iterate through an efi_memory_map */ #define for_each_efi_memory_desc_in_map(m, md) \ for ((md) = (m)->map; \ - (md) <= (efi_memory_desc_t *)((m)->map_end - (m)->desc_size); \ - (md) = (void *)(md) + (m)->desc_size) + (md); \ + (md) = efi_memory_desc_next_entry_map(m, md)) /** * for_each_efi_memory_desc - iterate over descriptors in efi.memmap @@ -1017,6 +1022,16 @@ extern int efi_memattr_apply_permissions(struct mm_struct *mm, #define for_each_efi_memory_desc(md) \ for_each_efi_memory_desc_in_map(&efi.memmap, md) +/* Continue iterating through an efi_memory_map */ +#define for_each_efi_memory_desc_in_map_continue(m, md) \ + for ((md) = efi_memory_desc_next_entry_map(m, md); \ + (md); \ + (md) = efi_memory_desc_next_entry_map(m, md)) + +/* Continue iterating through efi.memmap */ +#define for_each_efi_memory_desc_continue(md) \ + for_each_efi_memory_desc_in_map_continue(&efi.memmap, md) + /* * Format an EFI memory descriptor's type and attributes to a user-provided * character buffer, as per snprintf(), and return the buffer.
The for_each_efi_memory_desc_continue() macro and corresponding "_in_map" allow iterating over an efi_memory_map from a given position. For code reuse between the existing iterator and the _continue variant, this patch also introduces efi_memory_desc_next_entry_map(). Cc: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> --- include/linux/efi.h | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)