Re: [PATCH 4.14 1/4] powerpc/mm/slice: Remove intermediate bitmap copy

2018-03-10 Thread Greg Kroah-Hartman
On Sat, Mar 10, 2018 at 08:27:54AM +0100, christophe leroy wrote:
> 
> 
> Le 10/03/2018 à 01:10, Greg Kroah-Hartman a écrit :
> > On Fri, Mar 09, 2018 at 04:48:59PM +0100, Christophe Leroy wrote:
> > > Upstream 326691ad4f179e6edc7eb1271e618dd673e4736d
> > 
> > There is no such git commit id in Linus's tree :(
> > 
> > Please fix up and resend the series.
> 
> I checked again, it is there
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/powerpc/mm/slice.c?h=next-20180309=326691ad4f179e6edc7eb1271e618dd673e4736d

That is linux-next, which has everything and the kitchen sink.  It is
not Linus's tree.  Please wait for these things to be merged into
Linus's tree before asking for the to be merged into the stable tree.
That's a requirement.

thanks,

greg k-h


Re: [PATCH 4.14 1/4] powerpc/mm/slice: Remove intermediate bitmap copy

2018-03-10 Thread christophe leroy



Le 10/03/2018 à 15:52, Greg Kroah-Hartman a écrit :

On Sat, Mar 10, 2018 at 08:27:54AM +0100, christophe leroy wrote:



Le 10/03/2018 à 01:10, Greg Kroah-Hartman a écrit :

On Fri, Mar 09, 2018 at 04:48:59PM +0100, Christophe Leroy wrote:

Upstream 326691ad4f179e6edc7eb1271e618dd673e4736d


There is no such git commit id in Linus's tree :(

Please fix up and resend the series.


I checked again, it is there

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/powerpc/mm/slice.c?h=next-20180309=326691ad4f179e6edc7eb1271e618dd673e4736d


That is linux-next, which has everything and the kitchen sink.  It is
not Linus's tree.  Please wait for these things to be merged into
Linus's tree before asking for the to be merged into the stable tree.
That's a requirement.



Oops, sorry, I thought everything on kernel.org was official.

Once it is in, do I resend the patches or do I just ping you ?

Thanks
Christophe

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus



Re: [PATCH 4.14 1/4] powerpc/mm/slice: Remove intermediate bitmap copy

2018-03-10 Thread Greg Kroah-Hartman
On Sat, Mar 10, 2018 at 05:14:22PM +0100, christophe leroy wrote:
> 
> 
> Le 10/03/2018 à 15:52, Greg Kroah-Hartman a écrit :
> > On Sat, Mar 10, 2018 at 08:27:54AM +0100, christophe leroy wrote:
> > > 
> > > 
> > > Le 10/03/2018 à 01:10, Greg Kroah-Hartman a écrit :
> > > > On Fri, Mar 09, 2018 at 04:48:59PM +0100, Christophe Leroy wrote:
> > > > > Upstream 326691ad4f179e6edc7eb1271e618dd673e4736d
> > > > 
> > > > There is no such git commit id in Linus's tree :(
> > > > 
> > > > Please fix up and resend the series.
> > > 
> > > I checked again, it is there
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/powerpc/mm/slice.c?h=next-20180309=326691ad4f179e6edc7eb1271e618dd673e4736d
> > 
> > That is linux-next, which has everything and the kitchen sink.  It is
> > not Linus's tree.  Please wait for these things to be merged into
> > Linus's tree before asking for the to be merged into the stable tree.
> > That's a requirement.
> > 
> 
> Oops, sorry, I thought everything on kernel.org was official.

That would be a whole lot of "official" :)

Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for what the rules are here, if you haven't already.

> Once it is in, do I resend the patches or do I just ping you ?

You would need to resend the patches (if they need backporting
manually), or just send a list of the git commit ids that are needed to
be applied (usually easier.)

Also, why were these patches not tagged with the stable tag to start
with?  That way they would be automatically included in the stable tree
when they hit Linus's tree.

thanks,

greg k-h


Re: [PATCH 03/21] powerpc: Mark the variable earlycon_acpi_spcr_enable maybe_unused

