Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast

[Vineet Gupta]

On 3/28/24 00:15, Mike Rapoport wrote:
> On Thu, Mar 28, 2024 at 07:09:13AM +0100, Arnd Bergmann wrote:
>> On Thu, Mar 28, 2024, at 06:51, Vineet Gupta wrote:
>>> On 3/27/24 09:22, Arnd Bergmann wrote:
>>>> On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote:
>>>>> On 27.03.24 16:21, Peter Xu wrote:
>>>>>> On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote:
>>>>>>
>>>>>> I'm not sure what config you tried there; as I am doing some build tests
>>>>>> recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could
>>>>>> avoid a lot of issues, I think it's due to libc missing.  But maybe not 
>>>>>> the
>>>>>> case there.
>>>>> CCin Arnd; I use some of his compiler chains, others from Fedora 
>>>>> directly. For
>>>>> example for alpha and arc, the Fedora gcc is "13.2.1".
>>>>> But there is other stuff like (arc):
>>>>>
>>>>> ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid':
>>>>> ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of 
>>>>> function 'write_aux_reg' [-Werro
>>>>> r=implicit-function-declaration]
>>>>> 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE);
>>>>>| ^
>>>> Seems to be missing an #include of soc/arc/aux.h, but I can't
>>>> tell when this first broke without bisecting.
>>> Weird I don't see this one but I only have gcc 12 handy ATM.
>>>
>>>     gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain -
>>> build 1360)
>>>
>>> I even tried W=1 (which according to scripts/Makefile.extrawarn) should
>>> include -Werror=implicit-function-declaration but don't see this still.
>>>
>>> Tomorrow I'll try building a gcc 13.2.1 for ARC.
>> David reported them with the toolchains I built at
>> https://mirrors.edge.kernel.org/pub/tools/crosstool/
>> I'm fairly sure the problem is specific to the .config
>> and tree, not the toolchain though.
> This happens with defconfig and both gcc 12.2.0 and gcc 13.2.0 from your
> crosstools. I also see these on the current Linus' tree:
>
> arc/kernel/ptrace.c:342:16: warning: no previous prototype for 
> 'syscall_trace_enter' [-Wmissing-prototypes]
> arch/arc/kernel/kprobes.c:193:15: warning: no previous prototype for 
> 'arc_kprobe_handler' [-Wmissing-prototypes]

Yep these two I could trigger and fix posted [1]

> This fixed the warning about write_aux_reg for me, probably Vineet would
> want this include somewhere else...
>
> diff --git a/arch/arc/include/asm/mmu-arcv2.h 
> b/arch/arc/include/asm/mmu-arcv2.h
> index ed9036d4ede3..0fca342d7b79 100644
> --- a/arch/arc/include/asm/mmu-arcv2.h
> +++ b/arch/arc/include/asm/mmu-arcv2.h
> @@ -69,6 +69,8 @@
>  
>  #ifndef __ASSEMBLY__
>  
> +#include 
> +
>  struct mm_struct;
>  extern int pae40_exist_but_not_enab(void);

Thx Mike. Indeed the fix is trivial but on tip of tree I still can't
trigger the warning to even test anything. I'm at following with my
other fixes.

    2024-03-27 962490525cff Merge tag 'probes-fixes-v6.9-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace  

I tried defconfig build as well as the exact config from Linaro report
[2], and/or various toolchains: from snps github, Arnd's crosstool
toolchain.
Granted all of these are linux toolchains - I vaguely remember at some
time, baremetal elf32 toolchain behaved differently due to different
defaults etc.
I have a feeling this was something transient which got fixed up due to
order of header includes etc.

Anyone in the followup email David only reported 2 warnings which have
been tended to as mentioned above - will be sent to Linus soon.

[1]
http://lists.infradead.org/pipermail/linux-snps-arc/2024-March/007916.html
[2]
https://storage.tuxsuite.com/public/linaro/lkft/builds/2eA2VSZdDsL0DMBBhjoauN9IVoK/

Thx,
-Vineet

Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast

[Vineet Gupta]

+CC Alexey

On 3/27/24 09:22, Arnd Bergmann wrote:
> On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote:
>> On 27.03.24 16:21, Peter Xu wrote:
>>> On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote:
>>>
>>> I'm not sure what config you tried there; as I am doing some build tests
>>> recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could
>>> avoid a lot of issues, I think it's due to libc missing.  But maybe not the
>>> case there.
>> CCin Arnd; I use some of his compiler chains, others from Fedora directly. 
>> For
>> example for alpha and arc, the Fedora gcc is "13.2.1".
>> But there is other stuff like (arc):
>>
>> ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid':
>> ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of 
>> function 'write_aux_reg' [-Werro
>> r=implicit-function-declaration]
>> 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE);
>>| ^
> Seems to be missing an #include of soc/arc/aux.h, but I can't
> tell when this first broke without bisecting.

Weird I don't see this one but I only have gcc 12 handy ATM.

    gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain -
build 1360)

I even tried W=1 (which according to scripts/Makefile.extrawarn) should
include -Werror=implicit-function-declaration but don't see this still.

Tomorrow I'll try building a gcc 13.2.1 for ARC.


>
>> or (alpha)
>>
>> WARNING: modpost: "saved_config" [vmlinux] is COMMON symbol
>> ERROR: modpost: "memcpy" [fs/reiserfs/reiserfs.ko] undefined!
>> ERROR: modpost: "memcpy" [fs/nfs/nfs.ko] undefined!
>> ERROR: modpost: "memcpy" [fs/nfs/nfsv3.ko] undefined!
>> ERROR: modpost: "memcpy" [fs/nfsd/nfsd.ko] undefined!
>> ERROR: modpost: "memcpy" [fs/lockd/lockd.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/crypto.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/crypto_algapi.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/aead.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/crypto_skcipher.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/seqiv.ko] undefined!

Are these from ARC build or otherwise ?

Thx,
-Vineet

Re: [PATCH 13/21] arc: dma-mapping: skip invalidating before bidirectional DMA

[Vineet Gupta]

CC Shahab

On 3/27/23 17:43, Arnd Bergmann wrote:

From: Arnd Bergmann

Some architectures that need to invalidate buffers after bidirectional
DMA because of speculative prefetching only do a simpler writeback
before that DMA, while architectures that don't need to do the second
invalidate tend to have a combined writeback+invalidate before the
DMA.

arc is one of the architectures that does both, which seems unnecessary.

Change it to behave like arm/arm64/xtensa instead, and use just a
writeback before the DMA when we do the invalidate afterwards.

Signed-off-by: Arnd Bergmann


Reviewed-by: Vineet Gupta 

Shahab can you give this a spin on hsdk - run glibc testsuite over ssh 
and make sure nothing strange happens.


Thx,
-Vineet

Re: [PATCH v3 4/4] arc: Use generic dump_stack_print_cmdline() implementation

[Vineet Gupta]

On 8/8/22 06:09, Helge Deller wrote:

The process program name and command line is now shown in generic code
in dump_stack_print_info(), so drop the arc-specific implementation.

Signed-off-by: Helge Deller 


But that info printing was added back in 2018 by e36df28f532f882.
I don't think arc is using show_regs_print_info -> dump_stack_print_info 
yet.

Or is there a different code path now which calls here ?


---
  arch/arc/kernel/troubleshoot.c | 24 
  1 file changed, 24 deletions(-)

diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c
index 7654c2e42dc0..9807e590ee55 100644
--- a/arch/arc/kernel/troubleshoot.c
+++ b/arch/arc/kernel/troubleshoot.c
@@ -51,29 +51,6 @@ static void print_regs_callee(struct callee_regs *regs)
regs->r24, regs->r25);
  }

