Re: [PATCH] ARC: mm: retire support for aliasing VIPT D$

[Andrew Morton]

On Sun, 13 Aug 2023 12:25:43 -0700 Vineet Gupta  wrote:

> Legacy ARC700 processors (first generation of MMU enabled ARC cores) has
> VIPT cached which could be configured such that they could alias.
> I added the VIPT aliasing support, with all the cache flush overhead to
> support all but 1 silicon. That is long bygone and we can remove the
> complexity and maintenance burden of that unneeded code.
> 
> This also helps streamline support for new features such as generic folio
> work.
> 

This of course messes up Matthew's "arc: implement the new page table
range API".  Are you or Matthew up for redoing that patch?

Alternatively, can you redo this patch on top of Matthew's patch (ie,
against mm-unstable or linux-next)?

Thanks.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 3/3] mm, arch: add generic implementation of pfn_valid() for FLATMEM

[Andrew Morton]

On Wed, 25 Jan 2023 21:07:57 +0200 Mike Rapoport  wrote:

> Every architecture that supports FLATMEM memory model defines its own
> version of pfn_valid() that essentially compares a pfn to max_mapnr.
> 
> Use mips/powerpc version implemented as static inline as a generic
> implementation of pfn_valid() and drop its per-architecture definitions

arm allnoconfig:

./include/asm-generic/memory_model.h:23:19: error: static declaration of 
'pfn_valid' follows non-static declaration
   23 | static inline int pfn_valid(unsigned long pfn)
  |   ^
./arch/arm/include/asm/page.h:160:12: note: previous declaration of 'pfn_valid' 
with type 'int(long unsigned int)'
  160 | extern int pfn_valid(unsigned long);
  |^


I thought of doing

--- 
a/arch/arm/include/asm/page.h~mm-arch-add-generic-implementation-of-pfn_valid-for-flatmem-fix
+++ a/arch/arm/include/asm/page.h
@@ -156,10 +156,6 @@ extern void copy_page(void *to, const vo
 
 typedef struct page *pgtable_t;
 
-#ifdef CONFIG_HAVE_ARCH_PFN_VALID
-extern int pfn_valid(unsigned long);
-#endif
-
 #include 
 
 #endif /* !__ASSEMBLY__ */
_

but I'm seeing a pfn_valid declaration in arch/arc/include/asm/page.h
which might be a problem.

v2, please ;)

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] bit_spinlock: Include

[Andrew Morton]

On Sun,  8 Jan 2023 20:04:44 +0100 Christophe JAILLET 
 wrote:

> In an attempt to simplify some includes in , it
> appeared, when compiling fs/ecryptfs/dentry.c, that 
> was relying on other includes to get the definition of cpu_relax().
> (see [1])
> 
> It broke on arc.
> 
> Include  in  to fix the issue.
> This will help remove some un-needed includes from .
> 
> [1]: https://lore.kernel.org/all/202301082130.lxmj5qkd-...@intel.com/
> 
> ...
>
> --- a/include/linux/bit_spinlock.h
> +++ b/include/linux/bit_spinlock.h
> @@ -2,6 +2,7 @@
>  #ifndef __LINUX_BIT_SPINLOCK_H
>  #define __LINUX_BIT_SPINLOCK_H
>  
> +#include 
>  #include 
>  #include 
>  #include 

linux/processor.h would be preferable, rather than diving straight into asm/?

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 00/19] Introduce __xchg, non-atomic xchg

[Andrew Morton]

On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda  
wrote:

> Hi all,
> 
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.

So to clarify, the intent here is a simple readability cleanup for
existing open-coded exchange operations.  The intent is *not* to
identify existing xchg() sites which are unnecessarily atomic and to
optimize them by using the non-atomic version.

Have you considered the latter?

> I am not sure who is good person to review/ack such patches,

I can take 'em.

