On Wed, 10 Mar 2021 at 18:56, <gregkh(a)linuxfoundation.org> wrote:
>
> From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
>
> From: Alex Elder <elder(a)linaro.org>
>
> [ Upstream commit f849afcc8c3b27d7b50827e95b60557f24184df0 ]
>
> IPA v4.2 has a hardware quirk that requires the AP to allocate GSI
> channels for the modem to use. It is recommended that these modem
> channels get stopped (with a HALT generic command) by the AP when
> its IPA driver gets removed.
>
> The AP has no way of knowing the current state of a modem channel.
> So when the IPA driver issues a HALT command it's possible the
> channel is not running, and in that case we get an error indication.
> This error simply means we didn't need to stop the channel, so we
> can ignore it.
>
> This patch adds an explanation for this situation, and arranges for
> this condition to *not* report an error message.
>
> Signed-off-by: Alex Elder <elder(a)linaro.org>
> Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
> ---
> drivers/net/ipa/gsi.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
> index 2a65efd3e8da..48ee43b89fec 100644
> --- a/drivers/net/ipa/gsi.c
> +++ b/drivers/net/ipa/gsi.c
> @@ -1052,10 +1052,32 @@ static void gsi_isr_gp_int1(struct gsi *gsi)
> u32 result;
> u32 val;
>
> + /* This interrupt is used to handle completions of the two GENERIC
> + * GSI commands. We use these to allocate and halt channels on
> + * the modem's behalf due to a hardware quirk on IPA v4.2. Once
> + * allocated, the modem "owns" these channels, and as a result we
> + * have no way of knowing the channel's state at any given time.
> + *
> + * It is recommended that we halt the modem channels we allocated
> + * when shutting down, but it's possible the channel isn't running
> + * at the time we issue the HALT command. We'll get an error in
> + * that case, but it's harmless (the channel is already halted).
> + *
> + * For this reason, we silently ignore a CHANNEL_NOT_RUNNING error
> + * if we receive it.
> + */
> val = ioread32(gsi->virt + GSI_CNTXT_SCRATCH_0_OFFSET);
> result = u32_get_bits(val, GENERIC_EE_RESULT_FMASK);
> - if (result != GENERIC_EE_SUCCESS_FVAL)
> +
> + switch (result) {
> + case GENERIC_EE_SUCCESS_FVAL:
> + case GENERIC_EE_CHANNEL_NOT_RUNNING_FVAL:
While building stable rc 5.10 for arm64 the build failed due to
the following errors / warnings.
make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=arm64
CROSS_COMPILE=aarch64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
clang'
drivers/net/ipa/gsi.c:1074:7: error: use of undeclared identifier
'GENERIC_EE_CHANNEL_NOT_RUNNING_FVAL'
case GENERIC_EE_CHANNEL_NOT_RUNNING_FVAL:
^
1 error generated.
make[4]: *** [scripts/Makefile.build:279: drivers/net/ipa/gsi.o] Error 1
Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org>
Build log link,
https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc/-/jobs/108686…
--
Linaro LKFT
https://lkft.linaro.org
Hi Peter,
On Fri, 19 Feb 2021 at 04:43, Peter Xu <peterx(a)redhat.com> wrote:
>
> Huge pmd sharing could bring problem to userfaultfd. The thing is that
> userfaultfd is running its logic based on the special bits on page table
> entries, however the huge pmd sharing could potentially share page table
> entries for different address ranges. That could cause issues on either:
>
> - When sharing huge pmd page tables for an uffd write protected range, the
> newly mapped huge pmd range will also be write protected unexpectedly, or,
>
> - When we try to write protect a range of huge pmd shared range, we'll first
> do huge_pmd_unshare() in hugetlb_change_protection(), however that also
> means the UFFDIO_WRITEPROTECT could be silently skipped for the shared
> region, which could lead to data loss.
>
> Since at it, a few other things are done altogether:
>
> - Move want_pmd_share() from mm/hugetlb.c into linux/hugetlb.h, because
> that's definitely something that arch code would like to use too
>
> - ARM64 currently directly check against CONFIG_ARCH_WANT_HUGE_PMD_SHARE when
> trying to share huge pmd. Switch to the want_pmd_share() helper.
>
> Since at it, move vma_shareable() from huge_pmd_share() into want_pmd_share().
>
> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com>
> Reviewed-by: Axel Rasmussen <axelrasmussen(a)google.com>
> Signed-off-by: Peter Xu <peterx(a)redhat.com>
> ---
> arch/arm64/mm/hugetlbpage.c | 3 +--
> include/linux/hugetlb.h | 2 ++
> include/linux/userfaultfd_k.h | 9 +++++++++
> mm/hugetlb.c | 20 ++++++++++++++------
> 4 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 6e3bcffe2837..58987a98e179 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -284,8 +284,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
> */
> ptep = pte_alloc_map(mm, pmdp, addr);
> } else if (sz == PMD_SIZE) {
> - if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
> - pud_none(READ_ONCE(*pudp)))
> + if (want_pmd_share(vma, addr) && pud_none(READ_ONCE(*pudp)))
While building Linux next 20210310 tag for arm64 architecture with
- CONFIG_ARM64_64K_PAGES=y
enabled the build failed due to below errors / warnings
make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=arm64
CROSS_COMPILE=aarch64-linux-gnu- 'CC=sccache aarch64-linux-gnu-gcc'
'HOSTCC=sccache gcc'
aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
aarch64-linux-gnu-ld: Unexpected run-time procedure linkages detected!
aarch64-linux-gnu-ld: arch/arm64/mm/hugetlbpage.o: in function `huge_pte_alloc':
hugetlbpage.c:(.text+0x7d8): undefined reference to `want_pmd_share'
Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org>
Steps to reproduce:
----------------------------
# TuxMake is a command line tool and Python library that provides
# portable and repeatable Linux kernel builds across a variety of
# architectures, toolchains, kernel configurations, and make targets.
#
# TuxMake supports the concept of runtimes.
# See https://docs.tuxmake.org/runtimes/, for that to work it requires
# that you install podman or docker on your system.
#
# To install tuxmake on your system globally:
# sudo pip3 install -U tuxmake
#
# See https://docs.tuxmake.org/ for complete documentation.
tuxmake --runtime podman --target-arch arm64 --toolchain gcc-9
--kconfig defconfig --kconfig-add
https://builds.tuxbuild.com/1pYCSoc1oGtPWlPgLAJxbHx07kL/config
Build link,
https://builds.tuxbuild.com/1pYCSoc1oGtPWlPgLAJxbHx07kL/
--
Linaro LKFT
https://lkft.linaro.org