-static void print_task_path_n_nm(struct task_struct *tsk)
-{
-   char *path_nm = NULL;
-   struct mm_struct *mm;
-   struct file *exe_file;
-   char buf[ARC_PATH_MAX];
-
-   mm = get_task_mm(tsk);
-   if (!mm)
-   goto done;
-
-   exe_file = get_mm_exe_file(mm);
-   mmput(mm);
-
-   if (exe_file) {
-   path_nm = file_path(exe_file, buf, ARC_PATH_MAX-1);
-   fput(exe_file);
-   }
-
-done:
-   pr_info("Path: %s\n", !IS_ERR(path_nm) ? path_nm : "?");
-}
-
  static void show_faulting_vma(unsigned long address)
  {
struct vm_area_struct *vma;
@@ -176,7 +153,6 @@ void show_regs(struct pt_regs *regs)
 */
preempt_enable();


Maybe we remove preempt* as well now (perhaps as a follow up patch) 
since that was added by f731a8e89f8c78 "ARC: show_regs: lockdep: 
re-enable preemption" where show_regs -> print_task_path_n_nm -> mmput 
was triggering lockdep splat which is supposedly removed.




-   print_task_path_n_nm(tsk);
show_regs_print_info(KERN_INFO);

show_ecr_verbose(regs);
--
2.37.1


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

Re: [PATCH RESEND v9 1/5] arc: dts: Harmonize EHCI/OHCI DT nodes name

[Vineet Gupta]

On 6/24/22 07:16, Serge Semin wrote:

In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?"  . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.

Signed-off-by: Serge Semin
Acked-by: Alexey Brodkin
Acked-by: Krzysztof Kozlowski


This slipped thru cracks. Now on for-curr.

Thx,
-Vineet

Re: [PATCH v3] mm: Avoid unnecessary page fault retires on shared memory types

[Vineet Gupta]

nkel , Michal Simek , Thomas Bogendoerfer , 
linux-par...@vger.kernel.org, linux-m...@vger.kernel.org, Dinh Nguyen , Palmer Dabbelt , Sven 
Schnelle , Guo Ren , Borislav Petkov , Johannes Berg 
, linuxppc-dev@lists.ozlabs.org, "David S . Miller" 
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 




On 5/24/22 16:45, Peter Xu wrote:

I observed that for each of the shared file-backed page faults, we're very
likely to retry one more time for the 1st write fault upon no page.  It's
because we'll need to release the mmap lock for dirty rate limit purpose
with balance_dirty_pages_ratelimited() (in fault_dirty_shared_page()).

Then after that throttling we return VM_FAULT_RETRY.

We did that probably because VM_FAULT_RETRY is the only way we can return
to the fault handler at that time telling it we've released the mmap lock.

However that's not ideal because it's very likely the fault does not need
to be retried at all since the pgtable was well installed before the
throttling, so the next continuous fault (including taking mmap read lock,
walk the pgtable, etc.) could be in most cases unnecessary.

It's not only slowing down page faults for shared file-backed, but also add
more mmap lock contention which is in most cases not needed at all.

To observe this, one could try to write to some shmem page and look at
"pgfault" value in /proc/vmstat, then we should expect 2 counts for each
shmem write simply because we retried, and vm event "pgfault" will capture
that.

To make it more efficient, add a new VM_FAULT_COMPLETED return code just to
show that we've completed the whole fault and released the lock.  It's also
a hint that we should very possibly not need another fault immediately on
this page because we've just completed it.

This patch provides a ~12% perf boost on my aarch64 test VM with a simple
program sequentially dirtying 400MB shmem file being mmap()ed and these are
the time it needs:

   Before: 650.980 ms (+-1.94%)
   After:  569.396 ms (+-1.38%)

I believe it could help more than that.

We need some special care on GUP and the s390 pgfault handler (for gmap
code before returning from pgfault), the rest changes in the page fault
handlers should be relatively straightforward.

Another thing to mention is that mm_account_fault() does take this new
fault as a generic fault to be accounted, unlike VM_FAULT_RETRY.

I explicitly didn't touch hmm_vma_fault() and break_ksm() because they do
not handle VM_FAULT_RETRY even with existing code, so I'm literally keeping
them as-is.

Signed-off-by: Peter Xu
---

v3:
- Rebase to akpm/mm-unstable
- Copy arch maintainers
---
   arch/arc/mm/fault.c   |  4 


Acked-by: Vineet Gupta 

Thx,
-Vineet

Re: [PATCH -next] trap: Cleanup trap_init()

[Vineet Gupta]

On 8/12/21 5:36 AM, Kefeng Wang wrote:

There are some empty trap_init() in different ARCHs, introduce
a new weak trap_init() function to cleanup them.

Cc: Vineet Gupta
Cc: Russell King
Cc: Yoshinori Sato
Cc: Ley Foon Tan
Cc: Jonas Bonn
Cc: Stefan Kristiansson
Cc: Stafford Horne
Cc: James E.J. Bottomley
Cc: Helge Deller
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Paul Walmsley
Cc: Jeff Dike
Cc: Richard Weinberger
Cc: Anton Ivanov
Cc: Andrew Morton
Signed-off-by: Kefeng Wang
---
  arch/arc/kernel/traps.c  | 5 -


Acked-by: Vineet Gupta   #arch/arc

Re: [PATCH 2/3] trace: refactor TRACE_IRQFLAGS_SUPPORT in Kconfig

[Vineet Gupta]

On 7/30/21 10:22 PM, Masahiro Yamada wrote:
> Make architectures select TRACE_IRQFLAGS_SUPPORT instead of
> having many defines.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>   arch/arc/Kconfig  | 4 +---
> [snip..]


Acked-by: Vineet Gupta    #arch/arc

Re: [PATCH v2 2/9] arc: update comment about HIGHMEM implementation

[Vineet Gupta]

On 6/3/21 11:49 PM, Mike Rapoport wrote:
> From: Mike Rapoport 
>
> Arc does not use DISCONTIGMEM to implement high memory, update the comment
> describing how high memory works to reflect this.
>
> Signed-off-by: Mike Rapoport 

Acked-by: Vineet Gupta 

Thx,
-Vineet

> ---
>   arch/arc/mm/init.c | 13 +
>   1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index e2ed355438c9..397a201adfe3 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -139,16 +139,13 @@ void __init setup_arch_memory(void)
>   
>   #ifdef CONFIG_HIGHMEM
>   /*
> -  * Populate a new node with highmem
> -  *
>* On ARC (w/o PAE) HIGHMEM addresses are actually smaller (0 based)
> -  * than addresses in normal ala low memory (0x8000_ based).
> +  * than addresses in normal aka low memory (0x8000_ based).
>* Even with PAE, the huge peripheral space hole would waste a lot of
> -  * mem with single mem_map[]. This warrants a mem_map per region design.
> -  * Thus HIGHMEM on ARC is imlemented with DISCONTIGMEM.
> -  *
> -  * DISCONTIGMEM in turns requires multiple nodes. node 0 above is
> -  * populated with normal memory zone while node 1 only has highmem
> +  * mem with single contiguous mem_map[].
> +  * Thus when HIGHMEM on ARC is enabled the memory map corresponding
> +  * to the hole is freed and ARC specific version of pfn_valid()
> +  * handles the hole in the memory map.
>*/
>   #ifdef CONFIG_DISCONTIGMEM
>   node_set_online(1);

Re: [PATCH v2 3/9] arc: remove support for DISCONTIGMEM

[Vineet Gupta]

On 6/3/21 11:49 PM, Mike Rapoport wrote:
> From: Mike Rapoport 
>
> DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
> in v5.11.
>
> Remove the support for DISCONTIGMEM entirely.
>
> Signed-off-by: Mike Rapoport 

Looks non intrusive, but I'd still like to give this a spin on hardware 
- considering highmem on ARC has tendency to go sideways ;-)
Can you please share a branch !

Acked-by: Vineet Gupta 

Thx,
-Vineet

> ---
>   arch/arc/Kconfig  | 13 
>   arch/arc/include/asm/mmzone.h | 40 ---
>   arch/arc/mm/init.c|  8 ---
>   3 files changed, 61 deletions(-)
>   delete mode 100644 arch/arc/include/asm/mmzone.h
>
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 2d98501c0897..d8f51eb8963b 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -62,10 +62,6 @@ config SCHED_OMIT_FRAME_POINTER
>   config GENERIC_CSUM
>   def_bool y
>   
> -config ARCH_DISCONTIGMEM_ENABLE
> - def_bool n
> - depends on BROKEN
> -
>   config ARCH_FLATMEM_ENABLE
>   def_bool y
>   
> @@ -344,15 +340,6 @@ config ARC_HUGEPAGE_16M
>   
>   endchoice
>   
> -config NODES_SHIFT
> - int "Maximum NUMA Nodes (as a power of 2)"
> - default "0" if !DISCONTIGMEM
> - default "1" if DISCONTIGMEM
> - depends on NEED_MULTIPLE_NODES
> - help
> -   Accessing memory beyond 1GB (with or w/o PAE) requires 2 memory
> -   zones.
> -
>   config ARC_COMPACT_IRQ_LEVELS
>   depends on ISA_ARCOMPACT
>   bool "Setup Timer IRQ as high Priority"
> diff --git a/arch/arc/include/asm/mmzone.h b/arch/arc/include/asm/mmzone.h
> deleted file mode 100644
> index b86b9d1e54dc..
> --- a/arch/arc/include/asm/mmzone.h
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -/*
> - * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
> - */
> -
> -#ifndef _ASM_ARC_MMZONE_H
> -#define _ASM_ARC_MMZONE_H
> -
> -#ifdef CONFIG_DISCONTIGMEM
> -
> -extern struct pglist_data node_data[];
> -#define NODE_DATA(nid) (_data[nid])
> -
> -static inline int pfn_to_nid(unsigned long pfn)
> -{
> - int is_end_low = 1;
> -
> - if (IS_ENABLED(CONFIG_ARC_HAS_PAE40))
> - is_end_low = pfn <= virt_to_pfn(0xUL);
> -
> - /*
> -  * node 0: lowmem: 0x8000_   to 0x_
> -  * node 1: HIGHMEM w/o  PAE40: 0x0   to 0x7FFF_
> -  * HIGHMEM with PAE40: 0x1__ to ...
> -  */
> - if (pfn >= ARCH_PFN_OFFSET && is_end_low)
> - return 0;
> -
> - return 1;
> -}
> -
> -static inline int pfn_valid(unsigned long pfn)
> -{
> - int nid = pfn_to_nid(pfn);
> -
> - return (pfn <= node_end_pfn(nid));
> -}
> -#endif /* CONFIG_DISCONTIGMEM  */
> -
> -#endif
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 397a201adfe3..abfeef7bf6f8 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -32,11 +32,6 @@ unsigned long arch_pfn_offset;
>   EXPORT_SYMBOL(arch_pfn_offset);
>   #endif
>   
> -#ifdef CONFIG_DISCONTIGMEM
> -struct pglist_data node_data[MAX_NUMNODES] __read_mostly;
> -EXPORT_SYMBOL(node_data);
> -#endif
> -
>   long __init arc_get_mem_sz(void)
>   {
>   return low_mem_sz;
> @@ -147,9 +142,6 @@ void __init setup_arch_memory(void)
>* to the hole is freed and ARC specific version of pfn_valid()
>* handles the hole in the memory map.
>*/
> -#ifdef CONFIG_DISCONTIGMEM
> - node_set_online(1);
> -#endif
>   
>   min_high_pfn = PFN_DOWN(high_mem_start);
>   max_high_pfn = PFN_DOWN(high_mem_start + high_mem_sz);

Re: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

[Vineet Gupta]

On 5/14/21 12:22 PM, Linus Torvalds wrote:
> On Fri, May 14, 2021 at 11:52 AM Vineet Gupta
>  wrote:
>> Wasn't the new zlib code slated for 5.14. I don't see it in your master yet
> You're right, I never actually committed it, since it was specific to
> ARC and -O3

Well, not really, the issue manifested in ARC O3 testing, but I showed 
the problem existed for arm64 gcc too.

> and I wasn't entirely happy with the amount of testing it
> got (with Heiko pointing out that the s390 stuff needed more fixes for
> the change).

With his addon patch everything seemed hunky dory.

> The patch below is required on top of your patch to make it compile
> for s390 as well.
> Tested with kernel image decompression, and also btrfs with file
> compression; both software and hardware compression.
> Everything seems to work.

> So in fact it's not even queued up for 5.14 due to this all, I just dropped 
> it.

But Why. Can't we throw it in linux-next for 5.14. I promise to test it 
- and will likely hit any corner cases. Also for the time being we could 
force just that file/files to build for -O3 to stress test the aspects 
that were fragile.

>>>and the biggy
>>> case didn't even use "get_unaligned()").
>> Indeed this series is sort of orthogonal to that bug, but IMO that bug
>> still exists in 5.13 for -O3 build, granted that is not enabled for !ARC.
> Right, the zlib bug is still there.
>
> But Arnd's series wouldn't even fix it: right now inffast has its own
> - ugly and slow - special 2-byte-only version of "get_unaligned()",
> called "get_unaligned16()".

I know that's why said they are orthogonal.


> And because it's ugly and slow, it's not actually used for
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
>
> Vineet - maybe the fix is to not take my patch to update to a newer
> zlib, but to just fix inffast to use the proper get_unaligned(). Then
> Arnd's series _would_ actually fix all this..

OK if you say so.

-Vineet

Re: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

[Vineet Gupta]

On 5/14/21 10:32 AM, Linus Torvalds wrote:
> On Fri, May 14, 2021 at 3:02 AM Arnd Bergmann  wrote:
>> I've included this version in the asm-generic tree for 5.14 already,
>> addressing the few issues that were pointed out in the RFC. If there
>> are any remaining problems, I hope those can be addressed as follow-up
>> patches.
> This continues to look great to me, and now has the even simpler
> remaining implementation.
>
> I'd be tempted to just pull it in for 5.13, but I guess we don't
> actually have any _outstanding_ bug in this area (the bug was in our
> zlib code, required -O3 to trigger, has been fixed now,

Wasn't the new zlib code slated for 5.14. I don't see it in your master yet

>   and the biggy
> case didn't even use "get_unaligned()").

Indeed this series is sort of orthogonal to that bug, but IMO that bug 
still exists in 5.13 for -O3 build, granted that is not enabled for !ARC.

-Vineet

>
> So I guess your 5.14 timing is the right thing to do.
>
>  Linus

Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems

[Vineet Gupta]

On 4/20/21 12:07 AM, Arnd Bergmann wrote:
> On Tue, Apr 20, 2021 at 5:10 AM Matthew Wilcox  wrote:
>> On Tue, Apr 20, 2021 at 02:48:17AM +0000, Vineet Gupta wrote:
>>>> 32-bit architectures which expect 8-byte alignment for 8-byte integers
>>>> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
>>>> page inadvertently expanded in 2019.
>>> FWIW, ARC doesn't require 8 byte alignment for 8 byte integers. This is
>>> only needed for 8-byte atomics due to the requirements of LLOCKD/SCOND
>>> instructions.
>> Ah, like x86?  OK, great, I'll drop your arch from the list of
>> affected.  Thanks!
> I mistakenly assumed that i386 and m68k were the only supported
> architectures with 32-bit alignment on u64. I checked it now and found
>
> $ for i in /home/arnd/cross/x86_64/gcc-10.1.0-nolibc/*/bin/*-gcc ; do
> echo `echo 'int a = __alignof__(long long);' | $i -xc - -Wall -S -o- |
> grep -A1 a: | tail -n 1 | cut -f 3 -d\   `
> ${i#/home/arnd/cross/x86_64/gcc-10.1.0-nolibc/*/bin/} ; done
> 8 aarch64-linux-gcc
> 8 alpha-linux-gcc
> 4 arc-linux-gcc
> 8 arm-linux-gnueabi-gcc
> 8 c6x-elf-gcc
> 4 csky-linux-gcc
> 4 h8300-linux-gcc
> 8 hppa-linux-gcc
> 8 hppa64-linux-gcc
> 8 i386-linux-gcc
> 8 ia64-linux-gcc
> 2 m68k-linux-gcc
> 4 microblaze-linux-gcc
> 8 mips-linux-gcc
> 8 mips64-linux-gcc
> 8 nds32le-linux-gcc
> 4 nios2-linux-gcc
> 4 or1k-linux-gcc
> 8 powerpc-linux-gcc
> 8 powerpc64-linux-gcc
> 8 riscv32-linux-gcc
> 8 riscv64-linux-gcc
> 8 s390-linux-gcc
> 4 sh2-linux-gcc
> 4 sh4-linux-gcc
> 8 sparc-linux-gcc
> 8 sparc64-linux-gcc
> 8 x86_64-linux-gcc
> 8 xtensa-linux-gcc
>
> which means that half the 32-bit architectures do this. This may
> cause more problems when arc and/or microblaze want to support
> 64-bit kernels and compat mode in the future on their latest hardware,
> as that means duplicating the x86 specific hacks we have for compat.
>
> What is alignof(u64) on 64-bit arc?

$ echo 'int a = __alignof__(long long);' | arc64-linux-gnu-gcc -xc - 
-Wall -S -o - | grep -A1 a: | tail -n 1 | cut -f 3
8

Yeah ARCv2 alignment of 4 for 64-bit data was a bit of surprise finding 
for me as well. When 64-bit load/stores were initially targeted by the 
internal Metaware compiler (llvm based) they decided to keep alignment 
to 4 still (granted hardware allowed this) and then gcc guys decided to 
follow the same ABI. I only found this by accident :-)