> so I've used my intuition to construct to/cc lists, sorry for mistakes.
> This is the 2nd approach of the same idea, with comments addressed[0].
> 
> The helper is tiny and there are advices we can leave without it, so
> I want to present few arguments why it would be good to have it:
> 
> 1. Code readability/simplification/number of lines:
> 
> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c:
> -   previous_min_rate = evport->qos.min_rate;
> -   evport->qos.min_rate = min_rate;
> +   previous_min_rate = __xchg(evport->qos.min_rate, min_rate);
> 
> For sure the code is more compact, and IMHO more readable.
> 
> 2. Presence of similar helpers in other somehow related languages/libs:
> 
> a) Rust[1]: 'replace' from std::mem module, there is also 'take'
> helper (__xchg(, 0)), which is the same as private helper in
> i915 - fetch_and_zero, see latest patch.
> b) C++ [2]: 'exchange' from utility header.
> 
> If the idea is OK there are still 2 qestions to answer:
> 
> 1. Name of the helper, __xchg follows kernel conventions,
> but for me Rust names are also OK.

I like replace(), or, shockingly, exchange().

But...   Can we simply make swap() return the previous value?

previous_min_rate = swap(>qos.min_rate, min_rate);



___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] profile: setup_profiling_timer() is moslty not implemented

[Andrew Morton]

On Thu, 21 Jul 2022 20:55:09 +0100 Ben Dooks  wrote:

> The setup_profiling_timer() is mostly un-implemented by many
> architectures. In many places it isn't guarded by CONFIG_PROFILE
> which is needed for it to be used. Make it a weak symbol in
> kernel/profile.c and remove the 'return -EINVAL' implementations
> from the kenrel.
> 
> There are a couple of architectures which do return 0 from
> the setup_profiling_timer() function but they don't seem to
> do anything else with it. To keep the /proc compatibility for
> now, leave these for a future update or removal.
> 
> On ARM, this fixes the following sparse warning:
> arch/arm/kernel/smp.c:793:5: warning: symbol 'setup_profiling_timer' was not 
> declared. Should it be static?

I'll grab this.

We have had some problems with weak functions lately.  See

https://lore.kernel.org/all/87ee0q7b92@email.froward.int.ebiederm.org/T/#u

Hopefully that was a rare corner case.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V7 00/26] mm/mmap: Drop __SXXX/__PXXX macros from across platforms

[Andrew Morton]

On Mon, 11 Jul 2022 12:35:34 +0530 Anshuman Khandual 
 wrote:

> This series drops __SXXX/__PXXX macros from across platforms in the tree.

I've updated mm-unstable to this version, thanks.  I skipped the added-to-mm
emails to avoid wearing out people's inboxes.

Reissuing a 26-patch series N times is rather noisy.  Please prefer to send 
incremental
fixes when changes are minor.  It makes it so much easier for reviewers to see 
what
happened.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 8/9] mm: replace CONFIG_NEED_MULTIPLE_NODES with CONFIG_NUMA

[Andrew Morton]

On Tue,  8 Jun 2021 12:13:15 +0300 Mike Rapoport  wrote:

