Re: [PATCH 2/4] arch: simplify architecture specific page size configuration

[Helge Deller]

On 2/26/24 17:14, Arnd Bergmann wrote:

From: Arnd Bergmann 

arc, arm64, parisc and powerpc all have their own Kconfig symbols
in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
so the common symbols are the ones that are actually used, while
leaving the arhcitecture specific ones as the user visible
place for configuring it, to avoid breaking user configs.

Signed-off-by: Arnd Bergmann 
---
  arch/arc/Kconfig  |  3 +++
  arch/arc/include/uapi/asm/page.h  |  6 ++
  arch/arm64/Kconfig| 29 +
  arch/arm64/include/asm/page-def.h |  2 +-
  arch/parisc/Kconfig   |  3 +++
  arch/parisc/include/asm/page.h| 10 +-


Acked-by: Helge Deller  # parisc

Thanks for the cleanups!

Helge

Re: [PATCH v2 23/29] parisc: Move EXCEPTION_TABLE to RO_DATA segment

[Helge Deller]

On 11.10.19 02:06, Kees Cook wrote:

Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.

Signed-off-by: Kees Cook 
---
  arch/parisc/kernel/vmlinux.lds.S | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)



Acked-by: Helge Deller   # parisc

Helge



diff --git a/arch/parisc/kernel/vmlinux.lds.S b/arch/parisc/kernel/vmlinux.lds.S
index 12b3d7d5e9e4..53e29d88f99c 100644
--- a/arch/parisc/kernel/vmlinux.lds.S
+++ b/arch/parisc/kernel/vmlinux.lds.S
@@ -19,6 +19,7 @@
*(.data..vm0.pte)

  #define CC_USING_PATCHABLE_FUNCTION_ENTRY
+#define RO_EXCEPTION_TABLE_ALIGN   8

  #include 

@@ -129,9 +130,6 @@ SECTIONS

RO_DATA(8)

