19 Oct, 2022

3 commits

  • Added support for passing MU buffer address.

    Signed-off-by: Vabhav Sharma
    Reviewed-by: Pankaj Gupta
    Reviewed-by: Varun Sethi

    Vabhav Sharma
     
  • This patch adds trusted hardware key support for DCP crypto driver.

    Signed-off-by: Kshitiz Varshney
    Reviewed by: Pankaj Gupta

    Kshitiz Varshney
     
  • Current DCP driver implementation doesn't support AES OTP CRYPTO_KEY.
    otp_unique_key & otp_crypto_key handles are generated by U-boot RNG driver
    and on each reboot cycle, device tree fix-up is done using RNG.

    OpenSSL application can input device tree fixed up 16 byte number for
    crypto operations.

    Tested on i.MX6ULL EVK with commands below.

    - Encrypt using UNIQUE_KEY:
    $ openssl aes-128-ecb -p -nosalt -nopad -K "$(hexdump -v -e '"" 1/1 "%02X"'\
    /proc/device-tree/soc/bus@2200000/crypto@2280000/otp_unique_key)" -in \
    openssl_test.txt -out my_encrypted_secret.bin

    - Decrypt using UNIQUE_KEY:
    $ openssl aes-128-ecb -d -p -nosalt -nopad -K "$(hexdump -v -e '"" 1/1 "%02X"'\
    /proc/device-tree/soc/bus@2200000/crypto@2280000/otp_unique_key)" -in \
    my_encrypted_secret.bin -out openssl_decrypt_test.txt

    - Encrypt using CRYPTO_KEY:
    $ openssl aes-128-ecb -p -nosalt -nopad -K "$(hexdump -v -e '"" 1/1 "%02X"'\
    /proc/device-tree/soc/bus@2200000/crypto@2280000/otp_crypto_key)" -in \
    openssl_test.txt -out my_encrypted_secret.bin

    - Decrypt using CRYPTO_KEY:
    $ openssl aes-128-ecb -d -p -nosalt -nopad -K "$(hexdump -v -e '"" 1/1 "%02X"'\
    /proc/device-tree/soc/bus@2200000/crypto@2280000/otp_crypto_key)" -in \
    my_encrypted_secret.bin -out openssl_decrypt_test.txt

    Signed-off-by: Kshitiz Varshney
    Reviewed by: Gaurav Jain

    Kshitiz Varshney
     

18 Oct, 2022

5 commits

  • Consumer of the kernel crypto api, after allocating
    the transformation (tfm), sets the:
    - flag 'is_hbk'
    - structure 'struct hw_bound_key_info hbk_info'
    based on the type of key, the consumer is using.

    This helps:

    - This helps to influence the core processing logic
    for the encapsulated algorithm.
    - This flag is set by the consumer after allocating
    the tfm and before calling the function crypto_xxx_setkey().

    Signed-off-by: Pankaj Gupta
    Reviewed-by: Gaurav Jain
    Reviewed by: Kshitiz Varshney

    Pankaj Gupta
     
  • Changes done:
    - new cmd line option "hw" needs to be suffix, to generate the
    hw bound key.
    for ex:
    $:> keyctl add trusted 'new 32 hw' @s
    $:> keyctl add trusted 'load $(cat ) hw' @s
    - Key-payload, is added with two more information element specific to HBK
    -- flag 'is_hw_bound'
    -- structure 'struct hw_bound_key_info hbk_info'

    Signed-off-by: Pankaj Gupta
    Reviewed-by: Gaurav Jain
    Reviewed by: Kshitiz Varshney

    Pankaj Gupta
     
  • Hardware bound keys buffer has additional information,
    that will be accessed using this new structure.

    structure members are:
    - flags, flags for hardware specific information.
    - key_sz, size of the plain key.

    Signed-off-by: Pankaj Gupta
    Reviewed-by: Gaurav Jain
    Reviewed by: Kshitiz Varshney

    Pankaj Gupta
     
  • - added ele_trng_init to register Hardware Random Number Generator driver
    - added ele_get_random to proceed with random number generation operation.
    ele hwrng driver use this to read the random number with Sentinel.

    Signed-off-by: Gaurav Jain

    Gaurav Jain
     
  • - added ele_get_trng_state to read the TRNG state.
    ele hwrng driver use this to check if TRNG entropy is valid
    and ready to be read.
    - added ele_start_rng to start the initialization of the Sentinel RNG.
    ele hwrng driver use this to start Sentinel RNG when trng state
    is not valid.

    Signed-off-by: Gaurav Jain

    Gaurav Jain
     

