Re: [PATCH v2 3/9] ARM: oabi-compat: add epoll_pwait handler

[Arnd Bergmann]

On Mon, Sep 21, 2020 at 2:54 PM Sasha Levin <sashal@xxxxxxxxxx> wrote:
>
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: 369842658a36 ("ARM: 5677/1: ARM support for TIF_RESTORE_SIGMASK/pselect6/ppoll/epoll_pwait").
>
> The bot has tested the following trees: v5.8.10, v5.4.66, v4.19.146, v4.14.198, v4.9.236, v4.4.236.
>
> v5.8.10: Build OK!
> v5.4.66: Build OK!
> v4.19.146: Build OK!
> v4.14.198: Build OK!
> v4.9.236: Failed to apply! Possible dependencies:
>     00bf25d693e7 ("y2038: use time32 syscall names on 32-bit")
>     17435e5f8cf3 ("time: Introduce CONFIG_COMPAT_32BIT_TIME")
>     338035edc9b9 ("arm: Wire up restartable sequences system call")
>     4e2648db9c5f ("ARM: remove indirection of asm/mach-types.h")
>     73aeb2cbcdc9 ("ARM: 8787/1: wire up io_pgetevents syscall")
>     78594b95998f ("ARM: add migrate_pages() system call")
>     96a8fae0fe09 ("ARM: convert to generated system call tables")
>     a1016e94cce9 ("ARM: wire up statx syscall")
>     c281634c8652 ("ARM: compat: remove KERNEL_DS usage in sys_oabi_epoll_ctl()")
>     d4703ddafd1e ("time: Introduce CONFIG_64BIT_TIME in architectures")
>
> v4.4.236: Failed to apply! Possible dependencies:
>     00bf25d693e7 ("y2038: use time32 syscall names on 32-bit")
>     03590cb56d5d ("ARM: wire up copy_file_range() syscall")
>     0d4a619b64ba ("dma-mapping: make the generic coherent dma mmap implementation optional")
>     17435e5f8cf3 ("time: Introduce CONFIG_COMPAT_32BIT_TIME")
>     4e2648db9c5f ("ARM: remove indirection of asm/mach-types.h")
>     96a8fae0fe09 ("ARM: convert to generated system call tables")
>     c281634c8652 ("ARM: compat: remove KERNEL_DS usage in sys_oabi_epoll_ctl()")
>     d4703ddafd1e ("time: Introduce CONFIG_64BIT_TIME in architectures")
>     f2335a2a0a59 ("ARM: wire up preadv2 and pwritev2 syscalls")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?

I wouldn't worry too much about the failed backport in this case, as I
don't think there are any actual users of this code on older stable
kernels, and even if there are they are unlikely to start using
epoll_pwait.

      Arnd