> From: Mike Rapoport 
> 
> After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
> configuration options are equivalent.
> 
> Drop CONFIG_NEED_MULTIPLE_NODES and use CONFIG_NUMA instead.
> 
> Done with
> 
>   $ sed -i 's/CONFIG_NEED_MULTIPLE_NODES/CONFIG_NUMA/' \
>   $(git grep -wl CONFIG_NEED_MULTIPLE_NODES)
>   $ sed -i 's/NEED_MULTIPLE_NODES/NUMA/' \
>   $(git grep -wl NEED_MULTIPLE_NODES)
> 
> with manual tweaks afterwards.
> 
> ...
>
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -987,7 +987,7 @@ extern int movable_zone;
>  #ifdef CONFIG_HIGHMEM
>  static inline int zone_movable_is_highmem(void)
>  {
> -#ifdef CONFIG_NEED_MULTIPLE_NODES
> +#ifdef CONFIG_NUMA
>   return movable_zone == ZONE_HIGHMEM;
>  #else
>   return (ZONE_MOVABLE - 1) == ZONE_HIGHMEM;

I dropped this hunk - your "mm/mmzone.h: simplify is_highmem_idx()"
removed zone_movable_is_highmem().  

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [RFC] proc: get_wchan() stack unwind only makes sense for sleeping/non-self tasks

[Andrew Morton]

On Thu,  5 Nov 2020 15:11:32 -0800 Vineet Gupta  
wrote:

> Most architectures currently check this in their get_wchan() implementation
> (ARC doesn't hence this patch). However doing this in core code shows
> the semantics better so move the check one level up (eventually remove
> the boiler-plate code from arches)

It would be nice to clean up the arch callees in the same patch, at
least so it doesn't get forgotten about.  Are you prepared to propose
such a change?


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

[Andrew Morton]

On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny  wrote:

> > > 
> > > Actually it occurs to me that the patch consolidating kmap_prot is odd for
> > > sparc 32 bit...
> > > 
> > > Its a long shot but could you try reverting this patch?
> > > 
> > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions
> > > 
> > 
> > That is not easy to revert, unfortunately, due to several follow-up patches.
> 
> I have gotten your sparc tests to run and they all pass...
> 
> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh 
> Build reference: v5.7-rc4-17-g852b6f2edc0f
> 
> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
> Building sparc32:SS-4:nosmp:initrd ... running . passed
> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed
> Building sparc32:SS-4:smp:scsi:hd ... running . passed
> Building sparc32:SS-5:smp:scsi:cd ... running . passed
> Building sparc32:SS-10:smp:scsi:hd ... running . passed
> Building sparc32:SS-20:smp:scsi:hd ... running . passed
> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed
> 
> Is there another test I need to run?

This all petered out, but as I understand it, this patchset still might
have issues on various architectures.

Can folks please provide an update on the testing status?

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2 00/12] mm: consolidate definitions of page table accessors

[Andrew Morton]

On Thu, 14 May 2020 20:03:15 +0300 Mike Rapoport  wrote:

> The low level page table accessors (pXY_index(), pXY_offset()) are
> duplicated across all architectures and sometimes more than once. For
> instance, we have 31 definition of pgd_offset() for 25 supported
> architectures.
> 
> Most of these definitions are actually identical and typically it boils
> down to, e.g. 
> 
> static inline unsigned long pmd_index(unsigned long address)
> {
> return (address >> PMD_SHIFT) & (PTRS_PER_PMD - 1);
> }
> 
> static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
> {
> return (pmd_t *)pud_page_vaddr(*pud) + pmd_index(address);
> }
> 
> These definitions can be shared among 90% of the arches provided XYZ_SHIFT,
> PTRS_PER_XYZ and xyz_page_vaddr() are defined.
> 
> For architectures that really need a custom version there is always
> possibility to override the generic version with the usual ifdefs magic.
> 
> These patches introduce include/linux/pgtable.h that replaces
> include/asm-generic/pgtable.h and add the definitions of the page table
> accessors to the new header.

hm,

>  712 files changed, 684 insertions(+), 2021 deletions(-)

big!

There's a lot of stuff going on at present (I suspect everyone is
sitting at home coding up a storm).  However this all merged up fairly
cleanly, haven't tried compiling it yet.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V3 15/15] kmap: Consolidate kmap_prot definitions

[Andrew Morton]

On Thu,  7 May 2020 08:00:03 -0700 ira.we...@intel.com wrote:

> From: Ira Weiny 
> 
> Most architectures define kmap_prot to be PAGE_KERNEL.
> 
> Let sparc and xtensa define there own and define PAGE_KERNEL as the
> default if not overridden.
> 

checkpatch considered useful ;)


From: Andrew Morton 
Subject: kmap-consolidate-kmap_prot-definitions-checkpatch-fixes

WARNING: macros should not use a trailing semicolon
#134: FILE: arch/sparc/include/asm/highmem.h:33:
+#define kmap_prot __pgprot(SRMMU_ET_PTE | SRMMU_PRIV | SRMMU_CACHE);

total: 0 errors, 1 warnings, 100 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

./patches/kmap-consolidate-kmap_prot-definitions.patch has style problems, 
please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Ira Weiny 
Signed-off-by: Andrew Morton 
---

 arch/sparc/include/asm/highmem.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 
a/arch/sparc/include/asm/highmem.h~kmap-consolidate-kmap_prot-definitions-checkpatch-fixes
+++ a/arch/sparc/include/asm/highmem.h
@@ -30,7 +30,7 @@
 /* declarations for highmem.c */
 extern unsigned long highstart_pfn, highend_pfn;
 