17 Oct, 2022

6 commits

  • This will provide a way for SMMU drivers to retrieve StreamIDs
    associated with IORT RMR nodes and use that to set bypass settings
    for those IDs.

    Tested-by: Steven Price
    Tested-by: Laurentiu Tudor
    Tested-by: Hanjun Guo
    Reviewed-by: Hanjun Guo
    Signed-off-by: Shameer Kolothum
    Acked-by: Robin Murphy
    Link: https://lore.kernel.org/r/20220615101044.1972-6-shameerali.kolothum.thodi@huawei.com
    Signed-off-by: Joerg Roedel

    Shameer Kolothum
     
  • Parse through the IORT RMR nodes and populate the reserve region list
    corresponding to a given IOMMU and device(optional). Also, go through
    the ID mappings of the RMR node and retrieve all the SIDs associated
    with it.

    Reviewed-by: Lorenzo Pieralisi
    Tested-by: Steven Price
    Tested-by: Laurentiu Tudor
    Tested-by: Hanjun Guo
    Reviewed-by: Hanjun Guo
    Signed-off-by: Shameer Kolothum
    Acked-by: Robin Murphy
    Link: https://lore.kernel.org/r/20220615101044.1972-5-shameerali.kolothum.thodi@huawei.com
    Signed-off-by: Joerg Roedel

    Shameer Kolothum
     
  • Currently IORT provides a helper to retrieve HW MSI reserve regions.
    Change this to a generic helper to retrieve any IORT related reserve
    regions. This will be useful when we add support for RMR nodes in
    subsequent patches.

    [Lorenzo: For ACPI IORT]

    Reviewed-by: Lorenzo Pieralisi
    Reviewed-by: Christoph Hellwig
    Tested-by: Steven Price
    Tested-by: Laurentiu Tudor
    Tested-by: Hanjun Guo
    Reviewed-by: Hanjun Guo
    Signed-off-by: Shameer Kolothum
    Acked-by: Robin Murphy
    Link: https://lore.kernel.org/r/20220615101044.1972-4-shameerali.kolothum.thodi@huawei.com
    Signed-off-by: Joerg Roedel

    Shameer Kolothum
     
  • At present iort_iommu_msi_get_resv_regions() returns the number of
    MSI reserved regions on success and there are no users for this.
    The reserved region list will get populated anyway for platforms
    that require the HW MSI region reservation. Hence, change the
    function to return void instead.

    Reviewed-by: Christoph Hellwig
    Tested-by: Steven Price
    Tested-by: Laurentiu Tudor
    Reviewed-by: Hanjun Guo
    Signed-off-by: Shameer Kolothum
    Acked-by: Robin Murphy
    Link: https://lore.kernel.org/r/20220615101044.1972-3-shameerali.kolothum.thodi@huawei.com
    Signed-off-by: Joerg Roedel

    Shameer Kolothum
     
  • A callback is introduced to struct iommu_resv_region to free memory
    allocations associated with the reserved region. This will be useful
    when we introduce support for IORT RMR based reserved regions.

    Reviewed-by: Christoph Hellwig
    Tested-by: Steven Price
    Tested-by: Laurentiu Tudor
    Tested-by: Hanjun Guo
    Signed-off-by: Shameer Kolothum
    Acked-by: Robin Murphy
    Link: https://lore.kernel.org/r/20220615101044.1972-2-shameerali.kolothum.thodi@huawei.com
    Signed-off-by: Joerg Roedel

    Shameer Kolothum
     
  • ACPICA commit 87a2e39b8abdfedfb86b0a105708e37e895becd9

    IORT revision is now updated to E.d (ARM DEN 0049E.d) and
    contains a few additions like,
    -Added descriptor in the root complex node for specifying
    PASID width supported by the root complex.
    -Updated RMR node Flags field.
    -Introduced memory access attributes in the RMR node.

    Please note that IORT Rev E.c is deprecated and not supported.

    Link: https://github.com/acpica/acpica/commit/87a2e39b
    Signed-off-by: Shameer Kolothum
    Signed-off-by: Bob Moore
    Signed-off-by: Rafael J. Wysocki

    Shameer Kolothum
     