Can you point me to some specifics on the compat issue. For better of 
worse, arc64 does''t have a compat 32-bit mode, so everything is 
64-on-64 or 32-on-32 (ARC32 flavor of ARCv3)

Thx,
-Vineet

Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems

[Vineet Gupta]

Hi Matthew,

On 4/16/21 7:45 PM, Matthew Wilcox wrote:
> Replacement patch to fix compiler warning.
>
> From: "Matthew Wilcox (Oracle)" 
> Date: Fri, 16 Apr 2021 16:34:55 -0400
> Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
> To: bro...@redhat.com
> Cc: linux-ker...@vger.kernel.org,
>  linux...@kvack.org,
>  net...@vger.kernel.org,
>  linuxppc-dev@lists.ozlabs.org,
>  linux-arm-ker...@lists.infradead.org,
>  linux-m...@vger.kernel.org,
>  ilias.apalodi...@linaro.org,
>  mcr...@linux.microsoft.com,
>  grygorii.stras...@ti.com,
>  a...@kernel.org,
>  h...@lst.de,
>  linux-snps-...@lists.infradead.org,
>  mho...@kernel.org,
>  mgor...@suse.de
>
> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019.

FWIW, ARC doesn't require 8 byte alignment for 8 byte integers. This is 
only needed for 8-byte atomics due to the requirements of LLOCKD/SCOND 
instructions.

> When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
>
> Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
> This restores the alignment to that of an unsigned long, and also fixes a
> potential problem where (on a big endian platform), the bit used to denote
> PageTail could inadvertently get set, and a racing get_user_pages_fast()
> could dereference a bogus compound_head().
>
> Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> Signed-off-by: Matthew Wilcox (Oracle) 
> ---
>   include/linux/mm_types.h |  4 ++--
>   include/net/page_pool.h  | 12 +++-
>   net/core/page_pool.c | 12 +++-
>   3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6613b26a8894..5aacc1c10a45 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -97,10 +97,10 @@ struct page {
>   };
>   struct {/* page_pool used by netstack */
>   /**
> -  * @dma_addr: might require a 64-bit value even on
> +  * @dma_addr: might require a 64-bit value on
>* 32-bit architectures.
>*/
> - dma_addr_t dma_addr;
> + unsigned long dma_addr[2];
>   };
>   struct {/* slab, slob and slub */
>   union {
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..ad6154dc206c 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct 
> page_pool *pool,
>   
>   static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>   {
> - return page->dma_addr;
> + dma_addr_t ret = page->dma_addr[0];
> + if (sizeof(dma_addr_t) > sizeof(unsigned long))
> + ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;
> + return ret;
> +}
> +
> +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> +{
> + page->dma_addr[0] = addr;
> + if (sizeof(dma_addr_t) > sizeof(unsigned long))
> + page->dma_addr[1] = addr >> 16 >> 16;
>   }
>   
>   static inline bool is_page_pool_compiled_in(void)
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index ad8b0707af04..f014fd8c19a6 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
> @@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct 
> page_pool *pool,
> struct page *page,
> unsigned int dma_sync_size)
>   {
> + dma_addr_t dma_addr = page_pool_get_dma_addr(page);
> +
>   dma_sync_size = min(dma_sync_size, pool->p.max_len);
> - dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
> + dma_sync_single_range_for_device(pool->p.dev, dma_addr,
>pool->p.offset, dma_sync_size,
>pool->p.dma_dir);
>   }
> @@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct 
> page_pool *pool,
>   put_page(page);
>   return NULL;
>   }
> - page->dma_addr = dma;
> + page_pool_set_dma_addr(page, dma);
>   
>   if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
>   page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
> @@ -294,13 +296,13 @@ void page_pool_release_page(struct page_pool *pool, 
> struct page *page)
>*/
>   goto skip_dma_unmap;
>   
> - dma = page->dma_addr;
> + dma = page_pool_get_dma_addr(page);
>   
> - /* When page is unmapped, it cannot be returned our pool */
> + /* When page is unmapped, it cannot be 

Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()

[Vineet Gupta]

On 3/16/21 6:52 PM, Kefeng Wang wrote:
> mem_init_print_info() is called in mem_init() on each architecture,
> and pass NULL argument, so using void argument and move it into mm_init().
> 
> Acked-by: Dave Hansen 
> Signed-off-by: Kefeng Wang 

Acked-by: Vineet Gupta 

Thx,
-Vineet

Re: [PATCH v2 17/20] mm: free_area_init: allow defining max_zone_pfn in descending order

[Vineet Gupta]

On 5/5/20 6:18 AM, Guenter Roeck wrote:
> On 5/4/20 8:39 AM, Mike Rapoport wrote:
>> On Sun, May 03, 2020 at 11:43:00AM -0700, Guenter Roeck wrote:
>>> On Sun, May 03, 2020 at 10:41:38AM -0700, Guenter Roeck wrote:
 Hi,

 On Wed, Apr 29, 2020 at 03:11:23PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport 
>
> Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
> ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is
> sorted in descending order allows using free_area_init() on such
> architectures.
>
> Add top -> down traversal of max_zone_pfn array in free_area_init() and 
> use
> the latter in ARC node/zone initialization.
>
> Signed-off-by: Mike Rapoport 
 This patch causes my microblazeel qemu boot test in linux-next to fail.
 Reverting it fixes the problem.

>>> The same problem is seen with s390 emulations.
>> Yeah, this patch breaks some others as well :(
>>
>> My assumption that max_zone_pfn defines architectural limit for maximal
>> PFN that can belong to a zone was over-optimistic. Several arches
>> actually do that, but others do
>>
>>  max_zone_pfn[ZONE_DMA] = MAX_DMA_PFN;
>>  max_zone_pfn[ZONE_NORMAL] = max_pfn;
>>
>> where MAX_DMA_PFN is build-time constrain and max_pfn is run time limit
>> for the current system.
>>
>> So, when max_pfn is lower than MAX_DMA_PFN, the free_init_area() will
>> consider max_zone_pfn as descending and will wrongly calculate zone
>> extents.
>>
>> That said, instead of trying to create a generic way to special case
>> ARC, I suggest to simply use the below patch instead.
>>
> As a reminder, I reported the problem against s390 and microblazeel
> (interestingly enough, microblaze (big endian) works), not against arc.

Understood and my comment was to point to any other problems in future.

Thx,
-Vineet

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

[Vineet Gupta]

On 1/27/20 7:33 PM, Qian Cai wrote:
>
>>> What’s the value of this block of new code? It only supports x86 and arm64
>>> which are supposed to be good now.
>> We have been over the usefulness of this code many times before as the patch 
>> is
>> already in it's V12. Currently it is enabled on arm64, x86 (except PAE), arc 
>> and
>> ppc32. There are build time or runtime problems with other archs which 
>> prevent
> I am not sure if I care too much about arc and ppc32 which are pretty much 
> legacy
> platforms.

You really need to brush up on your definition and knowledge of what "legacy" 
means.
ARC is actively maintained and used by several customers, some in arch/arc/plat*
and some not in there.
It is present in broadband routers used by major ISP, massively multicore deep
packet inspection system from EZChip, and many more

Sure you may not care about them, but the maintainers for the platforms do.
It would have been better if you had spent the time and energy in improving the
code over 12 revisions rather than bike shedding.

-Vineet

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

[Vineet Gupta]

On 11/7/19 8:27 PM, Anshuman Khandual wrote:
>
> On 11/08/2019 12:35 AM, Vineet Gupta wrote:
>> On 11/6/19 8:44 PM, Anshuman Khandual wrote:
>>>>>   */
>>>>> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>>> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE
>>>>>  #include 
>>>>>  #endif
>>>> This in wrong.  CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE is a just a glue 
>>>> toggle,
>>>> used only in Kconfig files (and not in any "C" code).  It enables generic 
>>>> Kconfig
>>>> code to allow visibility of CONFIG_TRANSPARENT_HUGEPAGE w/o every arch 
>>>> needing to
>>>> do a me too.
>>>>
>>>> I think you need to use CONFIG_TRANSPARENT_HUGEPAGE to guard appropriate 
>>>> tests. I
>>>> understand that it only
>>> We can probably replace CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE wrapper with
>>> CONFIG_TRANSPARENT_HUGEPAGE. But CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>>> explicitly depends on CONFIG_TRANSPARENT_HUGEPAGE as a prerequisite. Could
>>> you please confirm if the following change on this test will work on ARC
>>> platform for both THP and !THP cases ? Thank you.
>>>
>>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
>>> index 621ac09..99ebc7c 100644
>>> --- a/mm/debug_vm_pgtable.c
>>> +++ b/mm/debug_vm_pgtable.c
>>> @@ -67,7 +67,7 @@ static void __init pte_basic_tests(unsigned long pfn, 
>>> pgprot_t prot)
>>> WARN_ON(pte_write(pte_wrprotect(pte)));
>>>  }
>>>  
>>> -#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE
>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>  static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
>>>  {
>>> pmd_t pmd = pfn_pmd(pfn, prot);
>>> @@ -85,9 +85,6 @@ static void __init pmd_basic_tests(unsigned long pfn, 
>>> pgprot_t prot)
>>>  */
>>> WARN_ON(!pmd_bad(pmd_mkhuge(pmd)));
>>>  }
>>> -#else
>>> -static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot) { }
>>> -#endif
>>>  
>>>  #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>>>  static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot)
>>> @@ -112,6 +109,10 @@ static void __init pud_basic_tests(unsigned long pfn, 
>>> pgprot_t prot)
>>>  #else
>>>  static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
>>>  #endif
>>> +#else
>>> +static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot) { }
>>> +static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
>>> +#endif
>> Fails to build for THP case since
>>
>> CONFIG_TRANSPARENT_HUGEPAGE=y
>> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=n
>>
>> ../mm/debug_vm_pgtable.c:112:20: error: redefinition of ‘pmd_basic_tests’
>>
> Hmm, really ? With arm64 defconfig we have the same default combination
> where it builds.
>
> CONFIG_TRANSPARENT_HUGEPAGE=y
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=n   /* It should not even appear */
>
> With the above change, we have now
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
> {
> 
> 
> }
>
> #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot)
> {
> 
> 
> }
> #else /* !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
> static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
> #endif
> #else /* !CONFIG_TRANSPARENT_HUGEPAGE */
> static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot) { }
> static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
> #endif
>
> When !CONFIG_TRANSPARENT_HUGEPAGE
>
> - Dummy definitions for pmd_basic_tests() and pud_basic_tests()
>
> When CONFIG_TRANSPARENT_HUGEPAGE and 
> !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>
> - Actual pmd_basic_tests() and dummy pud_basic_tests()
>
> When CONFIG_TRANSPARENT_HUGEPAGE and CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>
> - Actual pmd_basic_tests() and pud_basic_tests()
>
> Tested this on arm64 which does not have 
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> for THP and !THP and on x86 which has 
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> for THP and !THP which basically covered all combination for these configs.
>
> Is there something I am still missing in plain sight :)

