date:20230302

Re: [PATCH 1/1] mm/nommu: remove unnecessary VMA locking

2023-03-02 Thread Suren Baghdasaryan

On Thu, Mar 2, 2023 at 1:41 AM David Hildenbrand  wrote:
>
> On 01.03.23 20:04, Suren Baghdasaryan wrote:
> > Since CONFIG_PER_VMA_LOCK depends on CONFIG_MMU, the changes in nommu
> > are not needed. Remove them.
> >
> > Fixes: bad94decd6a4 ("mm: write-lock VMAs before removing them from VMA 
> > tree")
> > Reported-by: Hyeonggon Yoo <42.hye...@gmail.com>
> > Link: https://lore.kernel.org/all/Y%2F8CJQGNuMUTdLwP@localhost/
> > Signed-off-by: Suren Baghdasaryan 
> > ---
> > Fix cleanly applies over mm-unstable, SHA in "Fixes" is from that tree.
> >
> >   mm/nommu.c | 5 -
> >   1 file changed, 5 deletions(-)
> >
> > diff --git a/mm/nommu.c b/mm/nommu.c
> > index 2ab162d773e2..57ba243c6a37 100644
> > --- a/mm/nommu.c
> > +++ b/mm/nommu.c
> > @@ -588,7 +588,6 @@ static int delete_vma_from_mm(struct vm_area_struct 
> > *vma)
> >  current->pid);
> >   return -ENOMEM;
> >   }
> > - vma_start_write(vma);
> >   cleanup_vma_from_mm(vma);
> >
> >   /* remove from the MM's tree and list */
> > @@ -1520,10 +1519,6 @@ void exit_mmap(struct mm_struct *mm)
> >*/
> >   mmap_write_lock(mm);
> >   for_each_vma(vmi, vma) {
> > - /*
> > -  * No need to lock VMA because this is the only mm user and no
> > -  * page fault handled can race with it.
> > -  */
> >   cleanup_vma_from_mm(vma);
> >   delete_vma(mm, vma);
> >   cond_resched();
>
> So, i assume this should be squashed.

Yes, that would be best.

>
> Reviewed-by: David Hildenbrand 

Thanks1

>
>
> Just a general comment: usually, if review of the original series is
> still going on, it makes a lot more sense to raise such things in the
> original series so the author can fixup while things are still in
> mm-unstable. Once the series is in mm-stable, it's a different story. In
> that case, it is usually good to have the mail subjects be something
> like  "[PATCH mm-stable 1/1] ...".

Ok... For my education, do you mean the title of this patch should
somehow reflect that it should be folded into the original patch? Just
trying to understand the actionable item here. How would you change
this patch when posting for mm-unstable and for mm-stable?
Thanks,
Suren.

>
> --
> Thanks,
>
> David / dhildenb
>

Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms

2023-03-02 Thread Paul Gortmaker

[Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On 
01/03/2023 (Wed 14:23) Christophe Leroy wrote:

> 
> 
> Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??:
> > On Tue, Feb 28, 2023, at 11:03, Joakim Tjernlund wrote:
> >> On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote:
> >>
> >> Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the
> >> MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel.
> >>
> >> There will still exist several e300 Freescale Reference Design System 
> >> (RDS)
> >> boards[5] and mini-ITX boards[6] with support in the kernel.  While 
> >> these
> >> were more of a COTS "ready to deploy" design more suited to hobbyists, 
> >> it
> >> probably makes sense to consider removing these as well, based on age.
> >
> > These boards are mass market boards that sold in larger amount and are 
> > much more likely to still be used.  We would suggest we keep them for 
> > now.
> >>
> >> Agreed, the RDS design is still used here.
> > 
> > Can you elaborate what the typical kernel upgrade schedule for
> > these boards?
> > 
> > Note that for the debate about dropping the machines from future
> > kernels, it does not really matter how many remaining users there
> > are or how many boards get sold. The only question is whether
> > someone is still planning to provide upgrades to kernels later
> > than linux-6.3 in the future.
> > 
> > It sounds like there are commercial requirements for validating
> > and distributing kernel upgrades (in addition to hobbyist uses), so
> > I would expect that whoever is paying for the upgrades has a clear
> > plan for how much longer they are going to do that, or at least
> > a some idea of how many of the previous LTS kernels (5.10, 5.15,
> > 6.1) ended up actually getting shipped to users.
> > 
> > It may be worth pointing out that the official webpage for
> > the MPC8313ERDB board in the example only lists a hilariously
> > outdated BSP kernel based on a patched linux-2.6.23 release,
> > so maybe the marketing team can change that to point to the
> > latest validated LTS kernel instead.
> 
> Let me present things in a slightly different way.
> 
> My company has designed and manufactured and sold communication systems 
> embedding three types of boards:
> - First generation, with MPC 866, designed around 2002.
> - Second generation, with MPC 885, designed around 2010.
> - Third generation, with MPC 8321, designed around 2014.
> 
> When NXP announced end of life of MPC 866 and 885, we bought enough CPUs 
> to be able to produce boards for the 10 following years so we still 
> produce some.
> 
> MPC 8321 is still in production.
> 
> All those boards are used in critical systems where we have a customer 
> requirement to keep all software including U-boot and Linux kernel up to 
> date, for IT security reason mainly.

Firstly, thank you for the detailed reply - I totally appreciate how
framing things with this detail was not without effort on your part.

And your reasons for updating u-boot and the kernel are also valid.

> Until now, the boards were delivered with kernel 4.14, with is due to 
> EOL early next year.
> At the moment we are working on upgrading to mainline kernel with the 
> target being to be able to upgrade our customers to next LTS kernel at 
> the begining of 2024.
> 
> Note that because our kernel code is prehistoric, it is not mergeable to 
> mainline. Not because of licence issues but because the code is just not 
> following at all linux standard. So our boards are not in mainline. Two 
> of them are in U-boot and the third one should soon be as well.
> 
> So, to come back about the RDB boards, we have a couple of MPC 885 ADS 
> and a couple of MPC 8321 RDB. They are reference boards and we always 
> check that a given kernel version properly runs on them before starting 
> to port it to our hardware.

Just as a reminder - I only mentioned RDB "for consideration".  None of
the RDB platforms were removed in this series.  I don't want people to
inadvertently conflate the two.

> Hope it clarifies how those reference boards are used.

It was really useful input and gave an insight into how things get used.

But let me put a slightly different slant on things.  If there is no
maintainer for the platform/architecture/CPU, then where is the
obligation for mainline to keep it up to date just for your company to
use the code/BSP as a reference?

Do they continue to do this for one more year, or three or ...  ???
Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ?

Let us put that aside for now.  I've worked with linux-next for decade+
and have a pretty good idea how all that "upstream stuff" works.

If you have custom out-of-tree BSP and are interested in how upstream
changes impact it, you should have nightly builds pulling down
linux-next and applying your changes and finding when things break.

If you see change 0123abcdef breaks

Re: [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config fragments.

2023-03-02 Thread Paul Gortmaker

[Re: [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config fragments.] On 
02/03/2023 (Thu 17:30) Crystal Wood wrote:

> On Tue, 2023-02-21 at 22:49 +0100, Pali Roh??r wrote:
> > On Tuesday 21 February 2023 16:29:32 Paul Gortmaker wrote:
> > > [Re: [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config
> > > fragments.] On 21/02/2023 (Tue 21:03) Pali Roh??r wrote:
> > > 
> > > > On Tuesday 21 February 2023 14:46:37 Paul Gortmaker wrote:
> > > > > None of these have a reference anymore anywhere, such as like this:
> > > > > 
> > > > > ?? arch/powerpc/Makefile:?? $(call
> > > > > merge_into_defconfig,mpc85xx_base.config,\
> > > > > 
> > > > > As such, we probably should just clean up and remove them.
> > > > > 
> > > > > Cc: Scott Wood 
> > > > > Cc: Michael Ellerman 
> > > > > Cc: Benjamin Herrenschmidt 
> > > > > Cc: Paul Mackerras 
> > > > > Signed-off-by: Paul Gortmaker 
> > > > > ---
> > > > > ??arch/powerpc/configs/85xx-32bit.config | 5 -
> > > > > ??arch/powerpc/configs/85xx-hw.config?? | 139 
> > > > > 
> > > > > -
> > > > > ??arch/powerpc/configs/85xx-smp.config | 2 -
> > > > > ??3 files changed, 146 deletions(-)
> > > > > ??delete mode 100644 arch/powerpc/configs/85xx-32bit.config
> > > > > ??delete mode 100644 arch/powerpc/configs/85xx-hw.config
> > > > > ??delete mode 100644 arch/powerpc/configs/85xx-smp.config
> > > > 
> > > > This change is likely going to break mpc85xx platform because defconfig
> > > > files includes all these files which you are going to remove. For
> > > > example in arch/powerpc/Makefile is:
> > > > 
> > > > PHONY += mpc85xx_smp_defconfig
> > > > mpc85xx_smp_defconfig:
> > > > $(call merge_into_defconfig,mpc85xx_base.config,\
> > > > 85xx-32bit 85xx-smp 85xx-hw 
> > > > fsl-emb-nonhw)
> > > 
> > > OK, it seems you've answered a question for me.?? That being "why didn't
> > > grep find a reference to these fragments?"
> > > 
> > > It seems the ".config" extension is optional?
> > 
> > I really do not know. (And I'm not sure if I want to know answer :D)
> 
> It's not optional; you have to leave it off:
> 
> # Used to create 'merged defconfigs'
> # To use it $(call) it with the first argument as the base defconfig
> # and the second argument as a space separated list of .config files to merge,
> # without the .config suffix.
> define merge_into_defconfig
> ...
> 
> > > This seems inconsistent at best, to reference some files with the
> > > .config extension and others without it.?? Not blaming you for that,
> > > but it is probably something that needs looking into.
> > 
> > I agree it is inconsistent. But it was there before I looked or touched
> > any powerpc code. So it looks like something which nobody wanted to
> > cleanup because "it works" and had no motivation.
> 
> No, it's intentional to reduce verbosity.  If by "inconsistent" you're
> referring to mpc85xx_base.config, that argument sometimes refers to _defconfig
> files (i.e. the pseries targets which were the initial user of
> merge_into_config) so that argument can't autoappend .config.

Thanks for the detailed explanation.  As I believe I said elsewhere, I
wouldn't be submitting this change once I understood the use case.  Plus
it wasn't significant in reducing our overall maintain/build/boot kernel
overhead in v6.4+ in linux-next etc.  --- as that was the real goal here.

I deleted our various BSPs years ago because I didn't think it was fair
or reasonable to expect other people to update/carry them on our behalf.

I would hope that is a statement that everyone could get behind.

Thanks,
Paul.
--

> 
> -Crystal
>

Re: [PATCH v2 5/5] of: address: Always use dma_default_coherent for default coherency

2023-03-02 Thread Michael Ellerman

Jiaxun Yang  writes:
>> 2023年3月1日 13:06，Christoph Hellwig  写道：
>> 
>>> - select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE
>> 
>> Doesn't powerpc need to select CONFIG_ARCH_DMA_DEFAULT_COHERENT now,
>> or even better should be doing that in the patch adding that
>> symbol?
>
> If I read the code correctly for powerpc OF_DMA_DEFAULT_COHERENT is only 
> selected
> with !NOT_COHERENT_CACHE, which means non-coherent dma support is disabled….

I think you're right, but it's not easy to understand.

powerpc's NOT_COHERENT_CACHE selects:

  select ARCH_HAS_DMA_PREP_COHERENT
  select ARCH_HAS_SYNC_DMA_FOR_DEVICE
  select ARCH_HAS_SYNC_DMA_FOR_CPU


Then in your patch 3 you do:

 #if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
-bool dma_default_coherent;
+bool dma_default_coherent = IS_ENABLED(CONFIG_ARCH_DMA_DEFAULT_COHERENT);
 #endif

So for powerpc if NOT_COHERENT_CACHE=n, then none of those ARCH_HAS
symbols are defined, and so CONFIG_ARCH_DMA_DEFAULT_COHERENT is never used.

But like I said it's not very obvious, and it also seems fragile to
future changes.

So it seems it would be more future proof, and self documenting for
powerpc to just have:

select ARCH_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE


cheers

Re: [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config fragments.

2023-03-02 Thread Crystal Wood

On Tue, 2023-02-21 at 22:49 +0100, Pali Rohár wrote:
> On Tuesday 21 February 2023 16:29:32 Paul Gortmaker wrote:
> > [Re: [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config
> > fragments.] On 21/02/2023 (Tue 21:03) Pali Roh??r wrote:
> > 
> > > On Tuesday 21 February 2023 14:46:37 Paul Gortmaker wrote:
> > > > None of these have a reference anymore anywhere, such as like this:
> > > > 
> > > >   arch/powerpc/Makefile:  $(call
> > > > merge_into_defconfig,mpc85xx_base.config,\
> > > > 
> > > > As such, we probably should just clean up and remove them.
> > > > 
> > > > Cc: Scott Wood 
> > > > Cc: Michael Ellerman 
> > > > Cc: Benjamin Herrenschmidt 
> > > > Cc: Paul Mackerras 
> > > > Signed-off-by: Paul Gortmaker 
> > > > ---
> > > >  arch/powerpc/configs/85xx-32bit.config |   5 -
> > > >  arch/powerpc/configs/85xx-hw.config    | 139 
> > > > -
> > > >  arch/powerpc/configs/85xx-smp.config   |   2 -
> > > >  3 files changed, 146 deletions(-)
> > > >  delete mode 100644 arch/powerpc/configs/85xx-32bit.config
> > > >  delete mode 100644 arch/powerpc/configs/85xx-hw.config
> > > >  delete mode 100644 arch/powerpc/configs/85xx-smp.config
> > > 
> > > This change is likely going to break mpc85xx platform because defconfig
> > > files includes all these files which you are going to remove. For
> > > example in arch/powerpc/Makefile is:
> > > 
> > > PHONY += mpc85xx_smp_defconfig
> > > mpc85xx_smp_defconfig:
> > > $(call merge_into_defconfig,mpc85xx_base.config,\
> > > 85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw)
> > 
> > OK, it seems you've answered a question for me.  That being "why didn't
> > grep find a reference to these fragments?"
> > 
> > It seems the ".config" extension is optional?
> 
> I really do not know. (And I'm not sure if I want to know answer :D)

It's not optional; you have to leave it off:

# Used to create 'merged defconfigs'
# To use it $(call) it with the first argument as the base defconfig
# and the second argument as a space separated list of .config files to merge,
# without the .config suffix.
define merge_into_defconfig
...

> > This seems inconsistent at best, to reference some files with the
> > .config extension and others without it.  Not blaming you for that,
> > but it is probably something that needs looking into.
> 
> I agree it is inconsistent. But it was there before I looked or touched
> any powerpc code. So it looks like something which nobody wanted to
> cleanup because "it works" and had no motivation.

No, it's intentional to reduce verbosity.  If by "inconsistent" you're
referring to mpc85xx_base.config, that argument sometimes refers to _defconfig
files (i.e. the pseries targets which were the initial user of
merge_into_config) so that argument can't autoappend .config.

-Crystal

Re: [PATCH 1/2] powerpc/64: Move CPU -mtune options into Kconfig

2023-03-02 Thread Michael Ellerman

Nathan Chancellor  writes:
> On Fri, Mar 03, 2023 at 12:16:55AM +1100, Michael Ellerman wrote:
>> Currently the -mtune options are set in the Makefile, depending on what
>> is the compiler supports.
>> 
>> One downside of doing it that way is that the chosen -mtune option is
>> not recorded in the .config.
>> 
>> Another downside is that doing more complicated logic to calculate the
>> correct option gets messy in the Makefile.
>> 
>> So move the determination of which -mtune option to use into Kconfig
>> logic.
>> 
>> Signed-off-by: Michael Ellerman 
>
> Reviewed-by: Nathan Chancellor 
>
>> ---
>>  arch/powerpc/Makefile  | 4 +---
>>  arch/powerpc/platforms/Kconfig.cputype | 6 ++
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>> 
>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>> index 87d6ac27eebd..779956007f0c 100644
>> --- a/arch/powerpc/Makefile
>> +++ b/arch/powerpc/Makefile
>> @@ -156,9 +156,7 @@ endif
>>  CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
>>  AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
>>  
>> -CFLAGS-$(CONFIG_POWERPC64_CPU) += $(call cc-option,-mtune=power10,  \
>> -  $(call cc-option,-mtune=power9,   \
>> -  $(call cc-option,-mtune=power8)))
>> +CFLAGS-y += $(CONFIG_TUNE_CPU)
>>  
>>  asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
>>  
>> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
>> b/arch/powerpc/platforms/Kconfig.cputype
>> index 046b571496b1..7d7477b73951 100644
>> --- a/arch/powerpc/platforms/Kconfig.cputype
>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>> @@ -273,6 +273,12 @@ config TARGET_CPU
>>  default "e500mc" if E500MC_CPU
>>  default "powerpc" if POWERPC_CPU
>>  
>> +config TUNE_CPU
>> +string
>> +default "-mtune=power10" if POWERPC64_CPU && CC_IS_GCC   && 
>> $(cc-option,-mtune=power10)
>> +default "-mtune=power9"  if POWERPC64_CPU && CC_IS_GCC   && 
>> $(cc-option,-mtune=power9)
>> +default "-mtune=power8"  if POWERPC64_CPU && CC_IS_GCC   && 
>> $(cc-option,-mtune=power8)
>
> Would it be cleaner to hoist the POWERPC64_CPU dependency?

I was experimenting with some follow-on patches that add more cases for
other CPUs, but that got messy and it'll need a bit more work.

So for now yes I should just hoist that dependency.

cheers

> config TUNE_CPU
>   string
>   default "-mtune=power10" if CC_IS_GCC   && $(cc-option,-mtune=power10)
>   default "-mtune=power9"  if CC_IS_GCC   && $(cc-option,-mtune=power9)
>   default "-mtune=power8"  if CC_IS_GCC   && $(cc-option,-mtune=power8)
>   depends on POWERPC64_CPU

Re: [PATCH 2/2] powerpc/64: Use -mtune=pwr10/9/8 for clang

2023-03-02 Thread Michael Ellerman

Nathan Chancellor  writes:
> Hi Michael,
>
> Thanks for the workaround and sorry this has come to bite us :/
>
> On Fri, Mar 03, 2023 at 12:16:56AM +1100, Michael Ellerman wrote:
>> For the -mtune option clang doesn't accept power10/9/8, instead it
>> accepts pwr10/9/8. That will be fixed in future versions of clang, but
>> the kernel must support the clang versions in the wild.
>> 
>> So add support for the "pwr" spelling if clang is in use.
>> 
>> Reported-by: Nathan Chancellor 
>
> I think that should actually be
>
> Reported-by: Nick Desaulniers 

I guess yeah.

>> BugLink: https://github.com/ClangBuiltLinux/linux/issues/1799
>> Signed-off-by: Michael Ellerman 
>
> Reviewed-by: Nathan Chancellor 

Thanks.

>> ---
>>  arch/powerpc/platforms/Kconfig.cputype | 4 
>>  1 file changed, 4 insertions(+)
>> 
>> Need to confirm the clang <= 16 statement is correct.
>
> Currently, this is indeed the case. It is possible that Nemanja's patch
> will get applied to release/16.x before 16.0.0 final but it might not.
>
> We can always update it later. I think we do want to push to get that
> patch applied because I forgot that it is only in 16.0.0 that '-mtune'
> starts to do something on PowerPC:
>
> https://github.com/llvm/llvm-project/commit/1dc26b80b872a94c581549a21943756a8c3448a3
>
> Prior to that change, '-mtune' was accepted but did nothing. It is only
> once it was hooked up to the backend that we got the spew of warnings. I
> think that warrants us trying to get Nemanja's patch into 16.0.0, which
> may allow us to drop this workaround altogether...

Aha OK, I missed that the warning was new in 16.

I'll sit on this for now then until we know if that change will make it
into clang 16.

cheers

Re: [PATCH] powerpc/64s: Fix __pte_needs_flush() false positive warning

2023-03-02 Thread Benjamin Gray

Accidentally added a bad auto-import, V2 sent
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20230302225947.81083-1-bg...@linux.ibm.com/

[PATCH v2] powerpc/64s: Fix __pte_needs_flush() false positive warning

2023-03-02 Thread Benjamin Gray

Userspace PROT_NONE ptes set _PAGE_PRIVILEGED, triggering a false
positive debug assertion that __pte_flags_need_flush() is not called
on a kernel mapping.

Detect when it is a userspace PROT_NONE page by checking the required
bits of PAGE_NONE are set, and none of the RWX bits are set.
pte_protnone() is insufficient here because it always returns 0 when
CONFIG_NUMA_BALANCING=n.

Reported-by: Russell Currey 
Fixes: b11931e9adc1 ("powerpc/64s: add pte_needs_flush and 
huge_pmd_needs_flush")
Signed-off-by: Benjamin Gray 
---
v2: removed an auto-import that slipped in

MRE (CONFIG_DEBUG_VM must be enabled):

int main(int argc, char **argv)
{
char *buf = mmap(NULL, getpagesize(), PROT_WRITE, MAP_SHARED | 
MAP_ANONYMOUS, -1, 0);
buf[0] = '1';
mprotect(buf, getpagesize(), PROT_NONE);
return 0;
}
---
 arch/powerpc/include/asm/book3s/64/tlbflush.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h 
b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index 2bbc0fcce04a..5e26c7f2c25a 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -148,6 +148,11 @@ static inline void flush_tlb_fix_spurious_fault(struct 
vm_area_struct *vma,
 */
 }
 
+static inline bool __pte_protnone(unsigned long pte)
+{
+   return (pte & (pgprot_val(PAGE_NONE) | _PAGE_RWX)) == 
pgprot_val(PAGE_NONE);
+}
+
 static inline bool __pte_flags_need_flush(unsigned long oldval,
  unsigned long newval)
 {
@@ -164,8 +169,8 @@ static inline bool __pte_flags_need_flush(unsigned long 
oldval,
/*
 * We do not expect kernel mappings or non-PTEs or not-present PTEs.
 */
-   VM_WARN_ON_ONCE(oldval & _PAGE_PRIVILEGED);
-   VM_WARN_ON_ONCE(newval & _PAGE_PRIVILEGED);
+   VM_WARN_ON_ONCE(!__pte_protnone(oldval) && oldval & _PAGE_PRIVILEGED);
+   VM_WARN_ON_ONCE(!__pte_protnone(newval) && newval & _PAGE_PRIVILEGED);
VM_WARN_ON_ONCE(!(oldval & _PAGE_PTE));
VM_WARN_ON_ONCE(!(newval & _PAGE_PTE));
VM_WARN_ON_ONCE(!(oldval & _PAGE_PRESENT));

base-commit: 90dbf76e470bc4b973052a8f26ea43bae30f9aec
-- 
2.39.2

[PATCH] powerpc/64s: Fix __pte_needs_flush() false positive warning

2023-03-02 Thread Benjamin Gray

Userspace PROT_NONE ptes set _PAGE_PRIVILEGED, triggering a false
positive debug assertion that __pte_flags_need_flush() is not called
on a kernel mapping.

Detect when it is a userspace PROT_NONE page by checking the required
bits of PAGE_NONE are set, and none of the RWX bits are set.
pte_protnone() is insufficient here because it always returns 0 when
CONFIG_NUMA_BALANCING=n.

Reported-by: Russell Currey 
Fixes: b11931e9adc1 ("powerpc/64s: add pte_needs_flush and 
huge_pmd_needs_flush")
Signed-off-by: Benjamin Gray 
---
MRE (CONFIG_DEBUG_VM must be enabled):

int main(int argc, char **argv)
{
char *buf = mmap(NULL, getpagesize(), PROT_WRITE, MAP_SHARED | 
MAP_ANONYMOUS, -1, 0);
buf[0] = '1';
mprotect(buf, getpagesize(), PROT_NONE);
return 0;
}
---
 arch/powerpc/include/asm/book3s/64/tlbflush.h | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h 
b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index 2bbc0fcce04a..68f25977fff7 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -2,6 +2,7 @@
 #ifndef _ASM_POWERPC_BOOK3S_64_TLBFLUSH_H
 #define _ASM_POWERPC_BOOK3S_64_TLBFLUSH_H
 
+#include "asm/book3s/64/pgtable.h"
 #define MMU_NO_CONTEXT ~0UL
 
 #include 
@@ -148,6 +149,11 @@ static inline void flush_tlb_fix_spurious_fault(struct 
vm_area_struct *vma,
 */
 }
 
+static inline bool __pte_protnone(unsigned long pte)
+{
+   return (pte & (pgprot_val(PAGE_NONE) | _PAGE_RWX)) == 
pgprot_val(PAGE_NONE);
+}
+
 static inline bool __pte_flags_need_flush(unsigned long oldval,
  unsigned long newval)
 {
@@ -164,8 +170,8 @@ static inline bool __pte_flags_need_flush(unsigned long 
oldval,
/*
 * We do not expect kernel mappings or non-PTEs or not-present PTEs.
 */
-   VM_WARN_ON_ONCE(oldval & _PAGE_PRIVILEGED);
-   VM_WARN_ON_ONCE(newval & _PAGE_PRIVILEGED);
+   VM_WARN_ON_ONCE(!__pte_protnone(oldval) && oldval & _PAGE_PRIVILEGED);
+   VM_WARN_ON_ONCE(!__pte_protnone(newval) && newval & _PAGE_PRIVILEGED);
VM_WARN_ON_ONCE(!(oldval & _PAGE_PTE));
VM_WARN_ON_ONCE(!(newval & _PAGE_PTE));
VM_WARN_ON_ONCE(!(oldval & _PAGE_PRESENT));

base-commit: 90dbf76e470bc4b973052a8f26ea43bae30f9aec
-- 
2.39.2

Re: [PATCH 2/2] powerpc/tpm: Reserve SML log when kexec'ing

2023-03-02 Thread Michael Ellerman

Stefan Berger  writes:
> On 2/23/23 22:25, Michael Ellerman wrote:
>> The TPM code in prom_init.c creates a small buffer of memory to store
>> the TPM's SML (Stored Measurement Log). It's communicated to Linux via
>> the linux,sml-base/size device tree properties of the TPM node.
>> 
>> When kexec'ing that buffer can be overwritten, or when kdump'ing it may
>> not be mapped by the second kernel. The latter can lead to a crash when
>> booting the second kernel such as:
>> 
>>tpm_ibmvtpm 7103: CRQ initialization completed
>>BUG: Unable to handle kernel data access on read at 0xc0002ffb
>>Faulting instruction address: 0xc000200a70e0
>>Oops: Kernel access of bad area, sig: 11 [#1]
>>LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
>>Modules linked in:
>>CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc2-00134-g9307ce092f5d 
>> #314
>>Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 
>> 0xf05 of:SLOF,git-5b4c5a pSeries
>>NIP:  c000200a70e0 LR: c000203dd5dc CTR: 0800
>>REGS: c00024543280 TRAP: 0300   Not tainted  
>> (6.2.0-rc2-00134-g9307ce092f5d)
>>MSR:  82009033   CR: 24002280  XER: 
>> 0006
>>CFAR: c000200a70c8 DAR: c0002ffb DSISR: 4000 IRQMASK: 0
>>...
>>NIP memcpy_power7+0x400/0x7d0
>>LR  kmemdup+0x5c/0x80
>>Call Trace:
>>  memcpy_power7+0x274/0x7d0 (unreliable)
>>  kmemdup+0x5c/0x80
>>  tpm_read_log_of+0xe8/0x1b0
>>  tpm_bios_log_setup+0x60/0x210
>>  tpm_chip_register+0x134/0x320
>>  tpm_ibmvtpm_probe+0x520/0x7d0
>>  vio_bus_probe+0x9c/0x460
>>  really_probe+0x104/0x420
>>  __driver_probe_device+0xb0/0x170
>>  driver_probe_device+0x58/0x180
>>  __driver_attach+0xd8/0x250
>>  bus_for_each_dev+0xb4/0x140
>>  driver_attach+0x34/0x50
>>  bus_add_driver+0x1e8/0x2d0
>>  driver_register+0xb4/0x1c0
>>  __vio_register_driver+0x74/0x9c
>>  ibmvtpm_module_init+0x34/0x48
>>  do_one_initcall+0x80/0x320
>>  kernel_init_freeable+0x304/0x3ac
>>  kernel_init+0x30/0x1a0
>>  ret_from_kernel_thread+0x5c/0x64
>
> I have not been able to reproduce this particular crash issue with a
> 6.2 kernel running on P10 PowerVM when NOT applying your patches.

The crash only happens for a crashdump kernel, not a regular kexec.

And depending on where the SML is in memory, compared to where the
crashkernel is, the SML might be mapped accidentally in which case there
is no crash.

> For my tests I have used the following parameter with the 16GB VM:
> crashkernel=2G-4G:384M,4G-16G:1G,16G-64G:2G,64G-128G:2G,128G-:4G

So you should be seeing a 2GB crashkernel reservation at 512MB.

> What I noticed is that the log gets corrupted when the 2 patches are applied:
>
> After fresh boot:
>
>> cp /sys/kernel/security/tpm0/binary_bios_measurements ./
>> ls -l binary_bios_measurements
> -r--r-. 1 root root 10051 Feb 28 12:09 binary_bios_measurements
>
>
>> kexec -l /boot/vmlinuz-6.2.0+ --initrd /boot/initramfs-6.2.0+.img 
>> '--append=BOOT_IMAGE=/vmlinuz-6.2.0+ root=/dev/mapper/rhel_XYZ ro 
>> crashkernel=2G-4G:384M,4G-16G:1G,16G-64G:2G,64G-128G:2G,128G-:4G 
>> rd.lvm.lv=rhel_XYZ/root rd.lvm.lv=rhel_XYZ/swap biosdevname=0' -s
>> kexec -e

That's a normal kexec, not a crash kexec, so it doesn't use the
crashkernel region mentioned above.

>> cp /sys/kernel/security/tpm0/binary_bios_measurements ./
>> ls -l binary_bios_measurements
> -r--r-. 1 root root 32 Feb 28 12:10 binary_bios_measurements
>
>> od -t x1 < binary_bios_measurements
> 000 d0 0d fe ed 00 00 77 80 00 00 00 a0 00 00 4f 4c
> 020 00 00 00 28 00 00 00 11 00 00 00 11 00 00 00 00
> 040

That's a device tree header !? O_o

#define OF_DT_HEADER0xd00dfeed  /* marker */

> The contents have changed and these first 4 bytes of it are always the
> same once it has become this 32 byte file, otherwise they would be
> zero.

I'm not sure what's happening there. We'll need to debug it some more :/

cheers

Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread H. Peter Anvin

On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt  wrote:
>On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
>> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
>>> Hi Heiko,
>>> 
>>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens  wrote:
>>> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
>>> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the
>>> > > RISC-V port.  In theory that's a UABI break, as COMMAND_LINE_SIZE is the
>>> > > maximum length of /proc/cmdline and userspace could staticly rely on
>>> > > that to be correct.
>>> > >
>>> > > Usually I wouldn't mess around with changing this sort of thing, but
>>> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
>>> > > to 2048").  There are also a handful of examples of COMMAND_LINE_SIZE
>>> > > increasing, but they're from before the UAPI split so I'm not quite sure
>>> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
>>> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
>>> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
>>> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
>>> > > asm-generic/setup.h.").
>>> > >
>>> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
>>> > > part of the uapi to begin with, and userspace should be able to handle
>>> > > /proc/cmdline of whatever length it turns out to be.  I don't see any
>>> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
>>> > > search, but that's not really enough to consider it unused on my end.
>>> > >
>>> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
>>> > > shouldn't be part of uapi, so this now touches all the ports.  I've
>>> > > tried to split this all out and leave it bisectable, but I haven't
>>> > > tested it all that aggressively.
>>> >
>>> > Just to confirm this assumption a bit more: that's actually the same
>>> > conclusion that we ended up with when commit 3da0243f906a ("s390: make
>>> > command line configurable") went upstream.
>
>Thanks, I guess I'd missed that one.  At some point I think there was some 
>discussion of making this a Kconfig for everyone, which seems reasonable to me 
>-- our use case for this being extended is syzkaller, but we're sort of just 
>picking a value that's big enough for now and running with it.
>
>Probably best to get it out of uapi first, though, as that way at least it's 
>clear that it's not uABI.
>
>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
>>> I assume?
>> 
>> Yes, sorry for that. I got distracted while writing and used the wrong
>> branch to look this up.
>
>Alex: Probably worth adding that to the list in the cover letter as it looks 
>like you were planning on a v4 anyway (which I guess you now have to do, given 
>that I just added the issue to RISC-V).

The only use that is uapi is the *default* length of the command line if the 
kernel header doesn't include it (in the case of x86, it is in the bzImage 
header, but that is atchitecture- or even boot format-specific.)

Re: [PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA

2023-03-02 Thread Borislav Petkov

On Mon, Feb 27, 2023 at 02:29:29PM -0800, Rick Edgecombe wrote:
> [0] 
> https://lore.kernel.org/lkml/0e29a2d0-08d8-bcd6-ff26-4bea0e403...@redhat.com/#t

I guess that sub-thread about how you arrived at this "pass a VMA"
decision should be in the Link tag. But that's for the committer, I'd
say.

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 2/2] powerpc/64: Use -mtune=pwr10/9/8 for clang

2023-03-02 Thread Nathan Chancellor

Hi Michael,

Thanks for the workaround and sorry this has come to bite us :/

On Fri, Mar 03, 2023 at 12:16:56AM +1100, Michael Ellerman wrote:
> For the -mtune option clang doesn't accept power10/9/8, instead it
> accepts pwr10/9/8. That will be fixed in future versions of clang, but
> the kernel must support the clang versions in the wild.
> 
> So add support for the "pwr" spelling if clang is in use.
> 
> Reported-by: Nathan Chancellor 

I think that should actually be

Reported-by: Nick Desaulniers 

> BugLink: https://github.com/ClangBuiltLinux/linux/issues/1799
> Signed-off-by: Michael Ellerman 

Reviewed-by: Nathan Chancellor 

> ---
>  arch/powerpc/platforms/Kconfig.cputype | 4 
>  1 file changed, 4 insertions(+)
> 
> Need to confirm the clang <= 16 statement is correct.

Currently, this is indeed the case. It is possible that Nemanja's patch
will get applied to release/16.x before 16.0.0 final but it might not.
We can always update it later. I think we do want to push to get that
patch applied because I forgot that it is only in 16.0.0 that '-mtune'
starts to do something on PowerPC:

https://github.com/llvm/llvm-project/commit/1dc26b80b872a94c581549a21943756a8c3448a3

Prior to that change, '-mtune' was accepted but did nothing. It is only
once it was hooked up to the backend that we got the spew of warnings. I
think that warrants us trying to get Nemanja's patch into 16.0.0, which
may allow us to drop this workaround altogether...

> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index 7d7477b73951..e4e0e81be7de 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -278,6 +278,10 @@ config TUNE_CPU
>   default "-mtune=power10" if POWERPC64_CPU && CC_IS_GCC   && 
> $(cc-option,-mtune=power10)
>   default "-mtune=power9"  if POWERPC64_CPU && CC_IS_GCC   && 
> $(cc-option,-mtune=power9)
>   default "-mtune=power8"  if POWERPC64_CPU && CC_IS_GCC   && 
> $(cc-option,-mtune=power8)
> + # clang <= 16 only supports the "pwr" names
> + default "-mtune=pwr10"   if POWERPC64_CPU && CC_IS_CLANG && 
> $(cc-option,-mtune=pwr10)
> + default "-mtune=pwr9"if POWERPC64_CPU && CC_IS_CLANG && 
> $(cc-option,-mtune=pwr9)
> + default "-mtune=pwr8"if POWERPC64_CPU && CC_IS_CLANG && 
> $(cc-option,-mtune=pwr8)
>  
>  config PPC_BOOK3S
>   def_bool y
> -- 
> 2.39.2
>

Re: [PATCH 1/2] powerpc/64: Move CPU -mtune options into Kconfig

2023-03-02 Thread Nathan Chancellor

On Fri, Mar 03, 2023 at 12:16:55AM +1100, Michael Ellerman wrote:
> Currently the -mtune options are set in the Makefile, depending on what
> is the compiler supports.
> 
> One downside of doing it that way is that the chosen -mtune option is
> not recorded in the .config.
> 
> Another downside is that doing more complicated logic to calculate the
> correct option gets messy in the Makefile.
> 
> So move the determination of which -mtune option to use into Kconfig
> logic.
> 
> Signed-off-by: Michael Ellerman 

Reviewed-by: Nathan Chancellor 

> ---
>  arch/powerpc/Makefile  | 4 +---
>  arch/powerpc/platforms/Kconfig.cputype | 6 ++
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 87d6ac27eebd..779956007f0c 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -156,9 +156,7 @@ endif
>  CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
>  AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
>  
> -CFLAGS-$(CONFIG_POWERPC64_CPU) += $(call cc-option,-mtune=power10,   \
> -   $(call cc-option,-mtune=power9,   \
> -   $(call cc-option,-mtune=power8)))
> +CFLAGS-y += $(CONFIG_TUNE_CPU)
>  
>  asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
>  
> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index 046b571496b1..7d7477b73951 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -273,6 +273,12 @@ config TARGET_CPU
>   default "e500mc" if E500MC_CPU
>   default "powerpc" if POWERPC_CPU
>  
> +config TUNE_CPU
> + string
> + default "-mtune=power10" if POWERPC64_CPU && CC_IS_GCC   && 
> $(cc-option,-mtune=power10)
> + default "-mtune=power9"  if POWERPC64_CPU && CC_IS_GCC   && 
> $(cc-option,-mtune=power9)
> + default "-mtune=power8"  if POWERPC64_CPU && CC_IS_GCC   && 
> $(cc-option,-mtune=power8)

Would it be cleaner to hoist the POWERPC64_CPU dependency?

config TUNE_CPU
string
default "-mtune=power10" if CC_IS_GCC   && $(cc-option,-mtune=power10)
default "-mtune=power9"  if CC_IS_GCC   && $(cc-option,-mtune=power9)
default "-mtune=power8"  if CC_IS_GCC   && $(cc-option,-mtune=power8)
depends on POWERPC64_CPU

> +
>  config PPC_BOOK3S
>   def_bool y
>   depends on PPC_BOOK3S_32 || PPC_BOOK3S_64
> -- 
> 2.39.2
>

Re: [patch 05/39] genirq/msi: Remove filter from msi_free_descs_free_range()

2023-03-02 Thread Miquel Raynal

Hi Thomas,

t...@linutronix.de wrote on Wed, 01 Mar 2023 22:07:48 +0100:

> Miquel!
> 
> On Wed, Mar 01 2023 at 11:55, Miquel Raynal wrote:
> > t...@linutronix.de wrote on Fri, 11 Nov 2022 14:54:22 +0100 (CET):
> >  
> >> When a range of descriptors is freed then all of them are not associated to
> >> a linux interrupt. Remove the filter and add a warning to the free 
> >> function.
> >> +  /* Leak the descriptor when it is still referenced */
> >> +  if (WARN_ON_ONCE(msi_desc_match(desc, MSI_DESC_ASSOCIATED)))
> >> +  continue;
> >> +  msi_free_desc(desc);
> >>}
> >>  }  
> >
> > It looks like since this commit I am getting warnings upon EPROBE_DEFER
> > errors in the mvpp2 Marvell Ethernet driver. I looked a bit at the
> > internals to understand why this warning was shown, and it seems that
> > nothing "de-references" the descriptors, which would mean here:
> > resetting desc->irq to 0.  
> 
> Correct. This platform-msi ^(*&!@&^ hack really needs to die ASAP.

:-)

> Marc, where are we on that? Is this still in limbo?
> 
> > I am wondering how useful thisd WARN_ON() is, or otherwise where the  
> 
> It is useful as it caught bugs already.

Sure.

> > desc->irq entry should be zeroed (if I understand that correctly), any
> > help will be appreciated.  
> 
> Untested workaround below.

Excellent!

> I hate it with a passion, but *shrug*.

:'D

> Thanks,
> 
> tglx
> ---
>  drivers/base/platform-msi.c |1 +
>  include/linux/msi.h |2 ++
>  kernel/irq/msi.c|   23 ++-
>  3 files changed, 25 insertions(+), 1 deletion(-)

Kudos for the diff, which indeed works perfectly in my case. I guess
you'll make a proper patch soon, if that's the case you can add my:

Tested-by: Miquel Raynal 

Let me know otherwise.

Thanks a lot for the very quick fix!
Miquèl

> --- a/drivers/base/platform-msi.c
> +++ b/drivers/base/platform-msi.c
> @@ -324,6 +324,7 @@ void platform_msi_device_domain_free(str
>   struct platform_msi_priv_data *data = domain->host_data;
>  
>   msi_lock_descs(data->dev);
> + msi_domain_depopulate_descs(data->dev, virq, nr_irqs);
>   irq_domain_free_irqs_common(domain, virq, nr_irqs);
>   msi_free_msi_descs_range(data->dev, virq, virq + nr_irqs - 1);
>   msi_unlock_descs(data->dev);
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -631,6 +631,8 @@ int msi_domain_prepare_irqs(struct irq_d
>   int nvec, msi_alloc_info_t *args);
>  int msi_domain_populate_irqs(struct irq_domain *domain, struct device *dev,
>int virq, int nvec, msi_alloc_info_t *args);
> +void msi_domain_depopulate_descs(struct device *dev, int virq, int nvec);
> +
>  struct irq_domain *
>  __platform_msi_create_device_domain(struct device *dev,
>   unsigned int nvec,
> --- a/kernel/irq/msi.c
> +++ b/kernel/irq/msi.c
> @@ -1109,14 +1109,35 @@ int msi_domain_populate_irqs(struct irq_
>   return 0;
>  
>  fail:
> - for (--virq; virq >= virq_base; virq--)
> + for (--virq; virq >= virq_base; virq--) {
> + msi_domain_depopulate_descs(dev, virq, 1);
>   irq_domain_free_irqs_common(domain, virq, 1);
> + }
>   msi_domain_free_descs(dev, );
>  unlock:
>   msi_unlock_descs(dev);
>   return ret;
>  }
>  
> +void msi_domain_depopulate_descs(struct device *dev, int virq_base, int nvec)
> +{
> + struct msi_ctrl ctrl = {
> + .domid  = MSI_DEFAULT_DOMAIN,
> + .first  = virq_base,
> + .last   = virq_base + nvec - 1,
> + };
> + struct msi_desc *desc;
> + struct xarray *xa;
> + unsigned long idx;
> +
> + if (!msi_ctrl_valid(dev, ))
> + return;
> +
> + xa = >msi.data->__domains[ctrl.domid].store;
> + xa_for_each_range(xa, idx, desc, ctrl.first, ctrl.last)
> + desc->irq = 0;
> +}
> +
>  /*
>   * Carefully check whether the device can use reservation mode. If
>   * reservation mode is enabled then the early activation will assign a

[PATCH 1/2] powerpc/64: Move CPU -mtune options into Kconfig

2023-03-02 Thread Michael Ellerman

Currently the -mtune options are set in the Makefile, depending on what
is the compiler supports.

One downside of doing it that way is that the chosen -mtune option is
not recorded in the .config.

Another downside is that doing more complicated logic to calculate the
correct option gets messy in the Makefile.

So move the determination of which -mtune option to use into Kconfig
logic.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Makefile  | 4 +---
 arch/powerpc/platforms/Kconfig.cputype | 6 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 87d6ac27eebd..779956007f0c 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -156,9 +156,7 @@ endif
 CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
 AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
 
-CFLAGS-$(CONFIG_POWERPC64_CPU) += $(call cc-option,-mtune=power10, \
- $(call cc-option,-mtune=power9,   \
- $(call cc-option,-mtune=power8)))
+CFLAGS-y += $(CONFIG_TUNE_CPU)
 
 asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
 
diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index 046b571496b1..7d7477b73951 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -273,6 +273,12 @@ config TARGET_CPU
default "e500mc" if E500MC_CPU
default "powerpc" if POWERPC_CPU
 
+config TUNE_CPU
+   string
+   default "-mtune=power10" if POWERPC64_CPU && CC_IS_GCC   && 
$(cc-option,-mtune=power10)
+   default "-mtune=power9"  if POWERPC64_CPU && CC_IS_GCC   && 
$(cc-option,-mtune=power9)
+   default "-mtune=power8"  if POWERPC64_CPU && CC_IS_GCC   && 
$(cc-option,-mtune=power8)
+
 config PPC_BOOK3S
def_bool y
depends on PPC_BOOK3S_32 || PPC_BOOK3S_64
-- 
2.39.2

[PATCH 2/2] powerpc/64: Use -mtune=pwr10/9/8 for clang

2023-03-02 Thread Michael Ellerman

For the -mtune option clang doesn't accept power10/9/8, instead it
accepts pwr10/9/8. That will be fixed in future versions of clang, but
the kernel must support the clang versions in the wild.

So add support for the "pwr" spelling if clang is in use.

Reported-by: Nathan Chancellor 
BugLink: https://github.com/ClangBuiltLinux/linux/issues/1799
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/Kconfig.cputype | 4 
 1 file changed, 4 insertions(+)

Need to confirm the clang <= 16 statement is correct.

diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index 7d7477b73951..e4e0e81be7de 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -278,6 +278,10 @@ config TUNE_CPU
default "-mtune=power10" if POWERPC64_CPU && CC_IS_GCC   && 
$(cc-option,-mtune=power10)
default "-mtune=power9"  if POWERPC64_CPU && CC_IS_GCC   && 
$(cc-option,-mtune=power9)
default "-mtune=power8"  if POWERPC64_CPU && CC_IS_GCC   && 
$(cc-option,-mtune=power8)
+   # clang <= 16 only supports the "pwr" names
+   default "-mtune=pwr10"   if POWERPC64_CPU && CC_IS_CLANG && 
$(cc-option,-mtune=pwr10)
+   default "-mtune=pwr9"if POWERPC64_CPU && CC_IS_CLANG && 
$(cc-option,-mtune=pwr9)
+   default "-mtune=pwr8"if POWERPC64_CPU && CC_IS_CLANG && 
$(cc-option,-mtune=pwr8)
 
 config PPC_BOOK3S
def_bool y
-- 
2.39.2

Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti




On 3/2/23 11:06, Alexandre Ghiti wrote:

Hi Arnd,

On 3/2/23 10:35, Alexandre Ghiti wrote:

This all came up in the context of increasing COMMAND_LINE_SIZE in the
RISC-V port.  In theory that's a UABI break, as COMMAND_LINE_SIZE is the
maximum length of /proc/cmdline and userspace could staticly rely on
that to be correct.

Usually I wouldn't mess around with changing this sort of thing, but
PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
to 2048").  There are also a handful of examples of COMMAND_LINE_SIZE
increasing, but they're from before the UAPI split so I'm not quite sure
what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
asm-generic/setup.h.").

It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
part of the uapi to begin with, and userspace should be able to handle
/proc/cmdline of whatever length it turns out to be.  I don't see any
references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
search, but that's not really enough to consider it unused on my end.

This issue was already considered in s390 and they reached the same
conclusion in commit 622021cd6c56 ("s390: make command line
configurable").

The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
shouldn't be part of uapi, so this now touches all the ports. I've
tried to split this all out and leave it bisectable, but I haven't
tested it all that aggressively.

Changes since v3 
:

* Added RB/AB
* Added a mention to commit 622021cd6c56 ("s390: make command line
   configurable") in the cover letter

Changes since v2 
:

* Fix sh, csky and ia64 builds, as reported by kernel test robot

Changes since v1 
:

* Touches every arch.

base-commit-tag: next-20230207

Palmer Dabbelt (24):
   alpha: Remove COMMAND_LINE_SIZE from uapi
   arm64: Remove COMMAND_LINE_SIZE from uapi
   arm: Remove COMMAND_LINE_SIZE from uapi
   ia64: Remove COMMAND_LINE_SIZE from uapi
   m68k: Remove COMMAND_LINE_SIZE from uapi
   microblaze: Remove COMMAND_LINE_SIZE from uapi
   mips: Remove COMMAND_LINE_SIZE from uapi
   parisc: Remove COMMAND_LINE_SIZE from uapi
   powerpc: Remove COMMAND_LINE_SIZE from uapi
   sparc: Remove COMMAND_LINE_SIZE from uapi
   xtensa: Remove COMMAND_LINE_SIZE from uapi
   asm-generic: Remove COMMAND_LINE_SIZE from uapi
   alpha: Remove empty 
   arc: Remove empty 
   m68k: Remove empty 
   arm64: Remove empty 
   microblaze: Remove empty 
   sparc: Remove empty 
   parisc: Remove empty 
   x86: Remove empty 
   xtensa: Remove empty 
   powerpc: Remove empty 
   mips: Remove empty 
   s390: Remove empty 

  .../admin-guide/kernel-parameters.rst |  2 +-
  arch/alpha/include/asm/setup.h    |  4 +--
  arch/alpha/include/uapi/asm/setup.h   |  7 -
  arch/arc/include/asm/setup.h  |  1 -
  arch/arc/include/uapi/asm/setup.h |  6 -
  arch/arm/include/asm/setup.h  |  1 +
  arch/arm/include/uapi/asm/setup.h |  2 --
  arch/arm64/include/asm/setup.h    |  3 ++-
  arch/arm64/include/uapi/asm/setup.h   | 27 ---
  arch/ia64/include/asm/setup.h | 10 +++
  arch/ia64/include/uapi/asm/setup.h    |  6 ++---
  arch/loongarch/include/asm/setup.h    |  2 +-
  arch/m68k/include/asm/setup.h |  3 +--
  arch/m68k/include/uapi/asm/setup.h    | 17 
  arch/microblaze/include/asm/setup.h   |  2 +-
  arch/microblaze/include/uapi/asm/setup.h  | 20 --
  arch/mips/include/asm/setup.h |  3 ++-
  arch/mips/include/uapi/asm/setup.h    |  8 --
  arch/parisc/include/{uapi => }/asm/setup.h    |  0
  arch/powerpc/include/asm/setup.h  |  2 +-
  arch/powerpc/include/uapi/asm/setup.h |  7 -
  arch/s390/include/asm/setup.h |  1 -
  arch/s390/include/uapi/asm/setup.h    |  1 -
  arch/sh/include/asm/setup.h   |  2 +-
  arch/sparc/include/asm/setup.h    |  6 -
  arch/sparc/include/uapi/asm/setup.h   | 16 ---
  arch/x86/include/asm/setup.h  |  2 --
  arch/x86/include/uapi/asm/setup.h |  1 -
  arch/xtensa/include/{uapi => }/asm/setup.h    |  0
  include/asm-generic/Kbuild    |  1 +
  include/{uapi => }/asm-generic/setup.h    |  0
  include/uapi/asm-generic/Kbuild   |  1 -
  32 files changed, 31 insertions(+), 133 deletions(-)
  delete mode 100644 arch/alpha/include/uapi/asm/setup.h

Re: [PATCH v2.1 04/24] arm64/cpu: Mark cpu_die() __noreturn

2023-03-02 Thread Philippe Mathieu-Daudé


On 16/2/23 19:41, Josh Poimboeuf wrote:

cpu_die() doesn't return.  Annotate it as such.  By extension this also
makes arch_cpu_idle_dead() noreturn.

Acked-by: Mark Rutland 
Signed-off-by: Josh Poimboeuf 
---
  arch/arm64/include/asm/smp.h | 2 +-
  arch/arm64/kernel/smp.c  | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v2.1 09/24] mips/cpu: Expose play_dead()'s prototype definition

2023-03-02 Thread Philippe Mathieu-Daudé


On 1/3/23 19:16, Josh Poimboeuf wrote:


The latest version of this patch triggered a new kbuild warning which is
fixed by the below patch.  If there are no objections I'll bundle it in
with the rest of the set for merging.

---8<---

Subject: [PATCH] mips/smp: Add CONFIG_SMP guard for raw_smp_processor_id()
Content-type: text/plain

Without CONFIG_SMP, raw_smp_processor_id() is not expected to be defined
by the arch.

Reported-by: kernel test robot 
Link: https://lore.kernel.org/oe-kbuild-all/202302220755.hm8j8gor-...@intel.com/
Signed-off-by: Josh Poimboeuf 
---
  arch/mips/include/asm/smp.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/mips/include/asm/smp.h b/arch/mips/include/asm/smp.h
index 4eee29b7845c..cf992b8b1e46 100644
--- a/arch/mips/include/asm/smp.h
+++ b/arch/mips/include/asm/smp.h
@@ -25,6 +25,7 @@ extern cpumask_t cpu_sibling_map[];
  extern cpumask_t cpu_core_map[];
  extern cpumask_t cpu_foreign_map[];
  
+#ifdef CONFIG_SMP

  static inline int raw_smp_processor_id(void)
  {
  #if defined(__VDSO__)
@@ -36,6 +37,7 @@ static inline int raw_smp_processor_id(void)
  #endif
  }
  #define raw_smp_processor_id raw_smp_processor_id
+#endif
  
  /* Map from cpu id to sequential logical cpu number.  This will only

 not be idempotent when cpus failed to come on-line.*/


Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti




On 3/2/23 11:44, Geert Uytterhoeven wrote:

Hi Alex,

On Thu, Mar 2, 2023 at 11:09 AM Alexandre Ghiti  wrote:

On 3/2/23 10:47, Geert Uytterhoeven wrote:

On Thu, Mar 2, 2023 at 10:35 AM Alexandre Ghiti  wrote:

This all came up in the context of increasing COMMAND_LINE_SIZE in the
RISC-V port.  In theory that's a UABI break, as COMMAND_LINE_SIZE is the
maximum length of /proc/cmdline and userspace could staticly rely on
that to be correct.

Usually I wouldn't mess around with changing this sort of thing, but
PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
to 2048").  There are also a handful of examples of COMMAND_LINE_SIZE
increasing, but they're from before the UAPI split so I'm not quite sure
what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
asm-generic/setup.h.").

It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
part of the uapi to begin with, and userspace should be able to handle
/proc/cmdline of whatever length it turns out to be.  I don't see any
references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
search, but that's not really enough to consider it unused on my end.

This issue was already considered in s390 and they reached the same
conclusion in commit 622021cd6c56 ("s390: make command line
configurable").

The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
shouldn't be part of uapi, so this now touches all the ports.  I've
tried to split this all out and leave it bisectable, but I haven't
tested it all that aggressively.

Changes since v3 
:
* Added RB/AB
* Added a mention to commit 622021cd6c56 ("s390: make command line
configurable") in the cover letter

Thanks for the update!

   Apparently you forgot to add your own SoB?

I do not know, should I? Palmer did all the work, I only fixed 3 minor
things

If you are picking up patches, and submitting them to someone else
for upstream inclusion, you should add your own SoB.
https://elixir.bootlin.com/linux/latest/source/Documentation/process/submitting-patches.rst#L419



Great, thanks for the pointer, I'll do that then!


Thanks again,


Alex



Gr{oetje,eeting}s,

 Geert

Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Geert Uytterhoeven

Hi Alex,

On Thu, Mar 2, 2023 at 11:09 AM Alexandre Ghiti  wrote:
> On 3/2/23 10:47, Geert Uytterhoeven wrote:
> > On Thu, Mar 2, 2023 at 10:35 AM Alexandre Ghiti  
> > wrote:
> >> This all came up in the context of increasing COMMAND_LINE_SIZE in the
> >> RISC-V port.  In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> >> maximum length of /proc/cmdline and userspace could staticly rely on
> >> that to be correct.
> >>
> >> Usually I wouldn't mess around with changing this sort of thing, but
> >> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> >> to 2048").  There are also a handful of examples of COMMAND_LINE_SIZE
> >> increasing, but they're from before the UAPI split so I'm not quite sure
> >> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> >> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> >> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> >> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> >> asm-generic/setup.h.").
> >>
> >> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> >> part of the uapi to begin with, and userspace should be able to handle
> >> /proc/cmdline of whatever length it turns out to be.  I don't see any
> >> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> >> search, but that's not really enough to consider it unused on my end.
> >>
> >> This issue was already considered in s390 and they reached the same
> >> conclusion in commit 622021cd6c56 ("s390: make command line
> >> configurable").
> >>
> >> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> >> shouldn't be part of uapi, so this now touches all the ports.  I've
> >> tried to split this all out and leave it bisectable, but I haven't
> >> tested it all that aggressively.
> >>
> >> Changes since v3 
> >> :
> >> * Added RB/AB
> >> * Added a mention to commit 622021cd6c56 ("s390: make command line
> >>configurable") in the cover letter
> > Thanks for the update!
> >
> >   Apparently you forgot to add your own SoB?
>
> I do not know, should I? Palmer did all the work, I only fixed 3 minor
> things

If you are picking up patches, and submitting them to someone else
for upstream inclusion, you should add your own SoB.
https://elixir.bootlin.com/linux/latest/source/Documentation/process/submitting-patches.rst#L419

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti


Hi Geert,

On 3/2/23 10:47, Geert Uytterhoeven wrote:

Hi Alex,

On Thu, Mar 2, 2023 at 10:35 AM Alexandre Ghiti  wrote:

This all came up in the context of increasing COMMAND_LINE_SIZE in the
RISC-V port.  In theory that's a UABI break, as COMMAND_LINE_SIZE is the
maximum length of /proc/cmdline and userspace could staticly rely on
that to be correct.

Usually I wouldn't mess around with changing this sort of thing, but
PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
to 2048").  There are also a handful of examples of COMMAND_LINE_SIZE
increasing, but they're from before the UAPI split so I'm not quite sure
what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
asm-generic/setup.h.").

It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
part of the uapi to begin with, and userspace should be able to handle
/proc/cmdline of whatever length it turns out to be.  I don't see any
references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
search, but that's not really enough to consider it unused on my end.

This issue was already considered in s390 and they reached the same
conclusion in commit 622021cd6c56 ("s390: make command line
configurable").

The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
shouldn't be part of uapi, so this now touches all the ports.  I've
tried to split this all out and leave it bisectable, but I haven't
tested it all that aggressively.

Changes since v3 
:
* Added RB/AB
* Added a mention to commit 622021cd6c56 ("s390: make command line
   configurable") in the cover letter

Thanks for the update!

  Apparently you forgot to add your own SoB?



I do not know, should I? Palmer did all the work, I only fixed 3 minor 
things





Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds

Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti


Hi Arnd,

On 3/2/23 10:35, Alexandre Ghiti wrote:

This all came up in the context of increasing COMMAND_LINE_SIZE in the
RISC-V port.  In theory that's a UABI break, as COMMAND_LINE_SIZE is the
maximum length of /proc/cmdline and userspace could staticly rely on
that to be correct.

Usually I wouldn't mess around with changing this sort of thing, but
PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
to 2048").  There are also a handful of examples of COMMAND_LINE_SIZE
increasing, but they're from before the UAPI split so I'm not quite sure
what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
asm-generic/setup.h.").

It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
part of the uapi to begin with, and userspace should be able to handle
/proc/cmdline of whatever length it turns out to be.  I don't see any
references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
search, but that's not really enough to consider it unused on my end.

This issue was already considered in s390 and they reached the same
conclusion in commit 622021cd6c56 ("s390: make command line
configurable").

The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
shouldn't be part of uapi, so this now touches all the ports.  I've
tried to split this all out and leave it bisectable, but I haven't
tested it all that aggressively.

Changes since v3 
:
* Added RB/AB
* Added a mention to commit 622021cd6c56 ("s390: make command line
   configurable") in the cover letter

Changes since v2 
:
* Fix sh, csky and ia64 builds, as reported by kernel test robot

Changes since v1 
:
* Touches every arch.

base-commit-tag: next-20230207

Palmer Dabbelt (24):
   alpha: Remove COMMAND_LINE_SIZE from uapi
   arm64: Remove COMMAND_LINE_SIZE from uapi
   arm: Remove COMMAND_LINE_SIZE from uapi
   ia64: Remove COMMAND_LINE_SIZE from uapi
   m68k: Remove COMMAND_LINE_SIZE from uapi
   microblaze: Remove COMMAND_LINE_SIZE from uapi
   mips: Remove COMMAND_LINE_SIZE from uapi
   parisc: Remove COMMAND_LINE_SIZE from uapi
   powerpc: Remove COMMAND_LINE_SIZE from uapi
   sparc: Remove COMMAND_LINE_SIZE from uapi
   xtensa: Remove COMMAND_LINE_SIZE from uapi
   asm-generic: Remove COMMAND_LINE_SIZE from uapi
   alpha: Remove empty 
   arc: Remove empty 
   m68k: Remove empty 
   arm64: Remove empty 
   microblaze: Remove empty 
   sparc: Remove empty 
   parisc: Remove empty 
   x86: Remove empty 
   xtensa: Remove empty 
   powerpc: Remove empty 
   mips: Remove empty 
   s390: Remove empty 

  .../admin-guide/kernel-parameters.rst |  2 +-
  arch/alpha/include/asm/setup.h|  4 +--
  arch/alpha/include/uapi/asm/setup.h   |  7 -
  arch/arc/include/asm/setup.h  |  1 -
  arch/arc/include/uapi/asm/setup.h |  6 -
  arch/arm/include/asm/setup.h  |  1 +
  arch/arm/include/uapi/asm/setup.h |  2 --
  arch/arm64/include/asm/setup.h|  3 ++-
  arch/arm64/include/uapi/asm/setup.h   | 27 ---
  arch/ia64/include/asm/setup.h | 10 +++
  arch/ia64/include/uapi/asm/setup.h|  6 ++---
  arch/loongarch/include/asm/setup.h|  2 +-
  arch/m68k/include/asm/setup.h |  3 +--
  arch/m68k/include/uapi/asm/setup.h| 17 
  arch/microblaze/include/asm/setup.h   |  2 +-
  arch/microblaze/include/uapi/asm/setup.h  | 20 --
  arch/mips/include/asm/setup.h |  3 ++-
  arch/mips/include/uapi/asm/setup.h|  8 --
  arch/parisc/include/{uapi => }/asm/setup.h|  0
  arch/powerpc/include/asm/setup.h  |  2 +-
  arch/powerpc/include/uapi/asm/setup.h |  7 -
  arch/s390/include/asm/setup.h |  1 -
  arch/s390/include/uapi/asm/setup.h|  1 -
  arch/sh/include/asm/setup.h   |  2 +-
  arch/sparc/include/asm/setup.h|  6 -
  arch/sparc/include/uapi/asm/setup.h   | 16 ---
  arch/x86/include/asm/setup.h  |  2 --
  arch/x86/include/uapi/asm/setup.h |  1 -
  arch/xtensa/include/{uapi => }/asm/setup.h|  0
  include/asm-generic/Kbuild|  1 +
  include/{uapi => }/asm-generic/setup.h|  0
  include/uapi/asm-generic/Kbuild   |  1 -
  32 files changed, 31 insertions(+), 133 deletions(-)
  delete mode 100644 arch/alpha/include/uapi/asm/setup.h
  delete mode 100644

[PATCH v4 24/24] s390: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
Acked-by: Heiko Carstens 
Reviewed-by: Philippe Mathieu-Daudé 
---
 arch/s390/include/asm/setup.h  | 1 -
 arch/s390/include/uapi/asm/setup.h | 1 -
 2 files changed, 2 deletions(-)
 delete mode 100644 arch/s390/include/uapi/asm/setup.h

diff --git a/arch/s390/include/asm/setup.h b/arch/s390/include/asm/setup.h
index 177bf6deaa27..99c1cc97350a 100644
--- a/arch/s390/include/asm/setup.h
+++ b/arch/s390/include/asm/setup.h
@@ -7,7 +7,6 @@
 #define _ASM_S390_SETUP_H
 
 #include 
-#include 
 #include 
 
 #define PARMAREA   0x10400
diff --git a/arch/s390/include/uapi/asm/setup.h 
b/arch/s390/include/uapi/asm/setup.h
deleted file mode 100644
index 598d769e76df..
--- a/arch/s390/include/uapi/asm/setup.h
+++ /dev/null
@@ -1 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-- 
2.37.2

[PATCH v4 23/24] mips: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
---
 arch/mips/include/uapi/asm/setup.h | 5 -
 1 file changed, 5 deletions(-)
 delete mode 100644 arch/mips/include/uapi/asm/setup.h

diff --git a/arch/mips/include/uapi/asm/setup.h 
b/arch/mips/include/uapi/asm/setup.h
deleted file mode 100644
index 157c3c392fb4..
--- a/arch/mips/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI_MIPS_SETUP_H
-#define _UAPI_MIPS_SETUP_H
-
-#endif /* _UAPI_MIPS_SETUP_H */
-- 
2.37.2

[PATCH v4 22/24] powerpc: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
---
 arch/powerpc/include/uapi/asm/setup.h | 5 -
 1 file changed, 5 deletions(-)
 delete mode 100644 arch/powerpc/include/uapi/asm/setup.h

diff --git a/arch/powerpc/include/uapi/asm/setup.h 
b/arch/powerpc/include/uapi/asm/setup.h
deleted file mode 100644
index f2ca747aa45b..
--- a/arch/powerpc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI_ASM_POWERPC_SETUP_H
-#define _UAPI_ASM_POWERPC_SETUP_H
-
-#endif /* _UAPI_ASM_POWERPC_SETUP_H */
-- 
2.37.2

[PATCH v4 21/24] xtensa: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
Acked-by: Max Filippov 
---
 arch/xtensa/include/uapi/asm/setup.h | 15 ---
 1 file changed, 15 deletions(-)
 delete mode 100644 arch/xtensa/include/uapi/asm/setup.h

diff --git a/arch/xtensa/include/uapi/asm/setup.h 
b/arch/xtensa/include/uapi/asm/setup.h
deleted file mode 100644
index 6f982394684a..
--- a/arch/xtensa/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * include/asm-xtensa/setup.h
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 2001 - 2005 Tensilica Inc.
- */
-
-#ifndef _XTENSA_SETUP_H
-#define _XTENSA_SETUP_H
-
-#endif
-- 
2.37.2

[PATCH v4 20/24] x86: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
Reviewed-by: Philippe Mathieu-Daudé 
---
 arch/x86/include/asm/setup.h  | 2 --
 arch/x86/include/uapi/asm/setup.h | 1 -
 2 files changed, 3 deletions(-)
 delete mode 100644 arch/x86/include/uapi/asm/setup.h

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index f37cbff7354c..449b50a2f390 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -2,8 +2,6 @@
 #ifndef _ASM_X86_SETUP_H
 #define _ASM_X86_SETUP_H
 
-#include 
-
 #define COMMAND_LINE_SIZE 2048
 
 #include 
diff --git a/arch/x86/include/uapi/asm/setup.h 
b/arch/x86/include/uapi/asm/setup.h
deleted file mode 100644
index 79a9626b5500..
--- a/arch/x86/include/uapi/asm/setup.h
+++ /dev/null
@@ -1 +0,0 @@
-/* */
-- 
2.37.2

[PATCH v4 19/24] parisc: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: Helge Deller 
---
 arch/parisc/include/uapi/asm/setup.h | 5 -
 1 file changed, 5 deletions(-)
 delete mode 100644 arch/parisc/include/uapi/asm/setup.h

diff --git a/arch/parisc/include/uapi/asm/setup.h 
b/arch/parisc/include/uapi/asm/setup.h
deleted file mode 100644
index bfad89428e47..
--- a/arch/parisc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _PARISC_SETUP_H
-#define _PARISC_SETUP_H
-
-#endif /* _PARISC_SETUP_H */
-- 
2.37.2

[PATCH v4 18/24] sparc: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
---
 arch/sparc/include/uapi/asm/setup.h | 9 -
 1 file changed, 9 deletions(-)
 delete mode 100644 arch/sparc/include/uapi/asm/setup.h

diff --git a/arch/sparc/include/uapi/asm/setup.h 
b/arch/sparc/include/uapi/asm/setup.h
deleted file mode 100644
index c3cf1b0d30b3..
--- a/arch/sparc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * Just a place holder. 
- */
-
-#ifndef _UAPI_SPARC_SETUP_H
-#define _UAPI_SPARC_SETUP_H
-
-#endif /* _UAPI_SPARC_SETUP_H */
-- 
2.37.2

[PATCH v4 17/24] microblaze: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
---
 arch/microblaze/include/uapi/asm/setup.h | 18 --
 1 file changed, 18 deletions(-)
 delete mode 100644 arch/microblaze/include/uapi/asm/setup.h

diff --git a/arch/microblaze/include/uapi/asm/setup.h 
b/arch/microblaze/include/uapi/asm/setup.h
deleted file mode 100644
index 51aed65880e7..
--- a/arch/microblaze/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * Copyright (C) 2007-2009 Michal Simek 
- * Copyright (C) 2007-2009 PetaLogix
- * Copyright (C) 2006 Atmark Techno, Inc.
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- */
-
-#ifndef _UAPI_ASM_MICROBLAZE_SETUP_H
-#define _UAPI_ASM_MICROBLAZE_SETUP_H
-
-# ifndef __ASSEMBLY__
-
-# endif /* __ASSEMBLY__ */
-#endif /* _UAPI_ASM_MICROBLAZE_SETUP_H */
-- 
2.37.2

[PATCH v4 16/24] arm64: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
---
 arch/arm64/include/uapi/asm/setup.h | 25 -
 1 file changed, 25 deletions(-)
 delete mode 100644 arch/arm64/include/uapi/asm/setup.h

diff --git a/arch/arm64/include/uapi/asm/setup.h 
b/arch/arm64/include/uapi/asm/setup.h
deleted file mode 100644
index f9f51e5925aa..
--- a/arch/arm64/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * Based on arch/arm/include/asm/setup.h
- *
- * Copyright (C) 1997-1999 Russell King
- * Copyright (C) 2012 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
- */
-#ifndef __ASM_SETUP_H
-#define __ASM_SETUP_H
-
-#include 
-
-#endif
-- 
2.37.2

[PATCH v4 15/24] m68k: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
Acked-by: Geert Uytterhoeven 
---
 arch/m68k/include/uapi/asm/setup.h | 15 ---
 1 file changed, 15 deletions(-)
 delete mode 100644 arch/m68k/include/uapi/asm/setup.h

diff --git a/arch/m68k/include/uapi/asm/setup.h 
b/arch/m68k/include/uapi/asm/setup.h
deleted file mode 100644
index 005593acc7d8..
--- a/arch/m68k/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
-** asm/setup.h -- Definition of the Linux/m68k setup information
-**
-** Copyright 1992 by Greg Harp
-**
-** This file is subject to the terms and conditions of the GNU General Public
-** License.  See the file COPYING in the main directory of this archive
-** for more details.
-*/
-
-#ifndef _UAPI_M68K_SETUP_H
-#define _UAPI_M68K_SETUP_H
-
-#endif /* _UAPI_M68K_SETUP_H */
-- 
2.37.2

[PATCH v4 14/24] arc: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
Reviewed-by: Philippe Mathieu-Daudé 
---
 arch/arc/include/asm/setup.h  | 1 -
 arch/arc/include/uapi/asm/setup.h | 6 --
 2 files changed, 7 deletions(-)
 delete mode 100644 arch/arc/include/uapi/asm/setup.h

diff --git a/arch/arc/include/asm/setup.h b/arch/arc/include/asm/setup.h
index 028a8cf76206..fe45ff4681bc 100644
--- a/arch/arc/include/asm/setup.h
+++ b/arch/arc/include/asm/setup.h
@@ -7,7 +7,6 @@
 
 
 #include 
-#include 
 
 #define COMMAND_LINE_SIZE 256
 
diff --git a/arch/arc/include/uapi/asm/setup.h 
b/arch/arc/include/uapi/asm/setup.h
deleted file mode 100644
index a6d4e44938be..
--- a/arch/arc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,6 +0,0 @@
-/*
- * setup.h is part of userspace header ABI so UAPI scripts have to generate it
- * even if there's nothing to export - causing empty 
- * However to prevent "patch" from discarding it we add this placeholder
- * comment
- */
-- 
2.37.2

[PATCH v4 13/24] alpha: Remove empty

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
---
 arch/alpha/include/uapi/asm/setup.h | 5 -
 1 file changed, 5 deletions(-)
 delete mode 100644 arch/alpha/include/uapi/asm/setup.h

diff --git a/arch/alpha/include/uapi/asm/setup.h 
b/arch/alpha/include/uapi/asm/setup.h
deleted file mode 100644
index 9b3b5ba39b1d..
--- a/arch/alpha/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI__ALPHA_SETUP_H
-#define _UAPI__ALPHA_SETUP_H
-
-#endif /* _UAPI__ALPHA_SETUP_H */
-- 
2.37.2

Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Geert Uytterhoeven

Hi Alex,

On Thu, Mar 2, 2023 at 10:35 AM Alexandre Ghiti  wrote:
> This all came up in the context of increasing COMMAND_LINE_SIZE in the
> RISC-V port.  In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> maximum length of /proc/cmdline and userspace could staticly rely on
> that to be correct.
>
> Usually I wouldn't mess around with changing this sort of thing, but
> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> to 2048").  There are also a handful of examples of COMMAND_LINE_SIZE
> increasing, but they're from before the UAPI split so I'm not quite sure
> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> asm-generic/setup.h.").
>
> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> part of the uapi to begin with, and userspace should be able to handle
> /proc/cmdline of whatever length it turns out to be.  I don't see any
> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> search, but that's not really enough to consider it unused on my end.
>
> This issue was already considered in s390 and they reached the same
> conclusion in commit 622021cd6c56 ("s390: make command line
> configurable").
>
> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> shouldn't be part of uapi, so this now touches all the ports.  I've
> tried to split this all out and leave it bisectable, but I haven't
> tested it all that aggressively.
>
> Changes since v3 
> :
> * Added RB/AB
> * Added a mention to commit 622021cd6c56 ("s390: make command line
>   configurable") in the cover letter

Thanks for the update!

 Apparently you forgot to add your own SoB?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v4 12/24] asm-generic: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.  Since  only
contains COMMAND_LINE_SIZE we can just move it out of uapi to hide the
definition and fix up the only direct use in Loongarch.

Signed-off-by: Palmer Dabbelt 
Link: https://lore.kernel.org/r/20210423025545.313965-1-pal...@dabbelt.com
Signed-off-by: Palmer Dabbelt 
---
 Documentation/admin-guide/kernel-parameters.rst | 2 +-
 arch/loongarch/include/asm/setup.h  | 2 +-
 arch/sh/include/asm/setup.h | 2 +-
 include/asm-generic/Kbuild  | 1 +
 include/{uapi => }/asm-generic/setup.h  | 0
 include/uapi/asm-generic/Kbuild | 1 -
 6 files changed, 4 insertions(+), 4 deletions(-)
 rename include/{uapi => }/asm-generic/setup.h (100%)

diff --git a/Documentation/admin-guide/kernel-parameters.rst 
b/Documentation/admin-guide/kernel-parameters.rst
index 19600c50277b..2b94d5a42bd6 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -207,7 +207,7 @@ The number of kernel parameters is not limited, but the 
length of the
 complete command line (parameters including spaces etc.) is limited to
 a fixed number of characters. This limit depends on the architecture
 and is between 256 and 4096 characters. It is defined in the file
-./include/uapi/asm-generic/setup.h as COMMAND_LINE_SIZE.
+./include/asm-generic/setup.h as COMMAND_LINE_SIZE.
 
 Finally, the [KMG] suffix is commonly described after a number of kernel
 parameter values. These 'K', 'M', and 'G' letters represent the _binary_
diff --git a/arch/loongarch/include/asm/setup.h 
b/arch/loongarch/include/asm/setup.h
index 72ead58039f3..86c99b183ea0 100644
--- a/arch/loongarch/include/asm/setup.h
+++ b/arch/loongarch/include/asm/setup.h
@@ -7,7 +7,7 @@
 #define _LOONGARCH_SETUP_H
 
 #include 
-#include 
+#include 
 
 #define VECSIZE 0x200
 
diff --git a/arch/sh/include/asm/setup.h b/arch/sh/include/asm/setup.h
index fc807011187f..ae09b1c29fd1 100644
--- a/arch/sh/include/asm/setup.h
+++ b/arch/sh/include/asm/setup.h
@@ -2,7 +2,7 @@
 #ifndef _SH_SETUP_H
 #define _SH_SETUP_H
 
-#include 
+#include 
 
 /*
  * This is set up by the setup-routine at boot-time
diff --git a/include/asm-generic/Kbuild b/include/asm-generic/Kbuild
index 941be574bbe0..0fb55a119f54 100644
--- a/include/asm-generic/Kbuild
+++ b/include/asm-generic/Kbuild
@@ -49,6 +49,7 @@ mandatory-y += preempt.h
 mandatory-y += rwonce.h
 mandatory-y += sections.h
 mandatory-y += serial.h
+mandatory-y += setup.h
 mandatory-y += shmparam.h
 mandatory-y += simd.h
 mandatory-y += softirq_stack.h
diff --git a/include/uapi/asm-generic/setup.h b/include/asm-generic/setup.h
similarity index 100%
rename from include/uapi/asm-generic/setup.h
rename to include/asm-generic/setup.h
diff --git a/include/uapi/asm-generic/Kbuild b/include/uapi/asm-generic/Kbuild
index ebb180aac74e..0e7122339ee9 100644
--- a/include/uapi/asm-generic/Kbuild
+++ b/include/uapi/asm-generic/Kbuild
@@ -20,7 +20,6 @@ mandatory-y += posix_types.h
 mandatory-y += ptrace.h
 mandatory-y += resource.h
 mandatory-y += sembuf.h
-mandatory-y += setup.h
 mandatory-y += shmbuf.h
 mandatory-y += sigcontext.h
 mandatory-y += siginfo.h
-- 
2.37.2

[PATCH v4 11/24] xtensa: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
Acked-by: Max Filippov 
---
 arch/xtensa/include/asm/setup.h  | 17 +
 arch/xtensa/include/uapi/asm/setup.h |  2 --
 2 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 arch/xtensa/include/asm/setup.h

diff --git a/arch/xtensa/include/asm/setup.h b/arch/xtensa/include/asm/setup.h
new file mode 100644
index ..5356a5fd4d17
--- /dev/null
+++ b/arch/xtensa/include/asm/setup.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * include/asm-xtensa/setup.h
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2001 - 2005 Tensilica Inc.
+ */
+
+#ifndef _XTENSA_SETUP_H
+#define _XTENSA_SETUP_H
+
+#define COMMAND_LINE_SIZE  256
+
+#endif
diff --git a/arch/xtensa/include/uapi/asm/setup.h 
b/arch/xtensa/include/uapi/asm/setup.h
index 5356a5fd4d17..6f982394684a 100644
--- a/arch/xtensa/include/uapi/asm/setup.h
+++ b/arch/xtensa/include/uapi/asm/setup.h
@@ -12,6 +12,4 @@
 #ifndef _XTENSA_SETUP_H
 #define _XTENSA_SETUP_H
 
-#define COMMAND_LINE_SIZE  256
-
 #endif
-- 
2.37.2

[PATCH v4 10/24] sparc: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
---
 arch/sparc/include/asm/setup.h  | 6 +-
 arch/sparc/include/uapi/asm/setup.h | 7 ---
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/arch/sparc/include/asm/setup.h b/arch/sparc/include/asm/setup.h
index 72205684e51e..d1384ed92547 100644
--- a/arch/sparc/include/asm/setup.h
+++ b/arch/sparc/include/asm/setup.h
@@ -7,7 +7,11 @@
 
 #include 
 
-#include 
+#if defined(__sparc__) && defined(__arch64__)
+# define COMMAND_LINE_SIZE 2048
+#else
+# define COMMAND_LINE_SIZE 256
+#endif
 
 extern char reboot_command[];
 
diff --git a/arch/sparc/include/uapi/asm/setup.h 
b/arch/sparc/include/uapi/asm/setup.h
index 3c208a4dd464..c3cf1b0d30b3 100644
--- a/arch/sparc/include/uapi/asm/setup.h
+++ b/arch/sparc/include/uapi/asm/setup.h
@@ -6,11 +6,4 @@
 #ifndef _UAPI_SPARC_SETUP_H
 #define _UAPI_SPARC_SETUP_H
 
-#if defined(__sparc__) && defined(__arch64__)
-# define COMMAND_LINE_SIZE 2048
-#else
-# define COMMAND_LINE_SIZE 256
-#endif
-
-
 #endif /* _UAPI_SPARC_SETUP_H */
-- 
2.37.2

[PATCH v4 09/24] powerpc: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
Acked-by: Michael Ellerman 
---
 arch/powerpc/include/asm/setup.h  | 2 +-
 arch/powerpc/include/uapi/asm/setup.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index e29e83f8a89c..31786d1db2ef 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_POWERPC_SETUP_H
 #define _ASM_POWERPC_SETUP_H
 
-#include 
+#define COMMAND_LINE_SIZE  2048
 
 #ifndef __ASSEMBLY__
 extern void ppc_printk_progress(char *s, unsigned short hex);
diff --git a/arch/powerpc/include/uapi/asm/setup.h 
b/arch/powerpc/include/uapi/asm/setup.h
index c54940b09d06..f2ca747aa45b 100644
--- a/arch/powerpc/include/uapi/asm/setup.h
+++ b/arch/powerpc/include/uapi/asm/setup.h
@@ -2,6 +2,4 @@
 #ifndef _UAPI_ASM_POWERPC_SETUP_H
 #define _UAPI_ASM_POWERPC_SETUP_H
 
-#define COMMAND_LINE_SIZE  2048
-
 #endif /* _UAPI_ASM_POWERPC_SETUP_H */
-- 
2.37.2

[PATCH v4 08/24] parisc: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: Helge Deller 
---
 arch/parisc/include/asm/setup.h  | 7 +++
 arch/parisc/include/uapi/asm/setup.h | 2 --
 2 files changed, 7 insertions(+), 2 deletions(-)
 create mode 100644 arch/parisc/include/asm/setup.h

diff --git a/arch/parisc/include/asm/setup.h b/arch/parisc/include/asm/setup.h
new file mode 100644
index ..78b2f4ec7d65
--- /dev/null
+++ b/arch/parisc/include/asm/setup.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _PARISC_SETUP_H
+#define _PARISC_SETUP_H
+
+#define COMMAND_LINE_SIZE  1024
+
+#endif /* _PARISC_SETUP_H */
diff --git a/arch/parisc/include/uapi/asm/setup.h 
b/arch/parisc/include/uapi/asm/setup.h
index 78b2f4ec7d65..bfad89428e47 100644
--- a/arch/parisc/include/uapi/asm/setup.h
+++ b/arch/parisc/include/uapi/asm/setup.h
@@ -2,6 +2,4 @@
 #ifndef _PARISC_SETUP_H
 #define _PARISC_SETUP_H
 
-#define COMMAND_LINE_SIZE  1024
-
 #endif /* _PARISC_SETUP_H */
-- 
2.37.2

[PATCH v4 07/24] mips: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
Reviewed-by: Philippe Mathieu-Daudé 
---
 arch/mips/include/asm/setup.h  | 3 ++-
 arch/mips/include/uapi/asm/setup.h | 3 ---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/mips/include/asm/setup.h b/arch/mips/include/asm/setup.h
index 8c56b862fd9c..a13b9259b476 100644
--- a/arch/mips/include/asm/setup.h
+++ b/arch/mips/include/asm/setup.h
@@ -3,7 +3,8 @@
 #define _MIPS_SETUP_H
 
 #include 
-#include 
+
+#define COMMAND_LINE_SIZE  4096
 
 extern void prom_putchar(char);
 extern void setup_early_printk(void);
diff --git a/arch/mips/include/uapi/asm/setup.h 
b/arch/mips/include/uapi/asm/setup.h
index 7d48c433b0c2..157c3c392fb4 100644
--- a/arch/mips/include/uapi/asm/setup.h
+++ b/arch/mips/include/uapi/asm/setup.h
@@ -2,7 +2,4 @@
 #ifndef _UAPI_MIPS_SETUP_H
 #define _UAPI_MIPS_SETUP_H
 
-#define COMMAND_LINE_SIZE  4096
-
-
 #endif /* _UAPI_MIPS_SETUP_H */
-- 
2.37.2

[PATCH v4 06/24] microblaze: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
---
 arch/microblaze/include/asm/setup.h  | 2 +-
 arch/microblaze/include/uapi/asm/setup.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/microblaze/include/asm/setup.h 
b/arch/microblaze/include/asm/setup.h
index a06cc1f97aa9..2becbf3b8baf 100644
--- a/arch/microblaze/include/asm/setup.h
+++ b/arch/microblaze/include/asm/setup.h
@@ -7,7 +7,7 @@
 #ifndef _ASM_MICROBLAZE_SETUP_H
 #define _ASM_MICROBLAZE_SETUP_H
 
-#include 
+#define COMMAND_LINE_SIZE  256
 
 # ifndef __ASSEMBLY__
 extern char cmd_line[COMMAND_LINE_SIZE];
diff --git a/arch/microblaze/include/uapi/asm/setup.h 
b/arch/microblaze/include/uapi/asm/setup.h
index 6831794e6f2c..51aed65880e7 100644
--- a/arch/microblaze/include/uapi/asm/setup.h
+++ b/arch/microblaze/include/uapi/asm/setup.h
@@ -12,8 +12,6 @@
 #ifndef _UAPI_ASM_MICROBLAZE_SETUP_H
 #define _UAPI_ASM_MICROBLAZE_SETUP_H
 
-#define COMMAND_LINE_SIZE  256
-
 # ifndef __ASSEMBLY__
 
 # endif /* __ASSEMBLY__ */
-- 
2.37.2

Re: [PATCH 1/1] mm/nommu: remove unnecessary VMA locking

2023-03-02 Thread David Hildenbrand


On 01.03.23 20:04, Suren Baghdasaryan wrote:

Since CONFIG_PER_VMA_LOCK depends on CONFIG_MMU, the changes in nommu
are not needed. Remove them.

Fixes: bad94decd6a4 ("mm: write-lock VMAs before removing them from VMA tree")
Reported-by: Hyeonggon Yoo <42.hye...@gmail.com>
Link: https://lore.kernel.org/all/Y%2F8CJQGNuMUTdLwP@localhost/
Signed-off-by: Suren Baghdasaryan 
---
Fix cleanly applies over mm-unstable, SHA in "Fixes" is from that tree.

  mm/nommu.c | 5 -
  1 file changed, 5 deletions(-)

diff --git a/mm/nommu.c b/mm/nommu.c
index 2ab162d773e2..57ba243c6a37 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -588,7 +588,6 @@ static int delete_vma_from_mm(struct vm_area_struct *vma)
   current->pid);
return -ENOMEM;
}
-   vma_start_write(vma);
cleanup_vma_from_mm(vma);
  
  	/* remove from the MM's tree and list */

@@ -1520,10 +1519,6 @@ void exit_mmap(struct mm_struct *mm)
 */
mmap_write_lock(mm);
for_each_vma(vmi, vma) {
-   /*
-* No need to lock VMA because this is the only mm user and no
-* page fault handled can race with it.
-*/
cleanup_vma_from_mm(vma);
delete_vma(mm, vma);
cond_resched();


So, i assume this should be squashed.

Reviewed-by: David Hildenbrand 


Just a general comment: usually, if review of the original series is 
still going on, it makes a lot more sense to raise such things in the 
original series so the author can fixup while things are still in 
mm-unstable. Once the series is in mm-stable, it's a different story. In 
that case, it is usually good to have the mail subjects be something 
like  "[PATCH mm-stable 1/1] ...".


--
Thanks,

David / dhildenb

[PATCH v4 05/24] m68k: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
Acked-by: Geert Uytterhoeven 
---
 arch/m68k/include/asm/setup.h  | 3 +--
 arch/m68k/include/uapi/asm/setup.h | 2 --
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/m68k/include/asm/setup.h b/arch/m68k/include/asm/setup.h
index 2c99477aaf89..9a256cc3931d 100644
--- a/arch/m68k/include/asm/setup.h
+++ b/arch/m68k/include/asm/setup.h
@@ -23,9 +23,8 @@
 #define _M68K_SETUP_H
 
 #include 
-#include 
-
 
+#define COMMAND_LINE_SIZE 256
 #define CL_SIZE COMMAND_LINE_SIZE
 
 #ifndef __ASSEMBLY__
diff --git a/arch/m68k/include/uapi/asm/setup.h 
b/arch/m68k/include/uapi/asm/setup.h
index 25fe26d5597c..005593acc7d8 100644
--- a/arch/m68k/include/uapi/asm/setup.h
+++ b/arch/m68k/include/uapi/asm/setup.h
@@ -12,6 +12,4 @@
 #ifndef _UAPI_M68K_SETUP_H
 #define _UAPI_M68K_SETUP_H
 
-#define COMMAND_LINE_SIZE 256
-
 #endif /* _UAPI_M68K_SETUP_H */
-- 
2.37.2

[PATCH v4 04/24] ia64: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
---
 arch/ia64/include/asm/setup.h  | 10 ++
 arch/ia64/include/uapi/asm/setup.h |  6 ++
 2 files changed, 12 insertions(+), 4 deletions(-)
 create mode 100644 arch/ia64/include/asm/setup.h

diff --git a/arch/ia64/include/asm/setup.h b/arch/ia64/include/asm/setup.h
new file mode 100644
index ..0b19338ea3ec
--- /dev/null
+++ b/arch/ia64/include/asm/setup.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+
+#ifndef __IA64_SETUP_H
+#define __IA64_SETUP_H
+
+#include 
+
+#define COMMAND_LINE_SIZE  2048
+
+#endif
diff --git a/arch/ia64/include/uapi/asm/setup.h 
b/arch/ia64/include/uapi/asm/setup.h
index 8d13ce8fb03a..bcbb2b242ded 100644
--- a/arch/ia64/include/uapi/asm/setup.h
+++ b/arch/ia64/include/uapi/asm/setup.h
@@ -1,8 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef __IA64_SETUP_H
-#define __IA64_SETUP_H
-
-#define COMMAND_LINE_SIZE  2048
+#ifndef __UAPI_IA64_SETUP_H
+#define __UAPI_IA64_SETUP_H
 
 extern struct ia64_boot_param {
__u64 command_line; /* physical address of command line 
arguments */
-- 
2.37.2

[PATCH v4 03/24] arm: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
Reviewed-by: Russell King (Oracle) 
---
 arch/arm/include/asm/setup.h  | 1 +
 arch/arm/include/uapi/asm/setup.h | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index ba0872a8dcda..8a1e4f804d1b 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -13,6 +13,7 @@
 
 #include 
 
+#define COMMAND_LINE_SIZE 1024
 
 #define __tag __used __section(".taglist.init")
 #define __tagtable(tag, fn) \
diff --git a/arch/arm/include/uapi/asm/setup.h 
b/arch/arm/include/uapi/asm/setup.h
index 25ceda63b284..87a4f4af28e1 100644
--- a/arch/arm/include/uapi/asm/setup.h
+++ b/arch/arm/include/uapi/asm/setup.h
@@ -17,8 +17,6 @@
 
 #include 
 
-#define COMMAND_LINE_SIZE 1024
-
 /* The list ends with an ATAG_NONE node. */
 #define ATAG_NONE  0x
 
-- 
2.37.2

[PATCH v4 02/24] arm64: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
Acked-by: Catalin Marinas 
---
 arch/arm64/include/asm/setup.h  | 3 ++-
 arch/arm64/include/uapi/asm/setup.h | 2 --
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
index f4af547ef54c..7ca70f883cee 100644
--- a/arch/arm64/include/asm/setup.h
+++ b/arch/arm64/include/asm/setup.h
@@ -4,8 +4,9 @@
 #define __ARM64_ASM_SETUP_H
 
 #include 
+#include 
 
-#include 
+#define COMMAND_LINE_SIZE  2048
 
 void *get_early_fdt_ptr(void);
 void early_fdt_map(u64 dt_phys);
diff --git a/arch/arm64/include/uapi/asm/setup.h 
b/arch/arm64/include/uapi/asm/setup.h
index 5d703888f351..f9f51e5925aa 100644
--- a/arch/arm64/include/uapi/asm/setup.h
+++ b/arch/arm64/include/uapi/asm/setup.h
@@ -22,6 +22,4 @@
 
 #include 
 
-#define COMMAND_LINE_SIZE  2048
-
 #endif
-- 
2.37.2

[PATCH v4 01/24] alpha: Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
Reviewed-by: Philippe Mathieu-Daudé 
---
 arch/alpha/include/asm/setup.h  | 4 ++--
 arch/alpha/include/uapi/asm/setup.h | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/alpha/include/asm/setup.h b/arch/alpha/include/asm/setup.h
index 262aab99e391..ea08ca45efa8 100644
--- a/arch/alpha/include/asm/setup.h
+++ b/arch/alpha/include/asm/setup.h
@@ -2,8 +2,6 @@
 #ifndef __ALPHA_SETUP_H
 #define __ALPHA_SETUP_H
 
-#include 
-
 /*
  * We leave one page for the initial stack page, and one page for
  * the initial process structure. Also, the console eats 3 MB for
@@ -14,6 +12,8 @@
 /* Remove when official MILO sources have ELF support: */
 #define BOOT_SIZE  (16*1024)
 
+#define COMMAND_LINE_SIZE  256
+
 #ifdef CONFIG_ALPHA_LEGACY_START_ADDRESS
 #define KERNEL_START_PHYS  0x30 /* Old bootloaders hardcoded this.  */
 #else
diff --git a/arch/alpha/include/uapi/asm/setup.h 
b/arch/alpha/include/uapi/asm/setup.h
index f881ea5947cb..9b3b5ba39b1d 100644
--- a/arch/alpha/include/uapi/asm/setup.h
+++ b/arch/alpha/include/uapi/asm/setup.h
@@ -2,6 +2,4 @@
 #ifndef _UAPI__ALPHA_SETUP_H
 #define _UAPI__ALPHA_SETUP_H
 
-#define COMMAND_LINE_SIZE  256
-
 #endif /* _UAPI__ALPHA_SETUP_H */
-- 
2.37.2

[PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi

2023-03-02 Thread Alexandre Ghiti

This all came up in the context of increasing COMMAND_LINE_SIZE in the
RISC-V port.  In theory that's a UABI break, as COMMAND_LINE_SIZE is the
maximum length of /proc/cmdline and userspace could staticly rely on
that to be correct.

Usually I wouldn't mess around with changing this sort of thing, but
PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
to 2048").  There are also a handful of examples of COMMAND_LINE_SIZE
increasing, but they're from before the UAPI split so I'm not quite sure
what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
asm-generic/setup.h.").

It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
part of the uapi to begin with, and userspace should be able to handle
/proc/cmdline of whatever length it turns out to be.  I don't see any
references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
search, but that's not really enough to consider it unused on my end.

This issue was already considered in s390 and they reached the same
conclusion in commit 622021cd6c56 ("s390: make command line
configurable").

The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
shouldn't be part of uapi, so this now touches all the ports.  I've
tried to split this all out and leave it bisectable, but I haven't
tested it all that aggressively.

Changes since v3 
:
* Added RB/AB
* Added a mention to commit 622021cd6c56 ("s390: make command line
  configurable") in the cover letter

Changes since v2 
:
* Fix sh, csky and ia64 builds, as reported by kernel test robot

Changes since v1 
:
* Touches every arch.

base-commit-tag: next-20230207

Palmer Dabbelt (24):
  alpha: Remove COMMAND_LINE_SIZE from uapi
  arm64: Remove COMMAND_LINE_SIZE from uapi
  arm: Remove COMMAND_LINE_SIZE from uapi
  ia64: Remove COMMAND_LINE_SIZE from uapi
  m68k: Remove COMMAND_LINE_SIZE from uapi
  microblaze: Remove COMMAND_LINE_SIZE from uapi
  mips: Remove COMMAND_LINE_SIZE from uapi
  parisc: Remove COMMAND_LINE_SIZE from uapi
  powerpc: Remove COMMAND_LINE_SIZE from uapi
  sparc: Remove COMMAND_LINE_SIZE from uapi
  xtensa: Remove COMMAND_LINE_SIZE from uapi
  asm-generic: Remove COMMAND_LINE_SIZE from uapi
  alpha: Remove empty 
  arc: Remove empty 
  m68k: Remove empty 
  arm64: Remove empty 
  microblaze: Remove empty 
  sparc: Remove empty 
  parisc: Remove empty 
  x86: Remove empty 
  xtensa: Remove empty 
  powerpc: Remove empty 
  mips: Remove empty 
  s390: Remove empty 

 .../admin-guide/kernel-parameters.rst |  2 +-
 arch/alpha/include/asm/setup.h|  4 +--
 arch/alpha/include/uapi/asm/setup.h   |  7 -
 arch/arc/include/asm/setup.h  |  1 -
 arch/arc/include/uapi/asm/setup.h |  6 -
 arch/arm/include/asm/setup.h  |  1 +
 arch/arm/include/uapi/asm/setup.h |  2 --
 arch/arm64/include/asm/setup.h|  3 ++-
 arch/arm64/include/uapi/asm/setup.h   | 27 ---
 arch/ia64/include/asm/setup.h | 10 +++
 arch/ia64/include/uapi/asm/setup.h|  6 ++---
 arch/loongarch/include/asm/setup.h|  2 +-
 arch/m68k/include/asm/setup.h |  3 +--
 arch/m68k/include/uapi/asm/setup.h| 17 
 arch/microblaze/include/asm/setup.h   |  2 +-
 arch/microblaze/include/uapi/asm/setup.h  | 20 --
 arch/mips/include/asm/setup.h |  3 ++-
 arch/mips/include/uapi/asm/setup.h|  8 --
 arch/parisc/include/{uapi => }/asm/setup.h|  0
 arch/powerpc/include/asm/setup.h  |  2 +-
 arch/powerpc/include/uapi/asm/setup.h |  7 -
 arch/s390/include/asm/setup.h |  1 -
 arch/s390/include/uapi/asm/setup.h|  1 -
 arch/sh/include/asm/setup.h   |  2 +-
 arch/sparc/include/asm/setup.h|  6 -
 arch/sparc/include/uapi/asm/setup.h   | 16 ---
 arch/x86/include/asm/setup.h  |  2 --
 arch/x86/include/uapi/asm/setup.h |  1 -
 arch/xtensa/include/{uapi => }/asm/setup.h|  0
 include/asm-generic/Kbuild|  1 +
 include/{uapi => }/asm-generic/setup.h|  0
 include/uapi/asm-generic/Kbuild   |  1 -
 32 files changed, 31 insertions(+), 133 deletions(-)
 delete mode 100644 arch/alpha/include/uapi/asm/setup.h
 delete mode 100644 arch/arc/include/uapi/asm/setup.h
 delete mode 100644 arch/arm64/include/uapi/asm/setup.h
 create mode 100644 arch/ia64/include/asm/setup.h

52 matches

Mail list logo