10 Oct, 2022

1 commit


06 Oct, 2022

1 commit


03 Oct, 2022

1 commit


30 Sep, 2022

2 commits

  • Application shall obtain single fence fd to sync all available engines,
    the fence fd will be created and then configured to all blitter engines.

    The application acquire valid fence fd and perform fence-sync operation,
    the user-space driver can implement upper-level API to expose fence fd,
    the fence fd can be closed as a standard file descriptor after expired.

    Signed-off-by: Xianzhong
    Tested-by: Guangliu Ding

    Xianzhong
     
  • This is the 5.15.71 stable release

    * tag 'v5.15.71': (144 commits)
    Linux 5.15.71
    ext4: use locality group preallocation for small closed files
    ext4: avoid unnecessary spreading of allocations among groups
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    drivers/net/phy/aquantia_main.c
    drivers/tty/serial/fsl_lpuart.c

    Jason Liu
     

28 Sep, 2022

4 commits

  • commit e77cab77f2cb3a1ca2ba8df4af45bb35617ac16d upstream.

    A very common pattern in the drivers is to advance xmit tail
    index and do bookkeeping of Tx'ed characters. Create
    uart_xmit_advance() to handle it.

    Reviewed-by: Andy Shevchenko
    Cc: stable
    Signed-off-by: Ilpo Järvinen
    Link: https://lore.kernel.org/r/20220901143934.8850-2-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman

    Ilpo Järvinen
     
  • [ Upstream commit 1d9a143ee3408349700f44a9197b7ae0e4faae5d ]

    There are already a few definitions of arrays containing
    MULTICAST_LACPDU_ADDR and the next patch will add one more use. These all
    contain the same constant data so define one common instance for all
    bonding code.

    Signed-off-by: Benjamin Poirier
    Signed-off-by: David S. Miller
    Stable-dep-of: 86247aba599e ("net: bonding: Unsync device addresses on ndo_stop")
    Signed-off-by: Sasha Levin

    Benjamin Poirier
     
  • commit 13b0566962914e167cb3238fbe29ced618f07a27 upstream.

    Due to undocumented, hysterical raisins on x86, the CFI jump-table
    sections in .text are needlessly aligned to PMD_SIZE in the vmlinux
    linker script. When compiling a CFI-enabled arm64 kernel with a 64KiB
    page-size, a PMD maps 512MiB of virtual memory and so the .text section
    increases to a whopping 940MiB and blows the final Image up to 960MiB.
    Others report a link failure.

    Since the CFI jump-table requires only instruction alignment, reduce the
    alignment directives to function alignment for parity with other parts
    of the .text section. This reduces the size of the .text section for the
    aforementioned 64KiB page size arm64 kernel to 19MiB for a much more
    reasonable total Image size of 39MiB.

    Cc: Sami Tolvanen
    Cc: Mark Rutland
    Cc: "Mohan Rao .vanimina"
    Cc: Kees Cook
    Cc: Nathan Chancellor
    Cc:
    Link: https://lore.kernel.org/all/CAL_GTzigiNOMYkOPX1KDnagPhJtFNqSK=1USNbS0wUL4PW6-Uw@mail.gmail.com/
    Fixes: cf68fffb66d6 ("add support for Clang CFI")
    Reviewed-by: Mark Rutland
    Tested-by: Mark Rutland
    Reviewed-by: Sami Tolvanen
    Reviewed-by: Kees Cook
    Link: https://lore.kernel.org/r/20220922215715.13345-1-will@kernel.org
    Signed-off-by: Will Deacon
    Signed-off-by: Greg Kroah-Hartman

    Will Deacon
     
  • commit d7f06bdd6ee87fbefa05af5f57361d85e7715b11 upstream.

    As PAGE_SIZE is unsigned long, -1 > PAGE_SIZE when NR_CPUS
    Cc: "Rafael J. Wysocki"
    Cc: Yury Norov
    Cc: stable@vger.kernel.org
    Cc: feng xiangjun
    Reported-by: feng xiangjun
    Signed-off-by: Phil Auld
    Signed-off-by: Yury Norov
    Link: https://lore.kernel.org/r/20220906203542.1796629-1-pauld@redhat.com
    Signed-off-by: Greg Kroah-Hartman

    Phil Auld
     

