diff mbox

[1/3] efi: Introduce *_continue efi_memory_desc iterators

Message ID 1464707672-21882-2-git-send-email-catalin.marinas@arm.com
State New
Headers show

Commit Message

Catalin Marinas May 31, 2016, 3:14 p.m. UTC
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(-)


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Comments

Mark Rutland June 1, 2016, 10:34 a.m. UTC | #1
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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Catalin Marinas June 1, 2016, 10:43 a.m. UTC | #2
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.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Catalin Marinas June 2, 2016, 4:29 p.m. UTC | #3
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.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Catalin Marinas June 2, 2016, 5:11 p.m. UTC | #4
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).

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff mbox

Patch

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.