-#define kmap_prot __pgprot(SRMMU_ET_PTE | SRMMU_PRIV | SRMMU_CACHE);
+#define kmap_prot __pgprot(SRMMU_ET_PTE | SRMMU_PRIV | SRMMU_CACHE)
 extern pte_t *pkmap_page_table;
 
 void kmap_init(void) __init;
_


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V3 13/15] parisc/kmap: Remove duplicate kmap code

[Andrew Morton]

On Thu,  7 May 2020 08:00:01 -0700 ira.we...@intel.com wrote:

> parisc reimplements the kmap calls except to flush it's dcache.  This is
> arguably an abuse of kmap but regardless it is messy and confusing.
> 
> Remove the duplicate code and have parisc define
> ARCH_HAS_FLUSH_ON_KUNMAP for a kunmap_flush_on_unmap() architecture
> specific call to flush the cache.

checkpatch says:

ERROR: #define of 'ARCH_HAS_FLUSH_ON_KUNMAP' is wrong - use Kconfig variables 
or standard guards instead
#69: FILE: arch/parisc/include/asm/cacheflush.h:103:
+#define ARCH_HAS_FLUSH_ON_KUNMAP

which is fair enough, I guess.  More conventional would be

arch/parisc/include/asm/cacheflush.h:

static inline void kunmap_flush_on_unmap(void *addr)
{
...
}
#define kunmap_flush_on_unmap kunmap_flush_on_unmap


include/linux/highmem.h:

#ifndef kunmap_flush_on_unmap
static inline void kunmap_flush_on_unmap(void *addr)
{
}
#define kunmap_flush_on_unmap kunmap_flush_on_unmap
#endif


static inline void kunmap_atomic_high(void *addr)
{
/* Mostly nothing to do in the CONFIG_HIGHMEM=n case as kunmap_atomic()
 * handles re-enabling faults + preemption */
kunmap_flush_on_unmap(addr);
}


but I don't really think it's worth bothering changing it.  

(Ditto patch 3/15)

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 0/2] mm/thp: Rename pmd_mknotpresent() as pmd_mknotvalid()

[Andrew Morton]

On Sun, 29 Mar 2020 19:12:35 +0530 Anshuman Khandual 
 wrote:

> 
> 
> On 03/20/2020 10:24 AM, Anshuman Khandual wrote:
> > This series renames pmd_mknotpresent() as pmd_mknotvalid(). Before that it
> > drops an existing pmd_mknotpresent() definition from powerpc platform which
> > was never required as it defines it's pmdp_invalidate() through subscribing
> > __HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change.
> > 
> > This rename was suggested by Catalin during a previous discussion while we
> > were trying to change the THP helpers on arm64 platform for migration.
> > 
> > https://patchwork.kernel.org/patch/11019637/
> > 
> > This series is based on v5.6-rc6.
> > 
> > Boot tested on arm64 and x86 platforms.
> > Built tested on many other platforms including the ones changed here.
> 
> Gentle ping, any updates regarding this ?

We're in the merge window so I have parked this for consideration after
-rc1.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers

[Andrew Morton]

On Thu, 27 Feb 2020 08:04:05 +0530 Anshuman Khandual 
 wrote:

> > Must be something wrong with the following in debug_vm_pgtable()
> > 
> > paddr = __pa(_kernel);
> > 
> > Is there any explaination why start_kernel() is not in linear memory on 
> > ARM64 ?
> 
> 
> Cc: + James Morse 
> 
> This warning gets exposed with DEBUG_VIRTUAL due to __pa() on a kernel symbol
> i.e 'start_kernel' which might be outside the linear map. This happens due to
> kernel mapping position randomization with KASLR. Adding James here in case he
> might like to add more.
> 
> __pa_symbol() should have been used instead, for accessing the physical 
> address
> here. On arm64 __pa() does check for linear address with __is_lm_address() and
> switch accordingly if it is a kernel text symbol. Nevertheless, its much 
> better
> to use __pa_symbol() here rather than __pa().
> 
> Rather than respining the patch once more, will just send a fix replacing this
> helper __pa() with __pa_symbol() for Andrew to pick up as this patch is 
> already
> part of linux-next (next-20200226). But can definitely respin if that will be
> preferred.