27 Sep, 2022

1 commit

  • This is the 5.15.70 stable release

    * tag 'v5.15.70': (2444 commits)
    Linux 5.15.70
    ALSA: hda/sigmatel: Fix unused variable warning for beep power change
    cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    arch/arm/boot/dts/imx6ul.dtsi
    arch/arm/mm/mmu.c
    arch/arm64/boot/dts/freescale/imx8mp-evk.dts
    drivers/gpu/drm/imx/dcss/dcss-kms.c
    drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
    drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h
    drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
    drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
    drivers/soc/fsl/Kconfig
    drivers/soc/imx/gpcv2.c
    drivers/usb/dwc3/host.c
    net/dsa/slave.c
    sound/soc/fsl/imx-card.c

    Jason Liu
     

23 Sep, 2022

3 commits

  • commit 683412ccf61294d727ead4a73d97397396e69a6b upstream.

    Flush the CPU caches when memory is reclaimed from an SEV guest (where
    reclaim also includes it being unmapped from KVM's memslots). Due to lack
    of coherency for SEV encrypted memory, failure to flush results in silent
    data corruption if userspace is malicious/broken and doesn't ensure SEV
    guest memory is properly pinned and unpinned.

    Cache coherency is not enforced across the VM boundary in SEV (AMD APM
    vol.2 Section 15.34.7). Confidential cachelines, generated by confidential
    VM guests have to be explicitly flushed on the host side. If a memory page
    containing dirty confidential cachelines was released by VM and reallocated
    to another user, the cachelines may corrupt the new user at a later time.

    KVM takes a shortcut by assuming all confidential memory remain pinned
    until the end of VM lifetime. Therefore, KVM does not flush cache at
    mmu_notifier invalidation events. Because of this incorrect assumption and
    the lack of cache flushing, malicous userspace can crash the host kernel:
    creating a malicious VM and continuously allocates/releases unpinned
    confidential memory pages when the VM is running.

    Add cache flush operations to mmu_notifier operations to ensure that any
    physical memory leaving the guest VM get flushed. In particular, hook
    mmu_notifier_invalidate_range_start and mmu_notifier_release events and
    flush cache accordingly. The hook after releasing the mmu lock to avoid
    contention with other vCPUs.

    Cc: stable@vger.kernel.org
    Suggested-by: Sean Christpherson
    Reported-by: Mingwei Zhang
    Signed-off-by: Mingwei Zhang
    Message-Id:
    Signed-off-by: Paolo Bonzini
    [OP: adjusted KVM_X86_OP_OPTIONAL() -> KVM_X86_OP_NULL, applied
    kvm_arch_guest_memory_reclaimed() call in kvm_set_memslot()]
    Signed-off-by: Ovidiu Panait
    Signed-off-by: Greg Kroah-Hartman

    Mingwei Zhang
     
  • commit e22aa14866684f77b4f6b6cae98539e520ddb731 upstream.

    If we set XFRM security policy by calling setsockopt with option
    IPV6_XFRM_POLICY, the policy will be stored in 'sock_policy' in 'sock'
    struct. However tcp_v6_send_response doesn't look up dst_entry with the
    actual socket but looks up with tcp control socket. This may cause a
    problem that a RST packet is sent without ESP encryption & peer's TCP
    socket can't receive it.
    This patch will make the function look up dest_entry with actual socket,
    if the socket has XFRM policy(sock_policy), so that the TCP response
    packet via this function can be encrypted, & aligned on the encrypted
    TCP socket.

    Tested: We encountered this problem when a TCP socket which is encrypted
    in ESP transport mode encryption, receives challenge ACK at SYN_SENT
    state. After receiving challenge ACK, TCP needs to send RST to
    establish the socket at next SYN try. But the RST was not encrypted &
    peer TCP socket still remains on ESTABLISHED state.
    So we verified this with test step as below.
    [Test step]
    1. Making a TCP state mismatch between client(IDLE) & server(ESTABLISHED).
    2. Client tries a new connection on the same TCP ports(src & dst).
    3. Server will return challenge ACK instead of SYN,ACK.
    4. Client will send RST to server to clear the SOCKET.
    5. Client will retransmit SYN to server on the same TCP ports.
    [Expected result]
    The TCP connection should be established.

    Cc: Maciej Żenczykowski
    Cc: Eric Dumazet
    Cc: Steffen Klassert
    Cc: Sehee Lee
    Signed-off-by: Sewook Seo
    Reviewed-by: Eric Dumazet
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    sewookseo
     
  • commit 40bfe7a86d84cf08ac6a8fe2f0c8bf7a43edd110 upstream.

    Since the stub version of of_dma_configure_id() was added in commit
    a081bd4af4ce ("of/device: Add input id to of_dma_configure()"), it has
    not matched the signature of the full function, leading to build failure
    reports when code using this function is built on !OF configurations.

    Fixes: a081bd4af4ce ("of/device: Add input id to of_dma_configure()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thierry Reding
    Reviewed-by: Frank Rowand
    Acked-by: Lorenzo Pieralisi
    Link: https://lore.kernel.org/r/20220824153256.1437483-1-thierry.reding@gmail.com
    Signed-off-by: Rob Herring
    Signed-off-by: Greg Kroah-Hartman

    Thierry Reding
     

20 Sep, 2022

4 commits

  • [ Upstream commit 0c5f6c0d8201a809a6585b07b6263e9db2c874a3 ]

    The translation table copying code for kdump kernels is currently based
    on the extended root/context entry formats of ECS mode defined in older
    VT-d v2.5, and doesn't handle the scalable mode formats. This causes
    the kexec capture kernel boot failure with DMAR faults if the IOMMU was
    enabled in scalable mode by the previous kernel.

    The ECS mode has already been deprecated by the VT-d spec since v3.0 and
    Intel IOMMU driver doesn't support this mode as there's no real hardware
    implementation. Hence this converts ECS checking in copying table code
    into scalable mode.

    The existing copying code consumes a bit in the context entry as a mark
    of copied entry. It needs to work for the old format as well as for the
    extended context entries. As it's hard to find such a common bit for both
    legacy and scalable mode context entries. This replaces it with a per-
    IOMMU bitmap.

    Fixes: 7373a8cc38197 ("iommu/vt-d: Setup context and enable RID2PASID support")
    Cc: stable@vger.kernel.org
    Reported-by: Jerry Snitselaar
    Tested-by: Wen Jin
    Signed-off-by: Lu Baolu
    Link: https://lore.kernel.org/r/20220817011035.3250131-1-baolu.lu@linux.intel.com
    Signed-off-by: Joerg Roedel
    Signed-off-by: Sasha Levin

    Lu Baolu
     
  • [ Upstream commit e87f4152e542610d0b4c6c8548964a68a59d2040 ]

    Force-inline two stack helpers to fix the following objtool warnings:

    vmlinux.o: warning: objtool: in_task_stack()+0xc: call to task_stack_page() leaves .noinstr.text section
    vmlinux.o: warning: objtool: in_entry_stack()+0x10: call to cpu_entry_stack() leaves .noinstr.text section

    Signed-off-by: Borislav Petkov
    Acked-by: Peter Zijlstra (Intel)
    Link: https://lore.kernel.org/r/20220324183607.31717-2-bp@alien8.de
    Stable-dep-of: 54c3931957f6 ("tracing: hold caller_addr to hardirq_{enable,disable}_ip")
    Signed-off-by: Sasha Levin

    Borislav Petkov
     
  • [ Upstream commit 8b023accc8df70e72f7704d29fead7ca914d6837 ]

    While looking into a bug related to the compiler's handling of addresses
    of labels, I noticed some uses of _THIS_IP_ seemed unused in lockdep.
    Drive by cleanup.

    -Wunused-parameter:
    kernel/locking/lockdep.c:1383:22: warning: unused parameter 'ip'
    kernel/locking/lockdep.c:4246:48: warning: unused parameter 'ip'
    kernel/locking/lockdep.c:4844:19: warning: unused parameter 'ip'

    Signed-off-by: Nick Desaulniers
    Signed-off-by: Peter Zijlstra (Intel)
    Acked-by: Waiman Long
    Link: https://lore.kernel.org/r/20220314221909.2027027-1-ndesaulniers@google.com
    Stable-dep-of: 54c3931957f6 ("tracing: hold caller_addr to hardirq_{enable,disable}_ip")
    Signed-off-by: Sasha Levin

    Nick Desaulniers
     
  • commit 0ebeebcf59601bcfa0284f4bb7abdec051eb856d upstream.

    Fixes the following WARN_ON
    WARNING: CPU: 2 PID: 18678 at fs/nfs/inode.c:123 nfs_clear_inode+0x3b/0x50 [nfs]
    ...
    Call Trace:
    nfs4_evict_inode+0x57/0x70 [nfsv4]
    evict+0xd1/0x180
    dispose_list+0x48/0x60
    evict_inodes+0x156/0x190
    generic_shutdown_super+0x37/0x110
    nfs_kill_super+0x1d/0x40 [nfs]
    deactivate_locked_super+0x36/0xa0

    Signed-off-by: Dave Wysochanski
    Signed-off-by: Trond Myklebust
    Signed-off-by: Greg Kroah-Hartman

    Dave Wysochanski
     

15 Sep, 2022

9 commits

  • [ Upstream commit dc3005703f8cd893d325081c20b400e08377d9bb ]

    Remove CONFIG_SOC_SAMA7 dependency to avoid having #ifdef preprocessor
    directives in driver code (arch/arm/mach-at91/pm.c). This prepares the
    code for next commits.

    Signed-off-by: Claudiu Beznea
    Signed-off-by: Nicolas Ferre
    Link: https://lore.kernel.org/r/20220113144900.906370-2-claudiu.beznea@microchip.com
    Signed-off-by: Sasha Levin

    Claudiu Beznea
     
  • [ Upstream commit 3261400639463a853ba2b3be8bd009c2a8089775 ]

    We got a recent syzbot report [1] showing a possible misuse
    of pfmemalloc page status in TCP zerocopy paths.

    Indeed, for pages coming from user space or other layers,
    using page_is_pfmemalloc() is moot, and possibly could give
    false positives.

    There has been attempts to make page_is_pfmemalloc() more robust,
    but not using it in the first place in this context is probably better,
    removing cpu cycles.

    Note to stable teams :

    You need to backport 84ce071e38a6 ("net: introduce
    __skb_fill_page_desc_noacc") as a prereq.

    Race is more probable after commit c07aea3ef4d4
    ("mm: add a signature in struct page") because page_is_pfmemalloc()
    is now using low order bit from page->lru.next, which can change
    more often than page->index.

    Low order bit should never be set for lru.next (when used as an anchor
    in LRU list), so KCSAN report is mostly a false positive.

    Backporting to older kernel versions seems not necessary.

    [1]
    BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag

    write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:
    __list_add include/linux/list.h:73 [inline]
    list_add include/linux/list.h:88 [inline]
    lruvec_add_folio include/linux/mm_inline.h:105 [inline]
    lru_add_fn+0x440/0x520 mm/swap.c:228
    folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246
    folio_batch_add_and_move mm/swap.c:263 [inline]
    folio_add_lru+0xf1/0x140 mm/swap.c:490
    filemap_add_folio+0xf8/0x150 mm/filemap.c:948
    __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981
    pagecache_get_page+0x26/0x190 mm/folio-compat.c:104
    grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116
    ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988
    generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738
    ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270
    ext4_file_write_iter+0x2e3/0x1210
    call_write_iter include/linux/fs.h:2187 [inline]
    new_sync_write fs/read_write.c:491 [inline]
    vfs_write+0x468/0x760 fs/read_write.c:578
    ksys_write+0xe8/0x1a0 fs/read_write.c:631
    __do_sys_write fs/read_write.c:643 [inline]
    __se_sys_write fs/read_write.c:640 [inline]
    __x64_sys_write+0x3e/0x50 fs/read_write.c:640
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd

    read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:
    page_is_pfmemalloc include/linux/mm.h:1740 [inline]
    __skb_fill_page_desc include/linux/skbuff.h:2422 [inline]
    skb_fill_page_desc include/linux/skbuff.h:2443 [inline]
    tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018
    do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075
    tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]
    tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150
    inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833
    kernel_sendpage+0x184/0x300 net/socket.c:3561
    sock_sendpage+0x5a/0x70 net/socket.c:1054
    pipe_to_sendpage+0x128/0x160 fs/splice.c:361
    splice_from_pipe_feed fs/splice.c:415 [inline]
    __splice_from_pipe+0x222/0x4d0 fs/splice.c:559
    splice_from_pipe fs/splice.c:594 [inline]
    generic_splice_sendpage+0x89/0xc0 fs/splice.c:743
    do_splice_from fs/splice.c:764 [inline]
    direct_splice_actor+0x80/0xa0 fs/splice.c:931
    splice_direct_to_actor+0x305/0x620 fs/splice.c:886
    do_splice_direct+0xfb/0x180 fs/splice.c:974
    do_sendfile+0x3bf/0x910 fs/read_write.c:1249
    __do_sys_sendfile64 fs/read_write.c:1317 [inline]
    __se_sys_sendfile64 fs/read_write.c:1303 [inline]
    __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd

    value changed: 0x0000000000000000 -> 0xffffea0004a1d288

    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022

    Fixes: c07aea3ef4d4 ("mm: add a signature in struct page")
    Reported-by: syzbot
    Signed-off-by: Eric Dumazet
    Cc: Shakeel Butt
    Reviewed-by: Shakeel Butt
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    Eric Dumazet
     
  • [ Upstream commit 84ce071e38a6e25ea3ea91188e5482ac1f17b3af ]

    Managed pages contain pinned userspace pages and controlled by upper
    layers, there is no need in tracking skb->pfmemalloc for them. Introduce
    a helper for filling frags but ignoring page tracking, it'll be needed
    later.

    Signed-off-by: Pavel Begunkov
    Signed-off-by: Jakub Kicinski
    Signed-off-by: Sasha Levin

    Pavel Begunkov
     
  • [ Upstream commit ac56a0b48da86fd1b4389632fb7c4c8a5d86eefa ]

    Because rxrpc pretends to be a tunnel on top of a UDP/UDP6 socket, allowing
    it to siphon off UDP packets early in the handling of received UDP packets
    thereby avoiding the packet going through the UDP receive queue, it doesn't
    get ICMP packets through the UDP ->sk_error_report() callback. In fact, it
    doesn't appear that there's any usable option for getting hold of ICMP
    packets.

    Fix this by adding a new UDP encap hook to distribute error messages for
    UDP tunnels. If the hook is set, then the tunnel driver will be able to
    see ICMP packets. The hook provides the offset into the packet of the UDP
    header of the original packet that caused the notification.

    An alternative would be to call the ->error_handler() hook - but that
    requires that the skbuff be cloned (as ip_icmp_error() or ipv6_cmp_error()
    do, though isn't really necessary or desirable in rxrpc's case is we want
    to parse them there and then, not queue them).

    Changes
    =======
    ver #3)
    - Fixed an uninitialised variable.

    ver #2)
    - Fixed some missing CONFIG_AF_RXRPC_IPV6 conditionals.

    Fixes: 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit 7a94b83a7dc551607b6c4400df29151e6a951f07 ]

    On SAMA7G5, when resuming from backup and self-refresh, the bootloader
    performs DDR PHY recalibration by restoring the value of ZQ0SR0 (stored
    in RAM by Linux before going to backup and self-refresh). It has been
    discovered that the current procedure doesn't work for all possible values
    that might go to ZQ0SR0 due to hardware bug. The workaround to this is to
    avoid storing some values in ZQ0SR0. Thus Linux will read the ZQ0SR0
    register and cache its value in RAM after processing it (using
    modified_gray_code array). The bootloader will restore the processed value.

    Fixes: d2d4716d8384 ("ARM: at91: pm: save ddr phy calibration data to securam")
    Suggested-by: Frederic Schumacher
    Signed-off-by: Claudiu Beznea
    Link: https://lore.kernel.org/r/20220826083927.3107272-4-claudiu.beznea@microchip.com
    Signed-off-by: Sasha Levin

    Claudiu Beznea
     
  • [ Upstream commit a02875c4cbd6f3d2f33d70cc158a19ef02d4b84f ]

    It has been discovered that on some parts, from time to time, self-refresh
    procedure doesn't work as expected. Debugging and investigating it proved
    that disabling AC DLL introduce glitches in RAM controllers which
    leads to unexpected behavior. This is confirmed as a hardware bug. DLL
    bypass disables 3 DLLs: 2 DX DLLs and AC DLL. Thus, keep only DX DLLs
    disabled. This introduce 6mA extra current consumption on VDDCORE when
    switching to any ULP mode or standby mode but the self-refresh procedure
    still works.

    Fixes: f0bbf17958e8 ("ARM: at91: pm: add self-refresh support for sama7g5")
    Suggested-by: Frederic Schumacher
    Signed-off-by: Claudiu Beznea
    Tested-by: Cristian Birsan
    Link: https://lore.kernel.org/r/20220826083927.3107272-3-claudiu.beznea@microchip.com
    Signed-off-by: Sasha Levin

    Claudiu Beznea
     
  • [ Upstream commit 67f4b5dc49913abcdb5cc736e73674e2f352f81d ]

    Currently, when the writeback code detects a server reboot, it redirties
    any pages that were not committed to disk, and it sets the flag
    NFS_CONTEXT_RESEND_WRITES in the nfs_open_context of the file descriptor
    that dirtied the file. While this allows the file descriptor in question
    to redrive its own writes, it violates the fsync() requirement that we
    should be synchronising all writes to disk.
    While the problem is infrequent, we do see corner cases where an
    untimely server reboot causes the fsync() call to abandon its attempt to
    sync data to disk and causing data corruption issues due to missed error
    conditions or similar.

    In order to tighted up the client's ability to deal with this situation
    without introducing livelocks, add a counter that records the number of
    times pages are redirtied due to a server reboot-like condition, and use
    that in fsync() to redrive the sync to disk.

    Fixes: 2197e9b06c22 ("NFS: Fix up fsync() when the server rebooted")
    Cc: stable@vger.kernel.org
    Signed-off-by: Trond Myklebust
    Signed-off-by: Sasha Levin

    Trond Myklebust
     
  • [ Upstream commit e591b298d7ecb851e200f65946e3d53fe78a3c4f ]

    Save some space in the nfs_inode by setting up an anonymous union with
    the fields that are peculiar to a specific type of filesystem object.

    Signed-off-by: Trond Myklebust
    Signed-off-by: Sasha Levin

    Trond Myklebust
     
  • [ Upstream commit ff81dfb5d721fff87bd516c558847f6effb70031 ]

    If a user is doing 'ls -l', we have a heuristic in GETATTR that tells
    the readdir code to try to use READDIRPLUS in order to refresh the inode
    attributes. In certain cirumstances, we also try to invalidate the
    remaining directory entries in order to ensure this refresh.

    If there are multiple readers of the directory, we probably should avoid
    invalidating the page cache, since the heuristic breaks down in that
    situation anyway.

    Signed-off-by: Trond Myklebust
    Tested-by: Benjamin Coddington
    Reviewed-by: Benjamin Coddington
    Signed-off-by: Sasha Levin

    Trond Myklebust