Sorry my bad. I applied your manual hunk mindlessly and missed the nested #else.
So indeed it works. Although the stub for pud_basic_tests() is now defined twice
which makes it a bit ugly. But I'll leave that to you.

Thx,
-Vineet

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

[Vineet Gupta]

On 11/6/19 8:44 PM, Anshuman Khandual wrote:
>
>>
>>>   */
>>> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE
>>>  #include 
>>>  #endif
>> This in wrong.  CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE is a just a glue 
>> toggle,
>> used only in Kconfig files (and not in any "C" code).  It enables generic 
>> Kconfig
>> code to allow visibility of CONFIG_TRANSPARENT_HUGEPAGE w/o every arch 
>> needing to
>> do a me too.
>>
>> I think you need to use CONFIG_TRANSPARENT_HUGEPAGE to guard appropriate 
>> tests. I
>> understand that it only
> We can probably replace CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE wrapper with
> CONFIG_TRANSPARENT_HUGEPAGE. But CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> explicitly depends on CONFIG_TRANSPARENT_HUGEPAGE as a prerequisite. Could
> you please confirm if the following change on this test will work on ARC
> platform for both THP and !THP cases ? Thank you.
>
> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
> index 621ac09..99ebc7c 100644
> --- a/mm/debug_vm_pgtable.c
> +++ b/mm/debug_vm_pgtable.c
> @@ -67,7 +67,7 @@ static void __init pte_basic_tests(unsigned long pfn, 
> pgprot_t prot)
>   WARN_ON(pte_write(pte_wrprotect(pte)));
>  }
>  
> -#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
>  {
>   pmd_t pmd = pfn_pmd(pfn, prot);
> @@ -85,9 +85,6 @@ static void __init pmd_basic_tests(unsigned long pfn, 
> pgprot_t prot)
>*/
>   WARN_ON(!pmd_bad(pmd_mkhuge(pmd)));
>  }
> -#else
> -static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot) { }
> -#endif
>  
>  #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>  static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot)
> @@ -112,6 +109,10 @@ static void __init pud_basic_tests(unsigned long pfn, 
> pgprot_t prot)
>  #else
>  static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
>  #endif
> +#else
> +static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot) { }
> +static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
> +#endif

Fails to build for THP case since

CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=n

../mm/debug_vm_pgtable.c:112:20: error: redefinition of ‘pmd_basic_tests’

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

[Vineet Gupta]

On 11/5/19 7:03 PM, Anshuman Khandual wrote:
> But should not pfn_pmd() be encapsulated inside HAVE_ARCH_TRANSPARENT_HUGEPAGE
> at the minimum (but I would say it should be available always, nonetheless) 
> when
> the platform subscribes to THP irrespective of whether THP is enabled or not.

For ARC it was only introduced/needed when I added THP support so it is 
dependent
in some way.

> I could see in the file (arch/arc/include/asm/pgtable.h) that fetching 
> pfn_pmd()
> and all other basic PMD definitions is conditional on 
> CONFIG_TRANSPARENT_HUGEPAGE.
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> #include 
> #endif
>
> IIUC, CONFIG_TRANSPARENT_HUGEPAGE should only encapsulate PMD page table 
> helpers
> which are expected from generic THP code (pmd_trans_huge, 
> pmdp_set_access_flags
> etc) but not the basic PMD helpers like pmd_pfn, pmd_mkyoung, pmd_mkdirty,
> pmd_mkclean etc. 

ARC only has 2 levels of paging, so these don't make any sense in general and
needed only for THP case.
I case of arch/arm you see it is only defined in pgtable-3level.h

> Hence wondering will it be possible to accommodate following
> code change on arc platform (not even compiled) in order to fix the problem ?

I'm open to making changes in ARC code but lets do the right thing.

>   */
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE
>  #include 
>  #endif

This in wrong.  CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE is a just a glue toggle,
used only in Kconfig files (and not in any "C" code).  It enables generic 
Kconfig
code to allow visibility of CONFIG_TRANSPARENT_HUGEPAGE w/o every arch needing 
to
do a me too.

I think you need to use CONFIG_TRANSPARENT_HUGEPAGE to guard appropriate tests. 
I
understand that it only

-Vineet

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

[Vineet Gupta]

Hi Anshuman,

On 11/4/19 4:00 PM, Anshuman Khandual wrote:
> On 10/28/2019 10:59 AM, Anshuman Khandual wrote:
>> This adds tests which will validate architecture page table helpers and
>> other accessors in their compliance with expected generic MM semantics.
>> This will help various architectures in validating changes to existing
>> page table helpers or addition of new ones.
>>
>> This test covers basic page table entry transformations including but not
>> limited to old, young, dirty, clean, write, write protect etc at various
>> level along with populating intermediate entries with next page table page
>> and validating them.
>>
>> Test page table pages are allocated from system memory with required size
>> and alignments. The mapped pfns at page table levels are derived from a
>> real pfn representing a valid kernel text symbol. This test gets called
>> right after page_alloc_init_late().
>>
>> This gets build and run when CONFIG_DEBUG_VM_PGTABLE is selected along with
>> CONFIG_VM_DEBUG. Architectures willing to subscribe this test also need to
>> select CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE which for now is limited to x86 and
>> arm64. Going forward, other architectures too can enable this after fixing
>> build or runtime problems (if any) with their page table helpers.
>>
>> Folks interested in making sure that a given platform's page table helpers
>> conform to expected generic MM semantics should enable the above config
>> which will just trigger this test during boot. Any non conformity here will
>> be reported as an warning which would need to be fixed. This test will help
>> catch any changes to the agreed upon semantics expected from generic MM and
>> enable platforms to accommodate it thereafter.
>>

I tried enabling this on ARC and ran into a build issue

../mm/debug_vm_pgtable.c: In function ‘pmd_basic_tests’:
../mm/debug_vm_pgtable.c:73:14: error: implicit declaration of function 
‘pfn_pmd’;
did you mean ‘pfn_pte’? [-Werror=implicit-function-declaration]
  pmd_t pmd = pfn_pmd(pfn, prot);
  ^~~

The reason being THP was not enabled (although ARC supports THP) - for the
combination below
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
# CONFIG_TRANSPARENT_HUGEPAGE is not set

I think you need to use latter for guarding pmd_basic_tests()

Other than that the tests pass for !THP and THP too. So once fixed, you could
enable that for ARC as well
Thx for doing this.

-Vineet

Re: [PATCH v2 1/5] arch/arc: unwind.c: replace swap function with built-in one

[Vineet Gupta]

On 3/31/19 11:31 AM, Andrey Abramov wrote:
> Replace swap_eh_frame_hdr_table_entries with built-in one, because
> swap_eh_frame_hdr_table_entries does a simple byte to byte swap.
>
> Since Spectre mitigations have made indirect function calls more
> expensive, and the default simple byte copies swap is implemented
> without them, an "optimized" custom swap function is now
> a waste of time as well as code.
>
> Signed-off-by: Andrey Abramov 
> Reviewed by: George Spelvin 
>

Acked-by: Vineet Gupta 

Thx,
-Vineet

Re: [PATCH 00/14] entry: preempt_schedule_irq() callers scrub

[Vineet Gupta]

On 3/11/19 3:47 PM, Valentin Schneider wrote:
> Hi,
> 
> This is the continuation of [1] where I'm hunting down
> preempt_schedule_irq() callers because of [2].
> 
> I told myself the best way to get this moving forward wouldn't be to write
> doc about it, but to go write some fixes and get some discussions going,
> which is what this patch-set is about.
> 
> I've looked at users of preempt_schedule_irq(), and made sure they didn't
> have one of those useless loops. The list of offenders is:
> 
> $ grep -r -I "preempt_schedule_irq" arch/ | cut -d/ -f2 | sort | uniq
> 
...