2018-03-10 Thread Mathieu Malaterre
On Sun, Mar 4, 2018 at 11:54 AM, Michael Ellerman  wrote:
> Mathieu Malaterre  writes:
>
>> Re-use the object-like macro EARLYCON_USED_OR_UNUSED to mark
>> `earlycon_acpi_spcr_enable` as maybe_unused.
>>
>> Fix the following warning (treated as error in W=1)
>>
>>   CC  arch/powerpc/kernel/setup-common.o
>> In file included from ./include/linux/serial_8250.h:14:0,
>>  from arch/powerpc/kernel/setup-common.c:33:
>> ./include/linux/serial_core.h:382:19: error: ‘earlycon_acpi_spcr_enable’ 
>> defined but not used [-Werror=unused-const-variable=]
>>  static const bool earlycon_acpi_spcr_enable;
>>^
>> cc1: all warnings being treated as errors
>>
>> Signed-off-by: Mathieu Malaterre 
>> ---
>>  include/linux/serial_core.h | 1 +
>
> I can't take this one as that's not a file I maintain.
>
> The script says:
>
>   $ ./scripts/get_maintainer.pl include/linux/serial_core.h
>   gre...@linuxfoundation.org
>   jsl...@suse.com
>   linux-ker...@vger.kernel.org
>
>
> Can you resend it to them?

Ah right, thanks.
>
>> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
>> index b32df49a3bd5..4d14ecd7dbe8 100644
>> --- a/include/linux/serial_core.h
>> +++ b/include/linux/serial_core.h
>> @@ -379,6 +379,7 @@ extern int of_setup_earlycon(const struct earlycon_id 
>> *match,
>>  extern bool earlycon_acpi_spcr_enable __initdata;
>>  int setup_earlycon(char *buf);
>>  #else
>> +EARLYCON_USED_OR_UNUSED
>>  static const bool earlycon_acpi_spcr_enable;
>
> The macro eventually turns into an __attribute__, which I think is
> typically placed after the variable, so eg:
>
>   static const bool earlycon_acpi_spcr_enable EARLYCON_USED_OR_UNUSED;
>

Indeed makes it more consistent with style.  Thanks!

> cheers
>
>>  static inline int setup_earlycon(char *buf) { return 0; }
>>  #endif
>> --
>> 2.11.0


Re: [PATCH] powerpc/mm: Fix section mismatch warning in stop_machine_change_mapping()

2018-03-10 Thread Balbir Singh
On Sat, Mar 10, 2018 at 7:45 AM, Mauricio Faria de Oliveira
 wrote:
> Fix the warning messages for stop_machine_change_mapping(), and a number
> of other affected functions in its call chain.
>
> All modified functions are under CONFIG_MEMORY_HOTPLUG, so __meminit
> is okay (keeps them / does not discard them).
>
> Boot-tested on powernv/power9/radix-mmu and pseries/power8/hash-mmu.
>
> $ make -j$(nproc) CONFIG_DEBUG_SECTION_MISMATCH=y vmlinux
> ...
>   MODPOST vmlinux.o
> WARNING: vmlinux.o(.text+0x6b130): Section mismatch in reference from the 
> function stop_machine_change_mapping() to the function 
> .meminit.text:create_physical_mapping()
> The function stop_machine_change_mapping() references
> the function __meminit create_physical_mapping().
> This is often because stop_machine_change_mapping lacks a __meminit
> annotation or the annotation of create_physical_mapping is wrong.
>
> WARNING: vmlinux.o(.text+0x6b13c): Section mismatch in reference from the 
> function stop_machine_change_mapping() to the function 
> .meminit.text:create_physical_mapping()
> The function stop_machine_change_mapping() references
> the function __meminit create_physical_mapping().
> This is often because stop_machine_change_mapping lacks a __meminit
> annotation or the annotation of create_physical_mapping is wrong.
> ...
>
> Signed-off-by: Mauricio Faria de Oliveira 
> ---

Looks reasonable, I'd recommend trying to compile with MEMORY_HOTPLUG
and MEMORY_HOTREMOVE enabled/disabled as well

Acked-by: Balbir Singh 

Balbir Singh.