Re: Issues with the first PowerPC updates for the kernel 6.1

[Christian Zigotzky <chzigotzky@xenosoft.de>]

On 29 October 2022 at 01:44 pm, Christian Zigotzky wrote:
> On 17 October 2022 at 09:53 am, Christian Zigotzky wrote:
>>> On 17. Oct 2022, at 02:43, Michael Ellerman <mpe@ellerman.id.au> wrote:
>>> Previously BIG_ENDIAN && GENERIC_CPU would use -mcpu=power5, now it 
>>> uses
>>> -mcpu=power4.
>> Maybe this is the issue. We will wait and not release the RC1 for 
>> testing because it is a risk for our testers to test these new 
>> kernels because of this issue.
>>
>>>
>>> cheers
>>>
>>>
> I compiled the RC2 of kernel 6.1 today.
>
> After the first boot of the RC2, the file system was immediately to 
> 100% used.  This is the same issue we have seen with the git kernel 3 
> weeks ago.
>
> The Cyrus+ and Nemo boards are affected.
>
> I wrote 3 weeks ago:
>
> Hi All,
>
> I successfully compiled the latest git kernel with the first PowerPC 
> updates yesterday.
>
> Unfortunately this kernel is really dangerous. Many things for example 
> Network Manager and LightDM don't work anymore and produced several 
> gigabyte of config files till the partition has been filled.
>
> I deleted some files like the resolv.conf that had a size over 200 GB!
>
> Unfortunately, MintPPC was still damaged. For example LightDM doesn't 
> work anymore and the MATE desktop doesn't display any icons anymore 
> because Caja wasn't able to reserve memory anymore.
>
> In this case, bisecting isn't an option and I have to wait some weeks. 
> It is really difficult to find the issue if the userland will damaged 
> again and again.
>
> Cheers,
> Christian
>
> ---
>
> Maybe there is an issue in my kernel configs. Could you please check 
> the configs? Please find attached the configs. Could you please test 
> the RC2 on your FSL and pasemi machines?
>
> Thanks,
> Christian
>
Hi All,

I bisected today because Void PPC is recovering after a reboot. Memory 
space is released again. [1]

Result: c2e7a19827eec443a7cbe85e8d959052412d6dc3 (powerpc: Use generic 
fallocate compatibility syscall) is the first bad commit. [2]

I was able to create a patch for reverting this bad commit. [3]

I compiled the kernel with this patch. After that the kernel works 
without any problems.

Please check the first bad commit. [2]

Thanks,
Christian


[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=56099#p56099
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2e7a19827eec443a7cbe85e8d959052412d6dc3
[3] syscall.patch:

diff -rupN a/arch/powerpc/include/asm/syscalls.h 
b/arch/powerpc/include/asm/syscalls.h
--- a/arch/powerpc/include/asm/syscalls.h       2022-10-30 
13:53:28.956001116 +0100
+++ b/arch/powerpc/include/asm/syscalls.h       2022-10-30 
13:55:39.166300756 +0100
@@ -15,6 +15,7 @@
  #include <asm/unistd.h>
  #include <asm/ucontext.h>

+long compat_sys_fallocate(int fd, int mode, u32 offset1, u32 offset2, 
u32 len1, u32 len2);
  #ifndef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
  long sys_ni_syscall(void);
  #else
diff -rupN a/arch/powerpc/include/asm/unistd.h 
b/arch/powerpc/include/asm/unistd.h
--- a/arch/powerpc/include/asm/unistd.h 2022-10-30 13:53:28.957001103 +0100
+++ b/arch/powerpc/include/asm/unistd.h 2022-10-30 13:56:44.851441888 +0100
@@ -45,7 +45,6 @@
  #define __ARCH_WANT_SYS_UTIME
  #define __ARCH_WANT_SYS_NEWFSTATAT
  #define __ARCH_WANT_COMPAT_STAT
-#define __ARCH_WANT_COMPAT_FALLOCATE
  #define __ARCH_WANT_COMPAT_SYS_SENDFILE
  #endif
  #define __ARCH_WANT_SYS_FORK
diff -rupN a/arch/powerpc/kernel/sys_ppc32.c 
b/arch/powerpc/kernel/sys_ppc32.c
--- a/arch/powerpc/kernel/sys_ppc32.c   2022-10-30 13:53:28.967000972 +0100
+++ b/arch/powerpc/kernel/sys_ppc32.c   2022-10-30 13:58:28.993078689 +0100
@@ -97,6 +97,13 @@ PPC32_SYSCALL_DEFINE4(ppc_truncate64,
         return ksys_truncate(path, merge_64(len1, len2));
  }

+long compat_sys_fallocate(int fd, int mode, u32 offset1, u32 offset2,
+                                    u32 len1, u32 len2)
+{
+       return ksys_fallocate(fd, mode, merge_64(offset1, offset2),
+                            merge_64(len1, len2));
+}
+
  PPC32_SYSCALL_DEFINE4(ppc_ftruncate64,
                        unsigned int, fd, u32, reg4,
                        unsigned long, len1, unsigned long, len2)