> 
> Regarding that loop, archs seem to fall in 3 categories:
> A) Those that don't have the loop

Please clarify that this is the right thing to do (since core code already has 
the
loop) hence no fixing is required for this "category"

> B) Those that have a small need_resched() loop around the
>preempt_schedule_irq() callsite
> C) Those that branch to some more generic code further up the entry code
>and eventually branch back to preempt_schedule_irq()
> 
> arc, m68k, nios2 fall in A)

> sparc, ia64, s390 fall in C)
> all the others fall in B)
> 
> I've written patches for B) and C) EXCEPT for ia64 and s390 because I
> haven't been able to tell if it's actually fine to kill that "long jump"
> (and maybe I'm wrong on sparc). Hopefully folks who understand what goes on
> in there might be able to shed some light.

Re: [PATCH 0/3] move __HAVE_ARCH_PTE_SPECIAL in Kconfig

[Vineet Gupta]

On 04/09/2018 06:57 AM, Laurent Dufour wrote:

The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the
per architecture header files. This doesn't allow to make other
configuration dependent on it.


So I understand this series has more "readability" value and I'm fine with this 
change but I wonder if you really would want to make something depend on it or 
make this de-configurable. PTE special is really a fundamental construct - e.g. it 
is used for anon mapped pages where zero page has been wired up etc...


-Vineet


This series is moving the __HAVE_ARCH_PTE_SPECIAL into the Kconfig files,
setting it automatically when architectures was already setting it in
header file.

There is no functional change introduced by this series.

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

[Vineet Gupta]

On 02/17/2018 01:19 PM, Pavel Machek wrote:

Fix double ;;'s in code.

Signed-off-by: Pavel Machek

diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 9d27331..ec12fe1 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -373,7 +373,7 @@ static void arc_chk_core_config(void)
  {
struct cpuinfo_arc *cpu = _arc700[smp_processor_id()];
int saved = 0, present = 0;
-   char *opt_nm = NULL;;
+   char *opt_nm = NULL;
  
  	if (!cpu->extn.timer0)

panic("Timer0 is not present!\n");
diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index 333daab..183391d 100644
--- a/arch/arc/kernel/unwind.c
+++ b/arch/arc/kernel/unwind.c
@@ -366,7 +366,7 @@ static void init_unwind_hdr(struct unwind_table *table,
return;
  
  ret_err:

-   panic("Attention !!! Dwarf FDE parsing errors\n");;
+   panic("Attention !!! Dwarf FDE parsing errors\n");
  }
  


I have a fix from Luis to same effect from Jan sitting in my for-curr

Thx for it anyways.

-Vineet

Re: [PATCH 09/67] arc: remove CONFIG_ARC_PLAT_NEEDS_PHYS_TO_DMA

[Vineet Gupta]

On 12/29/2017 12:25 AM, Christoph Hellwig wrote:

We always use the stub definitions, so remove the unused other code.

Signed-off-by: Christoph Hellwig <h...@lst.de>


Acked-by: Vineet Gupta <vgu...@synopsys.com>

FWIW, it was removed and reintroduced as one of the customers wanted it, which is 
not relevant now !


Thx,
-Vineet


---
  arch/arc/Kconfig   |  3 ---
  arch/arc/include/asm/dma-mapping.h |  7 ---
  arch/arc/mm/dma.c  | 14 +++---
  3 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 9d5fd00d9e91..f3a80cf164cc 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -463,9 +463,6 @@ config ARCH_PHYS_ADDR_T_64BIT
  config ARCH_DMA_ADDR_T_64BIT
bool
  
-config ARC_PLAT_NEEDS_PHYS_TO_DMA

-   bool
-
  config ARC_KVADDR_SIZE
int "Kernel Virtual Address Space size (MB)"
range 0 512
diff --git a/arch/arc/include/asm/dma-mapping.h 
b/arch/arc/include/asm/dma-mapping.h
index 94285031c4fb..7a16824bfe98 100644
--- a/arch/arc/include/asm/dma-mapping.h
+++ b/arch/arc/include/asm/dma-mapping.h
@@ -11,13 +11,6 @@
  #ifndef ASM_ARC_DMA_MAPPING_H
  #define ASM_ARC_DMA_MAPPING_H
  
-#ifndef CONFIG_ARC_PLAT_NEEDS_PHYS_TO_DMA

-#define plat_dma_to_phys(dev, dma_handle) ((phys_addr_t)(dma_handle))
-#define plat_phys_to_dma(dev, paddr) ((dma_addr_t)(paddr))
-#else
-#include 
-#endif
-
  extern const struct dma_map_ops arc_dma_ops;
  
  static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)

diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index fad18261ef6a..1d405b86250c 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -60,7 +60,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
/* This is linear addr (0x8000_ based) */
paddr = page_to_phys(page);
  
-	*dma_handle = plat_phys_to_dma(dev, paddr);

+   *dma_handle = paddr;
  
  	/* This is kernel Virtual address (0x7000_ based) */

if (need_kvaddr) {
@@ -92,7 +92,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
  static void arc_dma_free(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_handle, unsigned long attrs)
  {
-   phys_addr_t paddr = plat_dma_to_phys(dev, dma_handle);
+   phys_addr_t paddr = dma_handle;
struct page *page = virt_to_page(paddr);
int is_non_coh = 1;
  
@@ -111,7 +111,7 @@ static int arc_dma_mmap(struct device *dev, struct vm_area_struct *vma,

  {
unsigned long user_count = vma_pages(vma);
unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
-   unsigned long pfn = __phys_to_pfn(plat_dma_to_phys(dev, dma_addr));
+   unsigned long pfn = __phys_to_pfn(dma_addr);
unsigned long off = vma->vm_pgoff;
int ret = -ENXIO;
  
@@ -175,7 +175,7 @@ static dma_addr_t arc_dma_map_page(struct device *dev, struct page *page,

if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
_dma_cache_sync(paddr, size, dir);
  
-	return plat_phys_to_dma(dev, paddr);

+   return paddr;
  }
  
  /*

@@ -190,7 +190,7 @@ static void arc_dma_unmap_page(struct device *dev, 
dma_addr_t handle,
   size_t size, enum dma_data_direction dir,
   unsigned long attrs)
  {
-   phys_addr_t paddr = plat_dma_to_phys(dev, handle);
+   phys_addr_t paddr = handle;
  
  	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))

_dma_cache_sync(paddr, size, dir);
@@ -224,13 +224,13 @@ static void arc_dma_unmap_sg(struct device *dev, struct 
scatterlist *sg,
  static void arc_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
  {
-   _dma_cache_sync(plat_dma_to_phys(dev, dma_handle), size, 
DMA_FROM_DEVICE);
+   _dma_cache_sync(dma_handle, size, DMA_FROM_DEVICE);
  }
  
  static void arc_dma_sync_single_for_device(struct device *dev,

dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
  {
-   _dma_cache_sync(plat_dma_to_phys(dev, dma_handle), size, DMA_TO_DEVICE);
+   _dma_cache_sync(dma_handle, size, DMA_TO_DEVICE);
  }
  
  static void arc_dma_sync_sg_for_cpu(struct device *dev,

Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

[Vineet Gupta]

+CC Ingo, tglx

Hi Till,

On 03/13/2017 03:14 PM, Till Smejkal wrote:
> Introduce a different type of address spaces which are first class citizens
> in the OS. That means that the kernel now handles two types of AS, those
> which are closely coupled with a process and those which aren't. While the
> former ones are created and destroyed together with the process by the
> kernel and are the default type of AS in the Linux kernel, the latter ones
> have to be managed explicitly by the user and are the newly introduced
> type.
> 
> Accordingly, a first class AS (also called VAS == virtual address space)
> can exist in the OS independently from any process. A user has to
> explicitly create and destroy them in the system. Processes and VAS can be
> combined by attaching a previously created VAS to a process which basically
> adds an additional AS to the process that the process' threads are able to
> execute in. Hence, VAS allow a process to have different views onto the
> main memory of the system (its original AS and the attached VAS) between
> which its threads can switch arbitrarily during their lifetime.
> 
> The functionality made available through first class virtual address spaces
> can be used in various different ways. One possible way to utilize VAS is
> to compartmentalize a process for security reasons. Another possible usage
> is to improve the performance of data-centric applications by being able to
> manage different sets of data in memory without the need to map or unmap
> them.
> 
> Furthermore, first class virtual address spaces can be attached to
> different processes at the same time if the underlying memory is only
> readable. This mechanism allows sharing of whole address spaces between
> multiple processes that can both execute in them using the contained
> memory.

I've not looked at the patches closely (or read the references paper fully yet),
but at first glance it seems on ARC architecture, we can can potentially
use/leverage this mechanism to implement the shared TLB entries. Before anyone
shouts these are not same as the IA64/x86 protection keys which allow TLB 
entries
with different protection bits across processes etc. These TLB entries are
actually *shared* by processes.

Conceptually there's shared address spaces, independent of processes. e.g. ldso
code is shared address space #1, libc (code) #2  System can support a 
limited
number of shared addr spaces (say 64, enough for typical embedded sys).

While Normal TLB entries are tagged with ASID (Addr space ID) to keep them 
unique
across processes, Shared TLB entries are tagged with Shared address space ID.

A process MMU context consists of ASID (a single number) and a SASID bitmap (to
allow "subscription" to multiple Shared spaces. The subscriptions are set up bu
userspace ld.so which knows about the libs process wants to map.

The restriction ofcourse is that the spaces are mapped at *same* vaddr is all
participating processes. I know this goes against whole security, address space
randomization - but it gives much better real time performance. Why does each
process need to take a MMU exception for libc code...

So long story short - it seems there can be multiple uses of this 
infrastructure !

-Vineet

[PATCH v3 2/2] atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

[Vineet Gupta]

This came to light when implementing native 64-bit atomics for ARCv2.

The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
to check whether atomic64_dec_if_positive() is available.
It seems it was needed when not every arch defined it.
However as of current code the Kconfig option seems needless

- for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
  generic definition of API is present lib/atomic64.c
- arches with native 64-bit atomics select it in arch/*/Kconfig and
  define the API in their headers

So I see no point in keeping the Kconfig option

Compile tested for:
 - blackfin (CONFIG_GENERIC_ATOMIC64)
 - x86 (!CONFIG_GENERIC_ATOMIC64)
 - ia64

Cc: Richard Henderson <r...@twiddle.net>
Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
Cc: Matt Turner <matts...@gmail.com>
Cc: Russell King <li...@armlinux.org.uk>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: "James E.J. Bottomley" <j...@parisc-linux.org>
Cc: Helge Deller <del...@gmx.de>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Martin Schwidefsky <schwidef...@de.ibm.com>
Cc: Heiko Carstens <heiko.carst...@de.ibm.com>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Chris Metcalf <cmetc...@mellanox.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: Zhaoxiu Zeng <zhaoxiu.z...@gmail.com>
Cc: Linus Walleij <linus.wall...@linaro.org>
Cc: Matthew Wilcox <wi...@linux.intel.com>
Cc: Alexander Potapenko <gli...@google.com>
Cc: Andrey Ryabinin <aryabi...@virtuozzo.com>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: Ming Lin <min...@ssi.samsung.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Geert Uytterhoeven <ge...@linux-m68k.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Borislav Petkov <b...@suse.de>
Cc: Andi Kleen <a...@linux.intel.com>
Cc: Boqun Feng <boqun.f...@gmail.com>
Cc: linux-al...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
---
 arch/alpha/Kconfig   | 1 -
 arch/arm/Kconfig | 1 -
 arch/arm64/Kconfig   | 1 -
 arch/mips/Kconfig| 1 -
 arch/parisc/Kconfig  | 1 -
 arch/powerpc/Kconfig | 1 -
 arch/s390/Kconfig| 1 -
 arch/sparc/Kconfig   | 1 -
 arch/tile/Kconfig| 1 -
 arch/x86/Kconfig | 1 -
 lib/Kconfig  | 3 ---
 lib/atomic64_test.c  | 4 
 12 files changed, 17 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7f312d80b43b..0e49d39ea74a 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -15,7 +15,6 @@ config ALPHA
select GENERIC_IRQ_SHOW
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_HAVE_NMI_SAFE_CMPXCHG
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select AUDIT_ARCH
select GENERIC_CLOCKEVENTS
select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48bb7ec..2a50957c7bfb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,7 +1,6 @@
 config ARM
bool
default y
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f586f1..3df2ca7efbcc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,7 +6,6 @@ config ARM64
select ACPI_MCFG if ACPI
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_KCOV
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 26388562e300..5bbea197c220 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -30,7 +30,6 @@ config MIPS
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT
select RTC_LIB if !MACH_LOONGSON64
select GENERIC_ATOMIC64 if !64BIT
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select HAVE_DMA_CONTIGUOUS
select HAVE_DMA_API_DEBUG
select GENERIC_IRQ_PROBE
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
in

[PATCH v2 2/2] atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

[Vineet Gupta]

This came to light when implementing native 64-bit atomics for ARCv2.

The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
to check whether atomic64_dec_if_positive() is available.
It seems it was needed when not every arch defined it.
However as of current code the Kconfig option seems needless

- for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
  generic definition of API is present lib/atomic64.c
- arches with native 64-bit atomics select it in arch/*/Kconfig and
  define the API in their headers

So I see no point in keeping the Kconfig option

Compile tested for:
 - blackfin (CONFIG_GENERIC_ATOMIC64)
 - x86 (!CONFIG_GENERIC_ATOMIC64)
 - ia64

Cc: Richard Henderson <r...@twiddle.net>
Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
Cc: Matt Turner <matts...@gmail.com>
Cc: Russell King <li...@armlinux.org.uk>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: "James E.J. Bottomley" <j...@parisc-linux.org>
Cc: Helge Deller <del...@gmx.de>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Martin Schwidefsky <schwidef...@de.ibm.com>
Cc: Heiko Carstens <heiko.carst...@de.ibm.com>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Chris Metcalf <cmetc...@mellanox.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: Zhaoxiu Zeng <zhaoxiu.z...@gmail.com>
Cc: Linus Walleij <linus.wall...@linaro.org>
Cc: Matthew Wilcox <wi...@linux.intel.com>
Cc: Alexander Potapenko <gli...@google.com>
Cc: Andrey Ryabinin <aryabi...@virtuozzo.com>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: Ming Lin <min...@ssi.samsung.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Geert Uytterhoeven <ge...@linux-m68k.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Borislav Petkov <b...@suse.de>
Cc: Andi Kleen <a...@linux.intel.com>
Cc: Boqun Feng <boqun.f...@gmail.com>
Cc: linux-al...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
---
 arch/alpha/Kconfig   | 1 -
 arch/arm/Kconfig | 1 -
 arch/arm64/Kconfig   | 1 -
 arch/mips/Kconfig| 1 -
 arch/parisc/Kconfig  | 1 -
 arch/powerpc/Kconfig | 1 -
 arch/s390/Kconfig| 2 +-
 arch/sparc/Kconfig   | 1 -
 arch/tile/Kconfig| 2 +-
 arch/x86/Kconfig | 2 +-
 lib/Kconfig  | 3 ---
 lib/atomic64_test.c  | 4 
 12 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7f312d80b43b..0e49d39ea74a 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -15,7 +15,6 @@ config ALPHA
select GENERIC_IRQ_SHOW
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_HAVE_NMI_SAFE_CMPXCHG
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select AUDIT_ARCH
select GENERIC_CLOCKEVENTS
select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48bb7ec..2a50957c7bfb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,7 +1,6 @@
 config ARM
bool
default y
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f586f1..3df2ca7efbcc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,7 +6,6 @@ config ARM64
select ACPI_MCFG if ACPI
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_KCOV
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 26388562e300..5bbea197c220 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -30,7 +30,6 @@ config MIPS
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT
select RTC_LIB if !MACH_LOONGSON64
select GENERIC_ATOMIC64 if !64BIT
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select HAVE_DMA_CONTIGUOUS
select HAVE_DMA_API_DEBUG
select GENERIC_IRQ_PROBE
diff --git a/arch/parisc/Kconfig b/arch/pa

Re: [PATCH] atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

[Vineet Gupta]

On 09/08/2016 11:19 AM, Peter Zijlstra wrote:
> On Thu, Sep 08, 2016 at 09:28:18AM -0700, Vineet Gupta wrote:
>> This came to light when implementing native 64-bit atomics for ARCv2.
>>
>> The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>> to check whether atomic64_dec_if_positive() is available.
>> It seems it was needed when not every arch defined it.
>> However as of current code the Kconfig option seems needless
>>
>> - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
>>   generic definition of API is present lib/atomic64.c
>> - arches with native 64-bit atomics select it in arch/*/Kconfig and
>>   define the API in their headers
>>
>> So I see no point in keeping the Kconfig option
>>
>> Compile tested for 2 representatives:
>>  - blackfin (CONFIG_GENERIC_ATOMIC64)
>>  - x86 (!CONFIG_GENERIC_ATOMIC64)
>>
>> Also logistics wise it seemed simpler to just do this in 1 patch vs.
>> splitting per arch - but I can break it up if maintainer feel that
>> is better to avoid conflicts.
> Works for me; you want me to take this, or do you need it for you ARCv2
> patches?

Please do. ARCv2 patch (following shortly) doesn't need it - I selected the
option in orig patch - which I can just take out.

Thx,
-Vineet

[PATCH] atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

[Vineet Gupta]

This came to light when implementing native 64-bit atomics for ARCv2.

The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
to check whether atomic64_dec_if_positive() is available.
It seems it was needed when not every arch defined it.
However as of current code the Kconfig option seems needless

- for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
  generic definition of API is present lib/atomic64.c
- arches with native 64-bit atomics select it in arch/*/Kconfig and
  define the API in their headers

So I see no point in keeping the Kconfig option

Compile tested for 2 representatives:
 - blackfin (CONFIG_GENERIC_ATOMIC64)
 - x86 (!CONFIG_GENERIC_ATOMIC64)

Also logistics wise it seemed simpler to just do this in 1 patch vs.
splitting per arch - but I can break it up if maintainer feel that
is better to avoid conflicts.

Cc: Richard Henderson <r...@twiddle.net>
Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
Cc: Matt Turner <matts...@gmail.com>
Cc: Russell King <li...@armlinux.org.uk>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: "James E.J. Bottomley" <j...@parisc-linux.org>
Cc: Helge Deller <del...@gmx.de>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Martin Schwidefsky <schwidef...@de.ibm.com>
Cc: Heiko Carstens <heiko.carst...@de.ibm.com>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Chris Metcalf <cmetc...@mellanox.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: Zhaoxiu Zeng <zhaoxiu.z...@gmail.com>
Cc: Linus Walleij <linus.wall...@linaro.org>
Cc: Matthew Wilcox <wi...@linux.intel.com>
Cc: Alexander Potapenko <gli...@google.com>
Cc: Andrey Ryabinin <aryabi...@virtuozzo.com>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: Ming Lin <min...@ssi.samsung.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Geert Uytterhoeven <ge...@linux-m68k.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Borislav Petkov <b...@suse.de>
Cc: Andi Kleen <a...@linux.intel.com>
Cc: Boqun Feng <boqun.f...@gmail.com>
Cc: linux-al...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
---
 arch/alpha/Kconfig   | 1 -
 arch/arm/Kconfig | 1 -
 arch/arm64/Kconfig   | 1 -
 arch/mips/Kconfig| 1 -
 arch/parisc/Kconfig  | 1 -
 arch/powerpc/Kconfig | 1 -
 arch/s390/Kconfig| 1 -
 arch/sparc/Kconfig   | 1 -
 arch/tile/Kconfig| 1 -
 arch/x86/Kconfig | 1 -
 lib/Kconfig  | 3 ---
 lib/atomic64_test.c  | 4 
 12 files changed, 17 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7f312d80b43b..0e49d39ea74a 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -15,7 +15,6 @@ config ALPHA
select GENERIC_IRQ_SHOW
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_HAVE_NMI_SAFE_CMPXCHG
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select AUDIT_ARCH
select GENERIC_CLOCKEVENTS
select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48bb7ec..2a50957c7bfb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,7 +1,6 @@
 config ARM
bool
default y
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f586f1..3df2ca7efbcc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,7 +6,6 @@ config ARM64
select ACPI_MCFG if ACPI
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_KCOV
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 26388562e300..5bbea197c220 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -30,7 +30,6 @@ config MIPS
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT
select RTC_LIB if !MACH_LOONGSON64
select GENERIC_ATOMIC64 if !64BIT
-   select ARCH_HAS_ATOMIC64_D

Re: [PATCH] devpts: remove DEVPTS_MULTIPLE_INSTANCES from all configs

[Vineet Gupta]

On Monday 20 June 2016 02:44 PM, Alexandru Moise wrote:
> As each mount of devpts is now an independent filesystem,
> the DEVPTS_MULTIPLE_INSTANCES config option no longer exists.
> So remove it.
>
> Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>

For arch/arc

Acked-by: Vineet Gupta <vgu...@synopsys.com>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 43/44] dma-mapping: Remove dma_get_attr

[Vineet Gupta]

On Friday 10 June 2016 03:44 PM, Krzysztof Kozlowski wrote:
> After switching DMA attributes to unsigned long it is easier to just
> compare the bits.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> [for avr32]
> Acked-by: Hans-Christian Noren Egtvedt <egtv...@samfundet.no>

Acked-by: Vineet Gupta <vgu...@synopsys.com>   #for arch/arc
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 19/31] arc: handle page-less SG entries

[Vineet Gupta]

On Wednesday 12 August 2015 12:39 PM, Christoph Hellwig wrote:
 Make all cache invalidation conditional on sg_has_page() and use
 sg_phys to get the physical address directly.

 Signed-off-by: Christoph Hellwig h...@lst.de

With a minor nit below.

Acked-by: Vineet Gupta vgu...@synopsys.com

 ---
  arch/arc/include/asm/dma-mapping.h | 26 +++---
  1 file changed, 19 insertions(+), 7 deletions(-)

 diff --git a/arch/arc/include/asm/dma-mapping.h 
 b/arch/arc/include/asm/dma-mapping.h
 index 2d28ba9..42eb526 100644
 --- a/arch/arc/include/asm/dma-mapping.h
 +++ b/arch/arc/include/asm/dma-mapping.h
 @@ -108,9 +108,13 @@ dma_map_sg(struct device *dev, struct scatterlist *sg,
   struct scatterlist *s;
   int i;
  
 - for_each_sg(sg, s, nents, i)
 - s-dma_address = dma_map_page(dev, sg_page(s), s-offset,
 -s-length, dir);
 + for_each_sg(sg, s, nents, i) {
 + if (sg_has_page(s)) {
 + _dma_cache_sync((unsigned long)sg_virt(s), s-length,
 + dir);
 + }
 + s-dma_address = sg_phys(s);
 + }
  
   return nents;
  }
 @@ -163,8 +167,12 @@ dma_sync_sg_for_cpu(struct device *dev, struct 
 scatterlist *sglist, int nelems,
   int i;
   struct scatterlist *sg;
  
 - for_each_sg(sglist, sg, nelems, i)
 - _dma_cache_sync((unsigned int)sg_virt(sg), sg-length, dir);
 + for_each_sg(sglist, sg, nelems, i) {
 + if (sg_has_page(sg)) {
 + _dma_cache_sync((unsigned int)sg_virt(sg), sg-length,
 + dir);
 + }
 + }
  }
  
  static inline void
 @@ -174,8 +182,12 @@ dma_sync_sg_for_device(struct device *dev, struct 
 scatterlist *sglist,
   int i;
   struct scatterlist *sg;
  
 - for_each_sg(sglist, sg, nelems, i)
 - _dma_cache_sync((unsigned int)sg_virt(sg), sg-length, dir);
 + for_each_sg(sglist, sg, nelems, i) {
 + if (sg_has_page(sg)) {
 + _dma_cache_sync((unsigned int)sg_virt(sg), sg-length,
 + dir);

For consistency, could u please fix the left alignment of @dir above - another 
tab
perhaps ?

 + }
 + }
  }
  
  static inline int dma_supported(struct device *dev, u64 dma_mask)

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC][PATCH 0/4] perf: Enable symbolic event names

[Vineet Gupta]

On Friday 01 May 2015 12:35 PM, Sukadev Bhattiprolu wrote:
 Implement ability to specify Power PMU events by their symbolic event
 names rather than raw codes. This approach pulls tables of the Power7
 and Power8 PMU events into the perf source tree and uses these tables
 to create aliases for the PMU events. With these aliases users can run:
 
   perf stat -e PM_1PLUS_PPC_CMPL:ku sleep 1
 or
   perf stat -e cpu/PM_VSU_SINGLE/ sleep 1
 
 This is an early POC patchset based on discussions with Jiri Olsa,
 Michael Ellerman and Ingo Molnar. Lightly tested on Power7 and Power8.
 
 Can other architectures can implement arch_get_events_table() and similarly 
 use symoblic event names?


Yes, ARC can certainly use this infrastructure. Our hardware conditions are
actually 1-8 char strings. So using raw events requires me to first convert the
string to ASCII.

 
 I am also assuming that if the header files like power8-events.h are
 easily readable, we don't need the JSON files anymore?
 
 TODO:
   - Maybe translate event names to lower-case?
   - Allow perf to process event descriptions (need Andi Kleen's patch)
 
 
 Sukadev Bhattiprolu (4):
   perf: Create a table of Power7 PMU events
   perf: Create a table of Power8 PMU events
   perf/powerpc: Move mfspr and friends to header file
   perf: Create aliases for Power PMU events
 
  tools/perf/arch/powerpc/util/Build   |2 +-
  tools/perf/arch/powerpc/util/header.c|9 +-
  tools/perf/arch/powerpc/util/header.h|9 +
  tools/perf/arch/powerpc/util/pmu-events.c|   52 +
  tools/perf/arch/powerpc/util/pmu-events.h|   17 +
  tools/perf/arch/powerpc/util/power7-events.h | 3315 +
  tools/perf/arch/powerpc/util/power8-events.h | 6408 
 ++
  tools/perf/util/pmu.c|   77 +
  tools/perf/util/pmu.h|   10 +
  9 files changed, 9890 insertions(+), 9 deletions(-)
  create mode 100644 tools/perf/arch/powerpc/util/header.h
  create mode 100644 tools/perf/arch/powerpc/util/pmu-events.c
  create mode 100644 tools/perf/arch/powerpc/util/pmu-events.h
  create mode 100644 tools/perf/arch/powerpc/util/power7-events.h
  create mode 100644 tools/perf/arch/powerpc/util/power8-events.h
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC][PATCH 4/4] perf: Create aliases for PMU events

[Vineet Gupta]

On Friday 01 May 2015 12:35 PM, Sukadev Bhattiprolu wrote:
 Using the tables of Power7 and Power8 events, create aliases for the
 Power PMU events. This would allow us to specify all Power events by
 name rather than by raw code:
 
   $ /tmp/perf stat -e PM_1PLUS_PPC_CMPL sleep 1
 
Performance counter stats for 'sleep 1':
 
  757,661  PM_1PLUS_PPC_CMPL
 
  1.001620145 seconds time elapsed
 
 The perf binary built on Power8 can be copied to Power7 and it will use
 the Power7 events (if arch/powerpc/util/pmu-events.h knows the CPU string).
 
 Hopefully other architecutres can also implement arch_get_events_table()
 and take advantage of this.
 
 Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
 ---
  tools/perf/arch/powerpc/util/Build|2 +-
  tools/perf/arch/powerpc/util/pmu-events.c |   52 +++
  tools/perf/arch/powerpc/util/pmu-events.h |   17 +++
  tools/perf/util/pmu.c |   77 
 +
  tools/perf/util/pmu.h |   10 
  5 files changed, 157 insertions(+), 1 deletion(-)
  create mode 100644 tools/perf/arch/powerpc/util/pmu-events.c
  create mode 100644 tools/perf/arch/powerpc/util/pmu-events.h
 
 diff --git a/tools/perf/arch/powerpc/util/Build 
 b/tools/perf/arch/powerpc/util/Build
 index 0af6e9b..52fbc7f 100644
 --- a/tools/perf/arch/powerpc/util/Build
 +++ b/tools/perf/arch/powerpc/util/Build
 @@ -1,4 +1,4 @@
 -libperf-y += header.o
 +libperf-y += header.o pmu-events.o
  
  libperf-$(CONFIG_DWARF) += dwarf-regs.o
  libperf-$(CONFIG_DWARF) += skip-callchain-idx.o
 diff --git a/tools/perf/arch/powerpc/util/pmu-events.c 
 b/tools/perf/arch/powerpc/util/pmu-events.c
 new file mode 100644
 index 000..7036f6d
 --- /dev/null
 +++ b/tools/perf/arch/powerpc/util/pmu-events.c
 @@ -0,0 +1,52 @@
 +#include stdio.h
 +#include unistd.h
 +#include sys/types.h
 +#include pmu.h
 +#include pmu-events.h
 +#include ../../util/debug.h/* verbose */
 +#include header.h  /* mfspr */
 +
 +static char *get_cpu_str(void)
 +{
 + char *bufp;
 +
 + if (asprintf(bufp, %.8lx-core, mfspr(SPRN_PVR))  0)
 + bufp = NULL;
 +
 + return bufp;
 +}
 +
 +struct perf_pmu_event *arch_get_events_table(char *cpustr)
 +{
 + int i, nmaps, must_free;
 + struct  perf_pmu_event *table;
 +
 + must_free = 0;
 + if (!cpustr) {
 + cpustr = get_cpu_str();
 + if (!cpustr)
 + return NULL;
 + must_free = 1;
 + }
 +
 + nmaps = sizeof(pvr_events_map) / sizeof(struct pvr_events_map_entry);
 +
 + for (i = 0; i  nmaps; i++) {
 + if (!strcmp(pvr_events_map[i].pvr, cpustr))
 + break;
 + }
 +
 + table = NULL;
 + if (i  nmaps) {
 + /* pvr_events_map is a const; cast to override */
 + table = (struct perf_pmu_event *)pvr_events_map[i].pmu_events;
 + } else if (verbose) {
 + printf(Unknown CPU %s, ignoring aliases\n, cpustr);
 + }
 +
 + if (must_free)
 + free(cpustr);
 +
 + return table;
 +}
 +
 diff --git a/tools/perf/arch/powerpc/util/pmu-events.h 
 b/tools/perf/arch/powerpc/util/pmu-events.h
 new file mode 100644
 index 000..1daf8e5
 --- /dev/null
 +++ b/tools/perf/arch/powerpc/util/pmu-events.h
 @@ -0,0 +1,17 @@
 +/*
 + * Include all Power processor tables that we care about.
 + */
 +#include power7-events.h
 +#include power8-events.h
 +
 +/*
 + * Map a processor version (PVR) to its table of events.
 + */
 +struct pvr_events_map_entry {
 + const char *pvr;
 + const struct perf_pmu_event *pmu_events;
 +} pvr_events_map[] = {
 + { .pvr = 004d0100-core,   .pmu_events = power8_pmu_events },
 + { .pvr = 003f0201-core,   .pmu_events = power7_pmu_events }
 +};

Do u really need the header - this could go in the .c file ?

 +
 diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
 index 4841167..f998d91 100644
 --- a/tools/perf/util/pmu.c
 +++ b/tools/perf/util/pmu.c
 @@ -435,6 +435,80 @@ perf_pmu__get_default_config(struct perf_pmu *pmu 
 __maybe_unused)
   return NULL;
  }
  
 +/*
 + * Default arch_get_events_table() is empty.
 + *
 + * Actual implementation is in arch/$(ARCH)/util/pmu-events.c. This
 + * allows architectures could choose what set(s) of events to a) include
 + * in perf binary b) consider for _this_ invocation of perf.
 + *
 + * Eg: For Power, we include both Power7 and Power8 event tables in the
 + *   perf binary. But depending on the processor where perf is executed,
 + *   either the Power7 or Power8 table is returned.
 + */
 +struct perf_pmu_event * __attribute__ ((weak))
 +arch_get_events_table(char *cpustr __maybe_unused)
 +{
 + return NULL;
 +}
 +
 +static int pmu_add_cpu_aliases(char *cpustr, void *data)
 +{
 + struct list_head *head = (struct list_head *)data;
 + struct perf_pmu_alias 

Re: [PATCH V2] tty: serial: Add const to struct uart_ops declarations

[Vineet Gupta]

On Sunday 05 April 2015 11:55 PM, Joe Perches wrote:

These structs can be const, so make them const.

Miscellanea:

o Add static to struct uart_ops declaration in bfin_sport_uart

Signed-off-by: Joe Perches j...@perches.commailto:j...@perches.com
---
On Sun, 2015-04-05 at 00:04 +0200, Stefan Agner wrote:


 On 2015-04-04 19:47, Joe Perches wrote:


  Done with:
  sed -r -i -e 's/\bstruct\s+uart_ops\s+(\w+)\s*=\s*/const struct
  uart_ops \1 = /g' drivers/tty/serial/*.c


[]


 +++ b/drivers/tty/serial/fsl_lpuart.c
 Something went wrong in this driver, const is twice...


Apologies, thanks for noticing.
The sed was mistakenly done twice on that file.

V2:

o Fix duplicate const in fsl_lpuart.c
o Add static to drivers/tty/serial/bfin_sport_uart.c

Still compiled only x86 and not cross-compiled or tested.

 drivers/tty/serial/21285.c  | 2 +-
 drivers/tty/serial/altera_jtaguart.c| 2 +-
 drivers/tty/serial/altera_uart.c| 2 +-
 drivers/tty/serial/amba-pl010.c | 2 +-
 drivers/tty/serial/amba-pl011.c | 2 +-
 drivers/tty/serial/apbuart.c| 2 +-
 drivers/tty/serial/ar933x_uart.c| 2 +-
 drivers/tty/serial/arc_uart.c   | 2 +-

Acked-by: Vineet Gupta vgu...@synopsys.commailto:vgu...@synopsys.com # for 
arc_uart

Th,
-Vineet
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 08/44] kernel: Move pm_power_off to common code

[Vineet Gupta]

On Tuesday 07 October 2014 11:01 AM, Guenter Roeck wrote:

diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c
index 2768fa1..8a4fc47 100644
--- a/arch/arc/kernel/reset.c
+++ b/arch/arc/kernel/reset.c
@@ -26,9 +26,6 @@ void machine_restart(char *__unused)

 void machine_power_off(void)
 {
-   /* FIXME ::  power off ??? */
+   do_kernel_poweroff();
machine_halt();
 }
-
-void (*pm_power_off) (void) = NULL;
-EXPORT_SYMBOL(pm_power_off);

Acked-by: Vineet Gupta vgu...@synopsys.commailto:vgu...@synopsys.com

Thx,
-Vineet
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

[Vineet Gupta]

On Thursday 14 August 2014 09:55 AM, Chen Gang wrote:
 Normal architectures:

  - Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc

  - Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300,
   score, unicore32, x86

  - Choose in config time: arc, arm, arm64, c6x, m32r, mips, powerpc, sh

 Special architectures:

  - Deside by compiler: microblaze, tile, xtensa.

  - Deside by building host: um

  - Next, need improve Kbuild to probe endian to deside whether need mark
__BUILDING_TIME_BIG_ENDIAN__ before real config.

 Another improvements:

  - score: use '\t' instead of ' '.

  - s390: sort the select value in alpha order.

 Signed-off-by: Chen Gang gang.chen.5...@gmail.com
 ---
  arch/alpha/Kconfig  |  1 +
  arch/arc/Kconfig|  1 +
  arch/arm/Kconfig|  1 +
  arch/arm64/Kconfig  |  1 +
  arch/avr32/Kconfig  |  1 +
  arch/blackfin/Kconfig   |  1 +
  arch/c6x/Kconfig|  1 +
  arch/cris/Kconfig   |  1 +
  arch/frv/Kconfig|  1 +
  arch/hexagon/Kconfig|  1 +
  arch/ia64/Kconfig   |  1 +
  arch/m32r/Kconfig   |  1 +
  arch/m68k/Kconfig   |  1 +
  arch/metag/Kconfig  |  1 +
  arch/microblaze/Kconfig |  2 ++
  arch/mips/Kconfig   |  1 +
  arch/mn10300/Kconfig|  1 +
  arch/openrisc/Kconfig   |  1 +
  arch/parisc/Kconfig |  1 +
  arch/powerpc/Kconfig|  1 +
  arch/s390/Kconfig   |  3 ++-
  arch/score/Kconfig  | 21 +++--
  arch/sparc/Kconfig  |  1 +
  arch/tile/Kconfig   |  2 ++
  arch/um/Kconfig.common  |  2 ++
  arch/unicore32/Kconfig  |  1 +
  arch/x86/Kconfig|  1 +
  arch/xtensa/Kconfig |  2 ++
  init/Kconfig|  6 ++
  29 files changed, 49 insertions(+), 11 deletions(-)

 diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
 index b7ff9a3..1cb7426 100644
 --- 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_LITTLE_ENDIAN
   help
 The Alpha is a 64-bit general-purpose processor designed and
 marketed by the Digital Equipment Corporation of blessed memory,
 diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
 index 9596b0a..e939abd 100644
 --- a/arch/arc/Kconfig
 +++ b/arch/arc/Kconfig
 @@ -35,6 +35,7 @@ config ARC
   select OF_EARLY_FLATTREE
   select PERF_USE_VMALLOC
   select HAVE_DEBUG_STACKOVERFLOW
 + select CPU_LITTLE_ENDIAN if !CPU_BIG_ENDIAN

It is not clear what exactly are you trying to fix. What doesn't work w/o this
patch !

-Vineet
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

[Vineet Gupta]

On Thursday 14 August 2014 03:22 PM, Chen Gang wrote:
 For many individual modules may need check CPU_LITTLE_ENDIAN or
 CPU_BIG_ENDIAN, which is an architecture's attribute.

 Or they have to list many architectures which they support, which they
 don't support. And still, it is not precise.

 For architecture API, endian is a main architecture's attribute which
 may be used by outside, so every architecture need let outside know
 about it, explicitly.

I don't think that is correct. The modules need to use standard API e.g. swab
which will take care of proper endian handling anyways. Why would a module do
anything endian specific outside of those APIs.

And again is this churn just theoretical or do you really have a issue at hand 
! I
would not accept a change for ARC unless you prove that something is broken (or
atleast potentially broken) !

-Vineet
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] of: Specify initrd location using 64-bit

[Vineet Gupta]

On 07/01/2013 11:52 PM, Santosh Shilimkar wrote:
 On some PAE architectures, the entire range of physical memory could reside
 outside the 32-bit limit.  These systems need the ability to specify the
 initrd location using 64-bit numbers.

 This patch globally modifies the early_init_dt_setup_initrd_arch() function to
 use 64-bit numbers instead of the current unsigned long.

 There has been quite a bit of debate about whether to use u64 or phys_addr_t.
 It was concluded to stick to u64 to be consistent with rest of the device
 tree code. As summarized by Geert, The address to load the initrd is decided
 by the bootloader/user and set at that point later in time. The dtb should not
 be tied to the kernel you are booting

 More details on the discussion can be found here:
 https://lkml.org/lkml/2013/6/20/690
 https://lkml.org/lkml/2012/9/13/544

 Cc: Grant Likely grant.lik...@linaro.org
 Cc: Rob Herring rob.herr...@calxeda.com
 Cc: Geert Uytterhoeven ge...@linux-m68k.org
 Cc: Sebastian Andrzej Siewior bige...@linutronix.de
 Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
 Cc: Vineet Gupta vgu...@synopsys.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Will Deacon will.dea...@arm.com
 Cc: Mark Salter msal...@redhat.com
 Cc: Aurelien Jacquiot a-jacqu...@ti.com
 Cc: James Hogan james.ho...@imgtec.com
 Cc: Michal Simek mon...@monstr.eu
 Cc: Ralf Baechle r...@linux-mips.org
 Cc: Jonas Bonn jo...@southpole.se
 Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
 Cc: Paul Mackerras pau...@samba.org
 Cc: x...@kernel.org
 Cc: a...@kernel.org
 Cc: Chris Zankel ch...@zankel.net
 Cc: Max Filippov jcmvb...@gmail.com
 Cc: bige...@linutronix.de
 Cc: robherri...@gmail.com
 Cc: Nicolas Pitre nicolas.pi...@linaro.org

 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-c6x-...@linux-c6x.org
 Cc: linux-m...@linux-mips.org
 Cc: linuxppc-dev@lists.ozlabs.org
 Cc: linux-xte...@linux-xtensa.org
 Cc: devicetree-disc...@lists.ozlabs.org

 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---

Acked-by: Vineet Gupta vgu...@synopsys.com  [For arch/arc bits]

-Vineet

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] of: Specify initrd location using 64-bit

[Vineet Gupta]

Hi Santosh,

On 06/21/2013 06:22 AM, Santosh Shilimkar wrote:
 Cc: Vineet Gupta vgu...@synopsys.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Will Deacon will.dea...@arm.com
 Cc: Mark Salter msal...@redhat.com
 Cc: Aurelien Jacquiot a-jacqu...@ti.com
 Cc: James Hogan james.ho...@imgtec.com
 Cc: Michal Simek mon...@monstr.eu
 Cc: Ralf Baechle r...@linux-mips.org
 Cc: Jonas Bonn jo...@southpole.se
 Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
 Cc: Paul Mackerras pau...@samba.org
 Cc: x...@kernel.org
 Cc: a...@kernel.org
 Cc: Chris Zankel ch...@zankel.net
 Cc: Max Filippov jcmvb...@gmail.com
 Cc: Grant Likely grant.lik...@linaro.org
 Cc: Rob Herring rob.herr...@calxeda.com
 Cc: bige...@linutronix.de
 Cc: robherri...@gmail.com
 Cc: Nicolas Pitre nicolas.pi...@linaro.org

 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-c6x-...@linux-c6x.org
 Cc: linux-m...@linux-mips.org
 Cc: linuxppc-dev@lists.ozlabs.org
 Cc: linux-xte...@linux-xtensa.org
 Cc: devicetree-disc...@lists.ozlabs.org

 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arc/mm/init.c|3 +--
  arch/arm/mm/init.c|2 +-
  arch/arm64/mm/init.c  |3 +--
  arch/c6x/kernel/devicetree.c  |3 +--
  arch/metag/mm/init.c  |3 +--
  arch/microblaze/kernel/prom.c |3 +--
  arch/mips/kernel/prom.c   |3 +--
  arch/openrisc/kernel/prom.c   |3 +--
  arch/powerpc/kernel/prom.c|3 +--
  arch/x86/kernel/devicetree.c  |3 +--
  arch/xtensa/kernel/setup.c|3 +--
  drivers/of/fdt.c  |   10 ++
  include/linux/of_fdt.h|3 +--
  13 files changed, 18 insertions(+), 27 deletions(-)

 diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
 index 4a17736..3640c74 100644
 --- a/arch/arc/mm/init.c
 +++ b/arch/arc/mm/init.c
 @@ -157,8 +157,7 @@ void __init free_initrd_mem(unsigned long start, unsigned 
 long end)
  #endif
  
  #ifdef CONFIG_OF_FLATTREE
 -void __init early_init_dt_setup_initrd_arch(unsigned long start,
 - unsigned long end)
 +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
  {
   pr_err(%s(%lx, %lx)\n, __func__, start, end);
  }

To avoid gcc warnings, you need to fix the print format specifiers too.

Thx,
-Vineet
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev