Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Shea Levy]

Hi all,

Shea Levy  writes:

> Hi Palmer,
>
> Palmer Dabbelt  writes:
>
>> On Wed, 18 Apr 2018 04:10:16 PDT (-0700), s...@shealevy.com wrote:
>>> Hi all,
>>>
>>> Shea Levy  writes:
>>>
 This function is effectively identical across 14 architectures, and
 the generic implementation is small enough to be negligible in the
 architectures that do override it. Many of the remaining divergent
 implementations can be included in the common code path in future,
 further reducing code duplication and sharing improvements between
 architectures.

 Series boot-tested on RISC-V (which now uses the generic
 implementation) and x86_64 (which doesn't).

 v6: Add information about build/run testing.
 v5: Add more complete commit messages.
 v4: Use weak symbols instead of Kconfig.
 v3: Make the generic path opt-out instead of opt-in.
 v2: Mark generic free_initrd_mem __init.

 Signed-off-by: Shea Levy 
 ---
  init/initramfs.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/init/initramfs.c b/init/initramfs.c
 index 7e99a0038942..c8fe150f958a 100644
 --- a/init/initramfs.c
 +++ b/init/initramfs.c
 @@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
  #include 
  #include 
  
 +void __init __weak free_initrd_mem(unsigned long start, unsigned long end)
 +{
 +   free_reserved_area((void *)start, (void *)end, -1, "initrd");
 +}
 +
  static void __init free_initrd(void)
  {
  #ifdef CONFIG_KEXEC_CORE
 -- 
 2.16.2
>>>
>>> This series has been quiet for a few weeks other than picking up some
>>> arch-specific acks. What is the next step here?
>>
>> I'm not sure.  I don't really think it's sane for the RISC-V tree because it 
>> touches so many architectures -- I haven't looked closely, though.
>
> Yeah, I think that makes sense.
>
>> IIRC 
>> there's a slight behavior change to the RISC-V port, which I'd be OK taking 
>> through my tree (and then obviously the RISC-V cleanup as well, unless it 
>> goes 
>> in as a whole patch set).
>>
>
> So currently the behavior for RISC-V is changed by simply deleting the
> arch-specific free_initrd_mem, which was a noop. Would you like me to
> first submit a patch to have the arch-specific free_initrd_mem and then
> change that in this series?
>
>>
>> For the IRQ cleanup I currently have in flight
>>
>> * Add the generic support
>> * Move every arch over (RISC-V is in, the rest aren't yet)
>> * Clean up a bit now that everyone is generic
>>
>> That lets all the arch-specific patches go in parallel, but can be a bit of 
>> a 
>> headache to manage.
>
> With the current series, the first patch could go in on its own and all
> of the arch-specific patches can go in in parallel if we wanted to, but
> beyond the above-suggested implementation of the RISC-V free_initrd_mem
> there's no real reordering meaningful here.
>
>>
>> I'm adding Arnd and Olof, as they know a lot more about Linux than I do.  
>> Here's the top-level of the v4 patch set: https://lkml.org/lkml/2018/3/28/744
>
> And here's the top-level of v6, the latest: https://lkml.org/lkml/2018/4/1/50

What's the right next step here?

Thanks,
Shea


signature.asc
Description: PGP signature

Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Shea Levy]

Hi all,

Shea Levy  writes:

> Hi Palmer,
>
> Palmer Dabbelt  writes:
>
>> On Wed, 18 Apr 2018 04:10:16 PDT (-0700), s...@shealevy.com wrote:
>>> Hi all,
>>>
>>> Shea Levy  writes:
>>>
 This function is effectively identical across 14 architectures, and
 the generic implementation is small enough to be negligible in the
 architectures that do override it. Many of the remaining divergent
 implementations can be included in the common code path in future,
 further reducing code duplication and sharing improvements between
 architectures.

 Series boot-tested on RISC-V (which now uses the generic
 implementation) and x86_64 (which doesn't).

 v6: Add information about build/run testing.
 v5: Add more complete commit messages.
 v4: Use weak symbols instead of Kconfig.
 v3: Make the generic path opt-out instead of opt-in.
 v2: Mark generic free_initrd_mem __init.

 Signed-off-by: Shea Levy 
 ---
  init/initramfs.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/init/initramfs.c b/init/initramfs.c
 index 7e99a0038942..c8fe150f958a 100644
 --- a/init/initramfs.c
 +++ b/init/initramfs.c
 @@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
  #include 
  #include 
  
 +void __init __weak free_initrd_mem(unsigned long start, unsigned long end)
 +{
 +   free_reserved_area((void *)start, (void *)end, -1, "initrd");
 +}
 +
  static void __init free_initrd(void)
  {
  #ifdef CONFIG_KEXEC_CORE
 -- 
 2.16.2
>>>
>>> This series has been quiet for a few weeks other than picking up some
>>> arch-specific acks. What is the next step here?
>>
>> I'm not sure.  I don't really think it's sane for the RISC-V tree because it 
>> touches so many architectures -- I haven't looked closely, though.
>
> Yeah, I think that makes sense.
>
>> IIRC 
>> there's a slight behavior change to the RISC-V port, which I'd be OK taking 
>> through my tree (and then obviously the RISC-V cleanup as well, unless it 
>> goes 
>> in as a whole patch set).
>>
>
> So currently the behavior for RISC-V is changed by simply deleting the
> arch-specific free_initrd_mem, which was a noop. Would you like me to
> first submit a patch to have the arch-specific free_initrd_mem and then
> change that in this series?
>
>>
>> For the IRQ cleanup I currently have in flight
>>
>> * Add the generic support
>> * Move every arch over (RISC-V is in, the rest aren't yet)
>> * Clean up a bit now that everyone is generic
>>
>> That lets all the arch-specific patches go in parallel, but can be a bit of 
>> a 
>> headache to manage.
>
> With the current series, the first patch could go in on its own and all
> of the arch-specific patches can go in in parallel if we wanted to, but
> beyond the above-suggested implementation of the RISC-V free_initrd_mem
> there's no real reordering meaningful here.
>
>>
>> I'm adding Arnd and Olof, as they know a lot more about Linux than I do.  
>> Here's the top-level of the v4 patch set: https://lkml.org/lkml/2018/3/28/744
>
> And here's the top-level of v6, the latest: https://lkml.org/lkml/2018/4/1/50

What's the right next step here?

Thanks,
Shea


signature.asc
Description: PGP signature

Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Shea Levy]

Hi Palmer,

Palmer Dabbelt  writes:

> On Wed, 18 Apr 2018 04:10:16 PDT (-0700), s...@shealevy.com wrote:
>> Hi all,
>>
>> Shea Levy  writes:
>>
>>> This function is effectively identical across 14 architectures, and
>>> the generic implementation is small enough to be negligible in the
>>> architectures that do override it. Many of the remaining divergent
>>> implementations can be included in the common code path in future,
>>> further reducing code duplication and sharing improvements between
>>> architectures.
>>>
>>> Series boot-tested on RISC-V (which now uses the generic
>>> implementation) and x86_64 (which doesn't).
>>>
>>> v6: Add information about build/run testing.
>>> v5: Add more complete commit messages.
>>> v4: Use weak symbols instead of Kconfig.
>>> v3: Make the generic path opt-out instead of opt-in.
>>> v2: Mark generic free_initrd_mem __init.
>>>
>>> Signed-off-by: Shea Levy 
>>> ---
>>>  init/initramfs.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/init/initramfs.c b/init/initramfs.c
>>> index 7e99a0038942..c8fe150f958a 100644
>>> --- a/init/initramfs.c
>>> +++ b/init/initramfs.c
>>> @@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
>>>  #include 
>>>  #include 
>>>  
>>> +void __init __weak free_initrd_mem(unsigned long start, unsigned long end)
>>> +{
>>> +   free_reserved_area((void *)start, (void *)end, -1, "initrd");
>>> +}
>>> +
>>>  static void __init free_initrd(void)
>>>  {
>>>  #ifdef CONFIG_KEXEC_CORE
>>> -- 
>>> 2.16.2
>>
>> This series has been quiet for a few weeks other than picking up some
>> arch-specific acks. What is the next step here?
>
> I'm not sure.  I don't really think it's sane for the RISC-V tree because it 
> touches so many architectures -- I haven't looked closely, though.

Yeah, I think that makes sense.

> IIRC 
> there's a slight behavior change to the RISC-V port, which I'd be OK taking 
> through my tree (and then obviously the RISC-V cleanup as well, unless it 
> goes 
> in as a whole patch set).
>

So currently the behavior for RISC-V is changed by simply deleting the
arch-specific free_initrd_mem, which was a noop. Would you like me to
first submit a patch to have the arch-specific free_initrd_mem and then
change that in this series?

>
> For the IRQ cleanup I currently have in flight
>
> * Add the generic support
> * Move every arch over (RISC-V is in, the rest aren't yet)
> * Clean up a bit now that everyone is generic
>
> That lets all the arch-specific patches go in parallel, but can be a bit of a 
> headache to manage.

With the current series, the first patch could go in on its own and all
of the arch-specific patches can go in in parallel if we wanted to, but
beyond the above-suggested implementation of the RISC-V free_initrd_mem
there's no real reordering meaningful here.

>
> I'm adding Arnd and Olof, as they know a lot more about Linux than I do.  
> Here's the top-level of the v4 patch set: https://lkml.org/lkml/2018/3/28/744

And here's the top-level of v6, the latest: https://lkml.org/lkml/2018/4/1/50


signature.asc
Description: PGP signature

Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Shea Levy]

Hi Palmer,

Palmer Dabbelt  writes:

> On Wed, 18 Apr 2018 04:10:16 PDT (-0700), s...@shealevy.com wrote:
>> Hi all,
>>
>> Shea Levy  writes:
>>
>>> This function is effectively identical across 14 architectures, and
>>> the generic implementation is small enough to be negligible in the
>>> architectures that do override it. Many of the remaining divergent
>>> implementations can be included in the common code path in future,
>>> further reducing code duplication and sharing improvements between
>>> architectures.
>>>
>>> Series boot-tested on RISC-V (which now uses the generic
>>> implementation) and x86_64 (which doesn't).
>>>
>>> v6: Add information about build/run testing.
>>> v5: Add more complete commit messages.
>>> v4: Use weak symbols instead of Kconfig.
>>> v3: Make the generic path opt-out instead of opt-in.
>>> v2: Mark generic free_initrd_mem __init.
>>>
>>> Signed-off-by: Shea Levy 
>>> ---
>>>  init/initramfs.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/init/initramfs.c b/init/initramfs.c
>>> index 7e99a0038942..c8fe150f958a 100644
>>> --- a/init/initramfs.c
>>> +++ b/init/initramfs.c
>>> @@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
>>>  #include 
>>>  #include 
>>>  
>>> +void __init __weak free_initrd_mem(unsigned long start, unsigned long end)
>>> +{
>>> +   free_reserved_area((void *)start, (void *)end, -1, "initrd");
>>> +}
>>> +
>>>  static void __init free_initrd(void)
>>>  {
>>>  #ifdef CONFIG_KEXEC_CORE
>>> -- 
>>> 2.16.2
>>
>> This series has been quiet for a few weeks other than picking up some
>> arch-specific acks. What is the next step here?
>
> I'm not sure.  I don't really think it's sane for the RISC-V tree because it 
> touches so many architectures -- I haven't looked closely, though.

Yeah, I think that makes sense.

> IIRC 
> there's a slight behavior change to the RISC-V port, which I'd be OK taking 
> through my tree (and then obviously the RISC-V cleanup as well, unless it 
> goes 
> in as a whole patch set).
>

So currently the behavior for RISC-V is changed by simply deleting the
arch-specific free_initrd_mem, which was a noop. Would you like me to
first submit a patch to have the arch-specific free_initrd_mem and then
change that in this series?

>
> For the IRQ cleanup I currently have in flight
>
> * Add the generic support
> * Move every arch over (RISC-V is in, the rest aren't yet)
> * Clean up a bit now that everyone is generic
>
> That lets all the arch-specific patches go in parallel, but can be a bit of a 
> headache to manage.

With the current series, the first patch could go in on its own and all
of the arch-specific patches can go in in parallel if we wanted to, but
beyond the above-suggested implementation of the RISC-V free_initrd_mem
there's no real reordering meaningful here.

>
> I'm adding Arnd and Olof, as they know a lot more about Linux than I do.  
> Here's the top-level of the v4 patch set: https://lkml.org/lkml/2018/3/28/744

And here's the top-level of v6, the latest: https://lkml.org/lkml/2018/4/1/50


signature.asc
Description: PGP signature

Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Palmer Dabbelt]

On Wed, 18 Apr 2018 04:10:16 PDT (-0700), s...@shealevy.com wrote:

Hi all,

Shea Levy  writes:


This function is effectively identical across 14 architectures, and
the generic implementation is small enough to be negligible in the
architectures that do override it. Many of the remaining divergent
implementations can be included in the common code path in future,
further reducing code duplication and sharing improvements between
architectures.

Series boot-tested on RISC-V (which now uses the generic
implementation) and x86_64 (which doesn't).

v6: Add information about build/run testing.
v5: Add more complete commit messages.
v4: Use weak symbols instead of Kconfig.
v3: Make the generic path opt-out instead of opt-in.
v2: Mark generic free_initrd_mem __init.

Signed-off-by: Shea Levy 
---
 init/initramfs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/init/initramfs.c b/init/initramfs.c
index 7e99a0038942..c8fe150f958a 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
 #include 
 #include 
 
+void __init __weak free_initrd_mem(unsigned long start, unsigned long end)

+{
+   free_reserved_area((void *)start, (void *)end, -1, "initrd");
+}
+
 static void __init free_initrd(void)
 {
 #ifdef CONFIG_KEXEC_CORE
--
2.16.2


This series has been quiet for a few weeks other than picking up some
arch-specific acks. What is the next step here?


I'm not sure.  I don't really think it's sane for the RISC-V tree because it 
touches so many architectures -- I haven't looked closely, though.  IIRC 
there's a slight behavior change to the RISC-V port, which I'd be OK taking 
through my tree (and then obviously the RISC-V cleanup as well, unless it goes 
in as a whole patch set).


For the IRQ cleanup I currently have in flight

* Add the generic support
* Move every arch over (RISC-V is in, the rest aren't yet)
* Clean up a bit now that everyone is generic

That lets all the arch-specific patches go in parallel, but can be a bit of a 
headache to manage.


I'm adding Arnd and Olof, as they know a lot more about Linux than I do.  
Here's the top-level of the v4 patch set: https://lkml.org/lkml/2018/3/28/744

Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Palmer Dabbelt]

On Wed, 18 Apr 2018 04:10:16 PDT (-0700), s...@shealevy.com wrote:

Hi all,

Shea Levy  writes:


This function is effectively identical across 14 architectures, and
the generic implementation is small enough to be negligible in the
architectures that do override it. Many of the remaining divergent
implementations can be included in the common code path in future,
further reducing code duplication and sharing improvements between
architectures.

Series boot-tested on RISC-V (which now uses the generic
implementation) and x86_64 (which doesn't).

v6: Add information about build/run testing.
v5: Add more complete commit messages.
v4: Use weak symbols instead of Kconfig.
v3: Make the generic path opt-out instead of opt-in.
v2: Mark generic free_initrd_mem __init.

Signed-off-by: Shea Levy 
---
 init/initramfs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/init/initramfs.c b/init/initramfs.c
index 7e99a0038942..c8fe150f958a 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
 #include 
 #include 
 
+void __init __weak free_initrd_mem(unsigned long start, unsigned long end)

+{
+   free_reserved_area((void *)start, (void *)end, -1, "initrd");
+}
+
 static void __init free_initrd(void)
 {
 #ifdef CONFIG_KEXEC_CORE
--
2.16.2


This series has been quiet for a few weeks other than picking up some
arch-specific acks. What is the next step here?


I'm not sure.  I don't really think it's sane for the RISC-V tree because it 
touches so many architectures -- I haven't looked closely, though.  IIRC 
there's a slight behavior change to the RISC-V port, which I'd be OK taking 
through my tree (and then obviously the RISC-V cleanup as well, unless it goes 
in as a whole patch set).


For the IRQ cleanup I currently have in flight

* Add the generic support
* Move every arch over (RISC-V is in, the rest aren't yet)
* Clean up a bit now that everyone is generic

That lets all the arch-specific patches go in parallel, but can be a bit of a 
headache to manage.


I'm adding Arnd and Olof, as they know a lot more about Linux than I do.  
Here's the top-level of the v4 patch set: https://lkml.org/lkml/2018/3/28/744

Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Shea Levy]

Hi all,

Shea Levy  writes:

> This function is effectively identical across 14 architectures, and
> the generic implementation is small enough to be negligible in the
> architectures that do override it. Many of the remaining divergent
> implementations can be included in the common code path in future,
> further reducing code duplication and sharing improvements between
> architectures.
>
> Series boot-tested on RISC-V (which now uses the generic
> implementation) and x86_64 (which doesn't).
>
> v6: Add information about build/run testing.
> v5: Add more complete commit messages.
> v4: Use weak symbols instead of Kconfig.
> v3: Make the generic path opt-out instead of opt-in.
> v2: Mark generic free_initrd_mem __init.
>
> Signed-off-by: Shea Levy 
> ---
>  init/initramfs.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/init/initramfs.c b/init/initramfs.c
> index 7e99a0038942..c8fe150f958a 100644
> --- a/init/initramfs.c
> +++ b/init/initramfs.c
> @@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
>  #include 
>  #include 
>  
> +void __init __weak free_initrd_mem(unsigned long start, unsigned long end)
> +{
> +   free_reserved_area((void *)start, (void *)end, -1, "initrd");
> +}
> +
>  static void __init free_initrd(void)
>  {
>  #ifdef CONFIG_KEXEC_CORE
> -- 
> 2.16.2

This series has been quiet for a few weeks other than picking up some
arch-specific acks. What is the next step here?

Thanks,
Shea


signature.asc
Description: PGP signature

Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Shea Levy]

Hi all,

Shea Levy  writes:

> This function is effectively identical across 14 architectures, and
> the generic implementation is small enough to be negligible in the
> architectures that do override it. Many of the remaining divergent
> implementations can be included in the common code path in future,
> further reducing code duplication and sharing improvements between
> architectures.
>
> Series boot-tested on RISC-V (which now uses the generic
> implementation) and x86_64 (which doesn't).
>
> v6: Add information about build/run testing.
> v5: Add more complete commit messages.
> v4: Use weak symbols instead of Kconfig.
> v3: Make the generic path opt-out instead of opt-in.
> v2: Mark generic free_initrd_mem __init.
>
> Signed-off-by: Shea Levy 
> ---
>  init/initramfs.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/init/initramfs.c b/init/initramfs.c
> index 7e99a0038942..c8fe150f958a 100644
> --- a/init/initramfs.c
> +++ b/init/initramfs.c
> @@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
>  #include 
>  #include 
>  
> +void __init __weak free_initrd_mem(unsigned long start, unsigned long end)
> +{
> +   free_reserved_area((void *)start, (void *)end, -1, "initrd");
> +}
> +
>  static void __init free_initrd(void)
>  {
>  #ifdef CONFIG_KEXEC_CORE
> -- 
> 2.16.2

This series has been quiet for a few weeks other than picking up some
arch-specific acks. What is the next step here?

Thanks,
Shea


signature.asc
Description: PGP signature

[PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Shea Levy]

This function is effectively identical across 14 architectures, and
the generic implementation is small enough to be negligible in the
architectures that do override it. Many of the remaining divergent
implementations can be included in the common code path in future,
further reducing code duplication and sharing improvements between
architectures.

Series boot-tested on RISC-V (which now uses the generic
implementation) and x86_64 (which doesn't).

v6: Add information about build/run testing.
v5: Add more complete commit messages.
v4: Use weak symbols instead of Kconfig.
v3: Make the generic path opt-out instead of opt-in.
v2: Mark generic free_initrd_mem __init.

Signed-off-by: Shea Levy 
---
 init/initramfs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/init/initramfs.c b/init/initramfs.c
index 7e99a0038942..c8fe150f958a 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
 #include 
 #include 
 
+void __init __weak free_initrd_mem(unsigned long start, unsigned long end)
+{
+   free_reserved_area((void *)start, (void *)end, -1, "initrd");
+}
+
 static void __init free_initrd(void)
 {
 #ifdef CONFIG_KEXEC_CORE
-- 
2.16.2

[PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Shea Levy]

This function is effectively identical across 14 architectures, and
the generic implementation is small enough to be negligible in the
architectures that do override it. Many of the remaining divergent
implementations can be included in the common code path in future,
further reducing code duplication and sharing improvements between
architectures.

Series boot-tested on RISC-V (which now uses the generic
implementation) and x86_64 (which doesn't).

v6: Add information about build/run testing.
v5: Add more complete commit messages.
v4: Use weak symbols instead of Kconfig.
v3: Make the generic path opt-out instead of opt-in.
v2: Mark generic free_initrd_mem __init.

Signed-off-by: Shea Levy 
---
 init/initramfs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/init/initramfs.c b/init/initramfs.c
index 7e99a0038942..c8fe150f958a 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
 #include 
 #include 
 
+void __init __weak free_initrd_mem(unsigned long start, unsigned long end)
+{
+   free_reserved_area((void *)start, (void *)end, -1, "initrd");
+}
+
 static void __init free_initrd(void)
 {
 #ifdef CONFIG_KEXEC_CORE
-- 
2.16.2