-   /* RO because of BUILDTIME_EXTABLE_SORT */
-   EXCEPTION_TABLE(8)
-
/* unwind info */
.PARISC.unwind : {
__start___unwind = .;

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

[Helge Deller]

On 16.07.19 20:55, Christian Brauner wrote:

On Tue, Jul 16, 2019 at 08:53:10PM +0200, Sven Schnelle wrote:

Hi,

[Adding Helge to CC list]

On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote:

On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:

I think Vasily already has a clone3 patch for s390x with 435.


A quick follow-up on this. Helge and Michael have asked whether there
are any tests for clone3. Yes, there will be and I try to have them
ready by the end of the this or next week for review. In the meantime I
hope the following minimalistic test program that just verifies very
very basic functionality (It's not pretty.) will help you test:
[..]


On PA-RISC this seems to work fine with Helge's patch to wire up the
clone3 syscall.


[...]
In any case, I saw Helge's patch and I think I might've missed to add an
Acked-by but feel free to add it.


Thanks!
I've added the patch to the parisc-linux for-next tree.

Helge

Re: [alpha] Debian 9.0 NETINST fails

[Helge Deller]

Hi Michael,

On 22.11.18 06:34, Michael Cree wrote:

On Wed, Nov 21, 2018 at 02:53:30PM -0600, Bob Tracy wrote:

On Wed, Nov 07, 2018 at 04:12:27PM +0100, John Paul Adrian Glaubitz wrote:

I can unfortunately not build updated installer images for Alpha since I
don't have an Alpha porterbox available where I can build the debian-installer
package for Alpha.

I do have two AlphaStation 233 sitting in the basement at the university now,
but I don't have any time and space to set them up to be used as porterboxes.

The only porterbox currently currently available to me is Michael Cree's 
"electro"
but the repositories of the chroots there don't include the debian-installer
component packages, so building d-i fails - at least last time I tried.


I've carved out a bit of time to deal with getting my PWS back on-line.
The above is the most recent post in the thread, as far as I can tell...

Michael -- is it a relatively easy thing to do to make the d-i component
packages available on "electro"?


I am not exactly sure what the problem is, but reading between the
lines I am starting to get the impression that Adrian expected the
package cache to be a complete copy of the archive.


Yes.
This is, because that's the way the installer images are being built
on the original build servers with the unmodified scripts/tools.
If you want the build process to be able to work with caching proxies,
someone needs to do modifications and bring them upstream.
Adrian offered to set up the build process as he has done it for many
of the architectures already. As far as I read his answers, he seems not
to be so much interested to do special work now "just" for alpha


It is not and it is not intended to be. Approx works by caching only
those things that have been previously requested.

Sure, understood.


If I have surmised correctly then one only needs to issue a download
request to approx for the missing packages (and it should not matter
with that is a .deb or a .udeb) and that should get it into the local
cache.


Someone has to do it then...

What's the problem of having a complete copy of the archive on electro?

Helge


Another option: is the SMP version of the 4.9.0-3 kernel available to
substitute into the existing netinst image?


That's for Adrian to answer.  I am not familiar with building an
installer image.

Cheers,
Michael.

Re: common non-cache coherent direct dma mapping ops

[Helge Deller]

On 11.05.2018 09:59, Christoph Hellwig wrote:
> this series continues consolidating the dma-mapping code, with a focus
> on architectures that do not (always) provide cache coherence for DMA.
> Three architectures (arm, mips and powerpc) are still left to be
> converted later due to complexity of their dma ops selection.
> 
> The dma-noncoherent ops calls the dma-direct ops for the actual
> translation of streaming mappins and allow the architecture to provide
> any cache flushing required for cpu to device and/or device to cpu
> ownership transfers.  The dma coherent allocator is for now still left
> entirely to architecture supplied implementations due the amount of
> variations.  Hopefully we can do some consolidation for them later on
> as well.
> 
> A lot of architectures are currently doing very questionable things
> in their dma mapping routines, which are documented in the changelogs
> for each patch.  Please review them very careful and correct me on
> incorrect assumptions.
> 
> Because this series sits on top of two previously submitted series
> a git tree might be useful to actually test it.  It is provided here:
> 
> git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent
> 
> Gitweb:
> 
> 
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent
> 
> Changes since RFC:
>  - fix a typo accidentally disabling the device to cpu transfer sync
>  - fixed a few compile failures


I tested it again on parisc (this time again on top of git head) and it still 
breaks
the same way as I reported in my mail on April 21st: the lasi82956 network 
driver works
unreliable. NIC gets IP, but ping doesn't work.
See drivers/net/ethernet/i825xx/lasi_82596.c, it uses dma*sync() functions.

See comment in James mail from April 21st too:
-> you just made every 32 bit parisc system unnecessarily use non-coherent.

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops

[Helge Deller]

On 25.04.2018 09:21, Christoph Hellwig wrote:
> On Sat, Apr 21, 2018 at 07:43:46PM +0200, Helge Deller wrote:
>> This patch breaks a 32bit kernel on a B160L machine (PA7300LC CPU, "pcxl2").
>> After applying this patch series the lasi82956 network driver works 
>> unreliable. 
>> NIC gets IP, but ping doesn't work.
>> See drivers/net/ethernet/i825xx/lasi_82596.c, it uses dma*sync() functions.
> 
> Just to confirm:  Without the series it is known to actually work?

Yes.
I reverted this series from my tree, rebuilt, and then the issue was gone.
I won't be able to test again earlier than next week.

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops

[Helge Deller]

On 20.04.2018 10:03, Christoph Hellwig wrote:
> Switch to the generic noncoherent direct mapping implementation.
> 
> Parisc previously had two different non-coherent dma ops implementation
> that just different in the way coherent allocations were handled or not
> handled.  The different behavior is not selected at runtime in the
> arch_dma_alloc and arch_dma_free routines.  The non-coherent allocation
> in the pcx cases now uses the dma_direct helpers that are a little more
> sophisticated and used by a lot of other architectures.
> 
> Fix sync_single_for_cpu to do skip the cache flush unless the transfer
> is to the device to match the more tested unmap_single path which should
> have the same cache coherency implications.
> 
> This also now consistenly uses flush_kernel_dcache_range for cache
> flushing while previously some of the SG based operations used
> flush_kernel_vmap_range instead.


This patch breaks a 32bit kernel on a B160L machine (PA7300LC CPU, "pcxl2").
After applying this patch series the lasi82956 network driver works unreliable. 
NIC gets IP, but ping doesn't work.
See drivers/net/ethernet/i825xx/lasi_82596.c, it uses dma*sync() functions.

Helge

 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/parisc/Kconfig   |   4 +
>  arch/parisc/include/asm/dma-mapping.h |   5 -
>  arch/parisc/kernel/pci-dma.c  | 181 --
>  arch/parisc/kernel/setup.c|   8 +-
>  arch/parisc/mm/init.c |  11 +-
>  5 files changed, 35 insertions(+), 174 deletions(-)
> 
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index 47047f0cbe35..80166a1cbcb7 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -188,6 +188,10 @@ config PA20
>  config PA11
>   def_bool y
>   depends on PA7000 || PA7100LC || PA7200 || PA7300LC
> + select ARCH_HAS_SYNC_DMA_FOR_CPU
> + select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> + select DMA_NONCOHERENT_OPS
> + select DMA_NONCOHERENT_CACHE_SYNC
>  
>  config PREFETCH
>   def_bool y
> diff --git a/arch/parisc/include/asm/dma-mapping.h 
> b/arch/parisc/include/asm/dma-mapping.h
> index 01e1fc057c83..44a9f97194aa 100644
> --- a/arch/parisc/include/asm/dma-mapping.h
> +++ b/arch/parisc/include/asm/dma-mapping.h
> @@ -21,11 +21,6 @@
>  ** flush/purge and allocate "regular" cacheable pages for everything.
>  */
>  
> -#ifdef CONFIG_PA11
> -extern const struct dma_map_ops pcxl_dma_ops;
> -extern const struct dma_map_ops pcx_dma_ops;
> -#endif
> -
>  extern const struct dma_map_ops *hppa_dma_ops;
>  
>  static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
> *bus)
> diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
> index 91bc0cac03a1..235e2e53959e 100644
> --- a/arch/parisc/kernel/pci-dma.c
> +++ b/arch/parisc/kernel/pci-dma.c
> @@ -21,13 +21,12 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
>  
>  #include 
>  #include /* for DMA_CHUNK_SIZE */
> @@ -447,178 +446,48 @@ static void pa11_dma_free(struct device *dev, size_t 
> size, void *vaddr,
>   free_pages((unsigned long)__va(dma_handle), order);
>  }
>  
> -static dma_addr_t pa11_dma_map_page(struct device *dev, struct page *page,
> - unsigned long offset, size_t size,
> - enum dma_data_direction direction, unsigned long attrs)
> +void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
> + size_t size, enum dma_data_direction dir)
>  {
> - void *addr = page_address(page) + offset;
> - BUG_ON(direction == DMA_NONE);
> -
> - if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> - flush_kernel_dcache_range((unsigned long) addr, size);
> -
> - return virt_to_phys(addr);
> + flush_kernel_dcache_range((unsigned long)phys_to_virt(paddr), size);
>  }
>  
> -static void pa11_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
> - size_t size, enum dma_data_direction direction,
> - unsigned long attrs)
> +void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr,
> + size_t size, enum dma_data_direction dir)
>  {
> - BUG_ON(direction == DMA_NONE);
> -
> - if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
> - return;
> -
> - if (direction == DMA_TO_DEVICE)
> + if (dir == DMA_TO_DEVICE)
>   return;
>  
>   /*
> -  * For PCI_DMA_FROMDEVICE this flush is not necessary for the
> +  * For DMA_FROM_DEVICE this flush is not necessary for the
>* simple map/unmap case. However, it IS necessary if if
> -  * pci_dma_sync_single_* has been called and the buffer reused.
> +  * dma_sync_single_* has been called and the buffer reused.
>*/
>  
> - flush_kernel_dcache_range((unsigned long) phys_to_virt(dma_handle), 
> size);
> -}
> -
> -static int pa11_dma_map_sg(struct device *dev, struct scatterlist 

Re: BRSGP relocation truncations in linking kernel for Alpha.

[Helge Deller]

Hi Michael,

On 22.10.2016 04:41, Michael Cree wrote:
> When building recent kernels for Alpha I am getting the following
> relocation errors:
> 
> alpha-linux-gnu-ld -static -N --build-id -o .tmp_vmlinux1 -T
> ./arch/alpha/kernel/vmlinux.lds arch/alpha/kernel/head.o init/built-in.o
> --start-group usr/built-in.o arch/alpha/kernel/built-in.o
> arch/alpha/mm/built-in.o arch/alpha/math-emu/built-in.o
> kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o
> ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o
> lib/lib.a arch/alpha/lib/lib.a lib/built-in.o arch/alpha/lib/built-in.o
> drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o
> virt/built-in.o --end-group
> net/built-in.o: In function `packet_setsockopt':
> net/packet/af_packet.o:(.text+0xf71d0): relocation truncated to fit:
> BRSGP against symbol `__copy_user' defined in .text section in
> arch/alpha/lib/lib.a(ev6-copy_user.o)
> 
> I can solve it by de-selecting config items, but it is getting
> frustrating that I can't build the kernel I would like to build.
> 
> Is there anything we can do to resolve these relocations?

You could try to play around where various functions get located
in the final vmlinux file. For that you need to modify 
arch/alpha/kernel/vmlinux.lds.S.
I did quite such optimizations for parisc like that.

Does it only happens for __copy_user() ?
If yes, I assume the problem happens because of __copy_tofrom_user_nocheck() in 
uaccess.h is always inlined. Maybe un-inlining helps?
Or, the inline-assembly for jsr/bsr needs tweeking ?

Helge 
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux 4.6 FTBFS on alpha

[Helge Deller]

On 05.05.2016 03:17, Ben Hutchings wrote:
> There's a silly type error in an alpha-specific module that now breaks
> the build:
> 
> /«PKGBUILDDIR»/fs/binfmt_em86.c: In function 'load_em86':
> /«PKGBUILDDIR»/fs/binfmt_em86.c:73:35: error: passing argument 2 of 
> 'copy_strings_kernel' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>retval = copy_strings_kernel(1, _arg, bprm);
>^
> In file included from /«PKGBUILDDIR»/fs/binfmt_em86.c:14:0:
> /«PKGBUILDDIR»/include/linux/binfmts.h:116:12: note: expected 'const char * 
> const*' but argument is of type 'char **'
>  extern int copy_strings_kernel(int argc, const char *const *argv,
> ^
> /«PKGBUILDDIR»/fs/binfmt_em86.c:77:34: error: passing argument 2 of 
> 'copy_strings_kernel' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   retval = copy_strings_kernel(1, _name, bprm);
>   ^
> In file included from /«PKGBUILDDIR»/fs/binfmt_em86.c:14:0:
> /«PKGBUILDDIR»/include/linux/binfmts.h:116:12: note: expected 'const char * 
> const*' but argument is of type 'char **'
>  extern int copy_strings_kernel(int argc, const char *const *argv,
> ^
> 
> The conversion is safe but the C standard says it requires a cast.
> This can easily be fixed by adding the cast, but I also wonder why we
> still build this module.  Even the Kconfig text says it's redundant
> with binfmt_misc.  What do you think?

I don't know if it being used, but it seems that systemd takes care 
of autoloading binfmt_misc automatically, so IMHO I agree that it should
be safe to simply disable binfmt_em86 from the debian alpha kernel.

Question to the alpha kernel maintainers: Maybe binfmt_em86 
should simply be dropped from the kernel source completely?  

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html