I didn't see this fix?  I assume it's this?  If so, are we sure it's OK to be
added to -next without testing??



From: Andrew Morton 
Subject: mm-debug-add-tests-validating-architecture-page-table-helpers-fix

A warning gets exposed with DEBUG_VIRTUAL due to __pa() on a kernel symbol
i.e 'start_kernel' which might be outside the linear map.  This happens
due to kernel mapping position randomization with KASLR.

__pa_symbol() should have been used instead, for accessing the physical
address here.  On arm64 __pa() does check for linear address with
__is_lm_address() and switch accordingly if it is a kernel text symbol. 
Nevertheless, its much better to use __pa_symbol() here rather than
__pa().

Reported-by: Qian Cai 
Cc: Anshuman Khandual 
Cc: James Morse 
Cc: Christophe Leroy 
Signed-off-by: Andrew Morton 
---

 mm/debug_vm_pgtable.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 
a/mm/debug_vm_pgtable.c~mm-debug-add-tests-validating-architecture-page-table-helpers-fix
+++ a/mm/debug_vm_pgtable.c
@@ -331,7 +331,7 @@ void __init debug_vm_pgtable(void)
 * helps avoid large memory block allocations to be used for mapping
 * at higher page table levels.
 */
-   paddr = __pa(_kernel);
+   paddr = __pa_symbol(_kernel);
 
pte_aligned = (paddr & PAGE_MASK) >> PAGE_SHIFT;
pmd_aligned = (paddr & PMD_MASK) >> PAGE_SHIFT;
_


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers

[Andrew Morton]

On Thu, 6 Feb 2020 13:49:35 +0530 Anshuman Khandual  
wrote:

> 
> On 02/06/2020 04:40 AM, kbuild test robot wrote:
> > Hi Anshuman,
> > 
> > Thank you for the patch! Yet something to improve:
> > 
> > [auto build test ERROR on powerpc/next]
> > [also build test ERROR on s390/features linus/master arc/for-next v5.5]
> > [cannot apply to mmotm/master tip/x86/core arm64/for-next/core 
> > next-20200205]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help
> > improve the system. BTW, we also suggest to use '--base' option to specify 
> > the
> > base tree in git format-patch, please see 
> > https://stackoverflow.com/a/37406982]
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-validating-architecture-page-table-helpers/20200205-215507
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
> > next
> > config: ia64-allmodconfig (attached as .config)
> > compiler: ia64-linux-gcc (GCC) 7.5.0
> > reproduce:
> > wget 
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > GCC_VERSION=7.5.0 make.cross ARCH=ia64 
> > 
> > If you fix the issue, kindly add following tag
> > Reported-by: kbuild test robot 
> > 
> > All error/warnings (new ones prefixed by >>):
> > 
> >In file included from include/asm-generic/pgtable-nopud.h:8:0,
> > from arch/ia64/include/asm/pgtable.h:586,
> > from include/linux/mm.h:99,
> > from include/linux/highmem.h:8,
> > from mm/debug_vm_pgtable.c:14:
> >mm/debug_vm_pgtable.c: In function 'pud_clear_tests':
> >>> include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit 
> >>> declaration of function '__pgd'; did you mean '__p4d'? 
> >>> [-Werror=implicit-function-declaration]
> > #define __pud(x)((pud_t) { __pgd(x) })
> >^
> >>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
> >  pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> >^
> >>> include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces 
> >>> around initializer [-Wmissing-braces]
> > #define __pud(x)((pud_t) { __pgd(x) })
> >  ^
> >>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
> >  pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> >^
> >cc1: some warnings being treated as errors
> 
> This build failure is expected now given that we have allowed DEBUG_VM_PGTABLE
> with EXPERT without platform requiring ARCH_HAS_DEBUG_VM_PGTABLE. This problem
> i.e build failure caused without a platform __pgd(), is known to exist both on
> ia64 and arm (32bit) platforms. Please refer 
> https://lkml.org/lkml/2019/9/24/314
> for details where this was discussed earlier.
> 

I'd prefer not to merge a patch which is known to cause build
regressions.  Is there some temporary thing we can do to prevent these
errors until arch maintainers(?) get around to implementing the
long-term fixes?



___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()

[Andrew Morton]

On Thu, 13 Jun 2019 15:37:24 +0530 Anshuman Khandual 
 wrote:

> Architectures which support kprobes have very similar boilerplate around
> calling kprobe_fault_handler(). Use a helper function in kprobes.h to unify
> them, based on the x86 code.
> 
> This changes the behaviour for other architectures when preemption is
> enabled. Previously, they would have disabled preemption while calling the
> kprobe handler. However, preemption would be disabled if this fault was
> due to a kprobe, so we know the fault was not due to a kprobe handler and
> can simply return failure.
> 
> This behaviour was introduced in the commit a980c0ef9f6d ("x86/kprobes:
> Refactor kprobes_fault() like kprobe_exceptions_notify()")
> 
> ...
>
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -30,28 +30,6 @@
>  
>  #ifdef CONFIG_MMU
>  
> -#ifdef CONFIG_KPROBES
> -static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)

Some architectures make this `static inline'.  Others make it
`nokprobes_inline', others make it `static inline __kprobes'.  The
latter seems weird - why try to put an inline function into
.kprobes.text?

So..  what's the best thing to do here?  You chose `static
nokprobe_inline' - is that the best approach, if so why?  Does
kprobe_page_fault() actually need to be inlined?

Also, some architectures had notify_page_fault returning int, others
bool.  You chose bool and that seems appropriate and all callers are OK
with that.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.

[Andrew Morton]

Please add changelogs.  An explanation of what a "limit on memory
region random shift" is would be nice ;) Why does it exist, why are we
doing this, etc.  Surely there's something to be said - at present this
is just a lump of random code?




___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] fix double ;;s in code

[Andrew Morton]

On Tue, 20 Feb 2018 10:03:56 +0200 Jani Nikula  
wrote:

> On Mon, 19 Feb 2018, Pavel Machek  wrote:
> > On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
> >> Yeah, pls split this into one patch per area, with a suitable patch
> >> subject prefix. Look at git log of each file to get a feeling for what's
> >> the standard in each area.
> >
> > Yeah I can spend hour spliting it, and then people will ignore it
> > anyway.
> >
> > If you care about one of the files being modified, please fix the
> > bug, ";;" is a clear bug.
> >
> > If you don't care ... well I don't care either.
> 
> Look, if this causes just one conflict down the line because it touches
> the kernel all over the place, then IMO it already wasn't worth
> it. Merge conflicts are inevitable, but there's no reason to make life
> harder just to cater for a cleanup patch. It's not that important.
> 
> Had it been split up, the drm parts would've been merged already.

I just stage patches like this behind linux-next.  So if your stuff in
in -next, you'll never notice a thing.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2] arch: define weak abort

[Andrew Morton]

On Tue, 19 Dec 2017 13:39:22 -0800 Vineet Gupta <vineet.gup...@synopsys.com> 
wrote:

> > --- a/kernel/exit.c
> > +++ b/kernel/exit.c
> > @@ -1759,3 +1759,11 @@ long kernel_wait4(pid_t upid, int __user *stat_addr, 
> > int options,
> > return -EFAULT;
> >   }
> >   #endif
> > +
> > +__weak void abort(void)
> > +{
> > +   BUG();
> > +
> > +   /* if that doesn't kill us, halt */
> > +   panic("Oops failed to kill thread");
> > +}
> 
> Hmm, I realize there's a small gotcha with this, when testing with a 
> different 
> patch from Arnd. This needs an EXPORT_SYMBOL() as well !

Yup.  This?

From: Andrew Morton <a...@linux-foundation.org>
Subject: kernel/exit.c: export abort() to modules

gcc -fisolate-erroneous-paths-dereference can generate calls to abort()
from modular code too.

Reported-by: Vineet Gupta <vineet.gup...@synopsys.com>
Cc: Sudip Mukherjee <sudipm.mukher...@gmail.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: "Alexey Brodkin" <alexey.brod...@synopsys.com>
Signed-off-by: Andrew Morton <a...@linux-foundation.org>
---

 kernel/exit.c |1 +
 1 file changed, 1 insertion(+)

diff -puN kernel/exit.c~a kernel/exit.c
--- a/kernel/exit.c~a
+++ a/kernel/exit.c
@@ -1763,3 +1763,4 @@ __weak void abort(void)
/* if that doesn't kill us, halt */
panic("Oops failed to kill thread");
 }
+EXPORT_SYMBOL(abort);
_


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [patch V4] lib: GCD: Use binary GCD algorithm instead of Euclidean

[Andrew Morton]

On Fri,  6 May 2016 17:42:42 +0800 zengzhao...@163.com wrote:

> From: Zhaoxiu Zeng 
> 
> The binary GCD algorithm is based on the following facts:
>   1. If a and b are all evens, then gcd(a,b) = 2 * gcd(a/2, b/2)
>   2. If a is even and b is odd, then gcd(a,b) = gcd(a/2, b)
>   3. If a and b are all odds, then gcd(a,b) = gcd((a-b)/2, b) = 
> gcd((a+b)/2, b)
> 
> Even on x86 machines with reasonable division hardware, the binary
> algorithm runs about 25% faster (80% the execution time) than the
> division-based Euclidian algorithm.
> 
> On platforms like Alpha and ARMv6 where division is a function call to
> emulation code, it's even more significant.
> 
> There are two variants of the code here, depending on whether a
> fast __ffs (find least significant set bit) instruction is available.
> This allows the unpredictable branches in the bit-at-a-time shifting
> loop to be eliminated.
> 
> ...
>
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -27,6 +27,7 @@ config ALPHA
>   select MODULES_USE_ELF_RELA
>   select ODD_RT_SIGACTION
>   select OLD_SIGSUSPEND
> + select CPU_NO_EFFICIENT_FFS if !ALPHA_EV67
>   help

argh.  Please don't always put new items at end-of-list.  That's the
perfect way of maximizing the number of patch collisions.  Insert it at
a random position. avoiding the end (if the list isn't alpha-sorted,
which it should be).



>
> ...
>
> --- a/arch/mips/include/asm/cpu-features.h
> +++ b/arch/mips/include/asm/cpu-features.h
> @@ -180,6 +180,16 @@
>  #endif
>  #endif
>  
> +/* __builtin_constant_p(cpu_has_mips_r) && cpu_has_mips_r */
> +#if !((defined(cpu_has_mips32r1) && cpu_has_mips32r1) || \
> +   (defined(cpu_has_mips32r2) && cpu_has_mips32r2) || \
> +   (defined(cpu_has_mips32r6) && cpu_has_mips32r6) || \
> +   (defined(cpu_has_mips64r1) && cpu_has_mips64r1) || \
> +   (defined(cpu_has_mips64r2) && cpu_has_mips64r2) || \
> +   (defined(cpu_has_mips64r6) && cpu_has_mips64r6))
> +#define CONFIG_CPU_NO_EFFICIENT_FFS 1
> +#endif

#defining a CONFIG_ variable is pretty rude - defining these is the
role of the Kconfig system, not of header files macros.

This was easy:

--- 
a/arch/mips/include/asm/cpu-features.h~lib-gcd-use-binary-gcd-algorithm-instead-of-euclidean-fix
+++ a/arch/mips/include/asm/cpu-features.h
@@ -187,7 +187,7 @@
  (defined(cpu_has_mips64r1) && cpu_has_mips64r1) || \
  (defined(cpu_has_mips64r2) && cpu_has_mips64r2) || \
  (defined(cpu_has_mips64r6) && cpu_has_mips64r6))
-#define CONFIG_CPU_NO_EFFICIENT_FFS 1
+#define CPU_NO_EFFICIENT_FFS 1
 #endif
 
 #ifndef cpu_has_mips_1
--- a/lib/gcd.c~lib-gcd-use-binary-gcd-algorithm-instead-of-euclidean-fix
+++ a/lib/gcd.c
@@ -10,7 +10,7 @@
  * has decent hardware division.
  */
 
-#if !defined(CONFIG_CPU_NO_EFFICIENT_FFS)
+#if !defined(CONFIG_CPU_NO_EFFICIENT_FFS) && !defined(CPU_NO_EFFICIENT_FFS)
 
 /* If __ffs is available, the even/odd algorithm benchmarks slower. */
 unsigned long gcd(unsigned long a, unsigned long b)
_


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc