[GIT PULL] arm64 updates 6.15-rc1

[GIT PULL] arm64 updates 6.15-rc1

[Catalin Marinas]

Hi Linus,

Please pull the arm64 updates for 6.15-rc1 below. Nothing major this
time around. Apart from the usual perf/PMU updates, some page table
cleanups, the notable features are average CPU frequency based on the
AMUv1 counters, CONFIG_HOTPLUG_SMT and MOPS instructions (memcpy/memset)
in the uaccess routines.

Thanks.

The following changes since commit 0ad2507d5d93f39619fc42372c347d6006b64319:

  Linux 6.14-rc3 (2025-02-16 14:02:44 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream

for you to fetch changes up to 64fa6b9322a904198589c0479dca6f2ed7f2eb04:

  Merge branch 'for-next/el2-enable-feat-pmuv3p9' into for-next/core (2025-03-25 19:32:32 +0000)

----------------------------------------------------------------
arm64 updates for 6.15:

Perf and PMUs:

 - Support for the "Rainier" CPU PMU from Arm

 - Preparatory driver changes and cleanups that pave the way for BRBE
   support

 - Support for partial virtualisation of the Apple-M1 PMU

 - Support for the second event filter in Arm CSPMU designs

 - Minor fixes and cleanups (CMN and DWC PMUs)

 - Enable EL2 requirements for FEAT_PMUv3p9

Power, CPU topology:

 - Support for AMUv1-based average CPU frequency

 - Run-time SMT control wired up for arm64 (CONFIG_HOTPLUG_SMT). It adds
   a generic topology_is_primary_thread() function overridden by x86 and
   powerpc

New(ish) features:

 - MOPS (memcpy/memset) support for the uaccess routines

Security/confidential compute:

 - Fix the DMA address for devices used in Realms with Arm CCA. The
   CCA architecture uses the address bit to differentiate between shared
   and private addresses

 - Spectre-BHB: assume CPUs Linux doesn't know about vulnerable by
   default

Memory management clean-ups:

 - Drop the P*D_TABLE_BIT definition in preparation for 128-bit PTEs

 - Some minor page table accessor clean-ups

 - PIE/POE (permission indirection/overlay) helpers clean-up

Kselftests:

 - MTE: skip hugetlb tests if MTE is not supported on such mappings and
   user correct naming for sync/async tag checking modes

Miscellaneous:

 - Add a PKEY_UNRESTRICTED definition as 0 to uapi (toolchain people
   request)

 - Sysreg updates for new register fields

 - CPU type info for some Qualcomm Kryo cores

----------------------------------------------------------------
Anshuman Khandual (16):
      arm64/sysreg: Update register fields for ID_AA64MMFR0_EL1
      arm64/sysreg: Add register fields for HDFGRTR2_EL2
      arm64/sysreg: Add register fields for HDFGWTR2_EL2
      arm64/sysreg: Add register fields for HFGITR2_EL2
      arm64/sysreg: Add register fields for HFGRTR2_EL2
      arm64/sysreg: Add register fields for HFGWTR2_EL2
      arm64/mm: Convert __pte_to_phys() and __phys_to_pte_val() as functions
      arm64/hugetlb: Consistently use pud_sect_supported()
      arm64/boot: Enable EL2 requirements for FEAT_PMUv3p9
      KVM: arm64: ptdump: Test PMD_TYPE_MASK for block mapping
      arm64/ptdump: Test PMD_TYPE_MASK for block mapping
      arm64/mm: Clear PXX_TYPE_MASK in mk_[pmd|pud]_sect_prot()
      arm64/mm: Clear PXX_TYPE_MASK and set PXD_TYPE_SECT in [pmd|pud]_mkhuge()
      arm64/mm: Check PXD_TYPE_TABLE in [p4d|pgd]_bad()
      arm64/mm: Drop PXD_TABLE_BIT
      arm64/mm: Define PTDESC_ORDER

Ard Biesheuvel (1):
      arm64/kernel: Always use level 2 or higher for early mappings

Beata Michalska (5):
      cpufreq: Allow arch_freq_get_on_cpu to return an error
      cpufreq: Introduce an optional cpuinfo_avg_freq sysfs entry
      arm64: Provide an AMU-based version of arch_freq_get_on_cpu
      arm64: Update AMU-based freq scale factor on entering idle
      arm64: Utilize for_each_cpu_wrap for reference lookup

Catalin Marinas (5):
      kselftest/arm64: mte: Use the correct naming for tag check modes in check_hugetlb_options.c
      kselftest/arm64: mte: Skip the hugetlb tests if MTE not supported on such mappings
      Merge branches 'for-next/amuv1-avg-freq', 'for-next/pkey_unrestricted', 'for-next/sysreg', 'for-next/misc', 'for-next/pgtable-cleanups', 'for-next/kselftest', 'for-next/uaccess-mops', 'for-next/pie-poe-cleanup', 'for-next/cputype-kryo', 'for-next/cca-dma-address', 'for-next/drop-pxd_table_bit' and 'for-next/spectre-bhb-assume-vulnerable', remote-tracking branch 'arm64/for-next/perf' into for-next/core
      Merge branch 'for-next/smt-control' into for-next/core
      Merge branch 'for-next/el2-enable-feat-pmuv3p9' into for-next/core

Douglas Anderson (7):
      arm64: cputype: Add QCOM_CPU_PART_KRYO_3XX_GOLD
      arm64: cputype: Add comments about Qualcomm Kryo 5XX and 6XX cores
      arm64: errata: Add QCOM_KRYO_4XX_GOLD to the spectre_bhb_k24_list
      arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB
      arm64: errata: Add KRYO 2XX/3XX/4XX silver cores to Spectre BHB safe list
      arm64: cputype: Add MIDR_CORTEX_A76AE
      arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected() lists

Ionela Voinescu (1):
      arch_topology: init capacity_freq_ref to 0

James Clark (2):
      arm64/sysreg: Fix unbalanced closing block
      arm64/sysreg: Enforce whole word match for open/close tokens

Kevin Brodsky (3):
      arm64/sysreg: Improve PIR/POR helpers
      arm64/sysreg: Rename POE_RXW to POE_RWX
      arm64/sysreg: Move POR_EL0_INIT to asm/por.h

Kristina Martšenko (3):
      arm64: extable: Add fixup handling for uaccess CPY* instructions
      arm64: mm: Handle PAN faults on uaccess CPY* instructions
      arm64: lib: Use MOPS for usercopy routines

Madhavan Srinivasan (1):
      selftest/powerpc/mm/pkey: fix build-break introduced by commit 00894c3fc917

Mark Rutland (3):
      perf: arm_pmu: Don't disable counter in armpmu_add()
      perf: arm_pmuv3: Don't disable counter in armv8pmu_enable_event()
      perf: arm_pmu: Move PMUv3-specific data

Oliver Upton (2):
      drivers/perf: apple_m1: Refactor event select/filter configuration
      drivers/perf: apple_m1: Support host/guest event filtering

Rob Herring (Arm) (4):
      perf: arm_pmuv3: Call kvm_vcpu_pmu_resync_el0() before enabling counters
      perf: arm_v7_pmu: Drop obvious comments for enabling/disabling counters and interrupts
      perf: arm_v7_pmu: Don't disable counter in (armv7|krait_|scorpion_)pmu_enable_event()
      perf: apple_m1: Don't disable counter in m1_pmu_enable_event()

Robin Murphy (5):
      perf/arm-cmn: Minor event type housekeeping
      perf/arm_cspmu: Move register definitons to header
      perf/arm_cspmu: Generalise event filtering
      perf/arm_cspmu: Add PMEVFILT2R support
      perf/arm_cspmu: Fix missing io.h include

Ryan Roberts (2):
      arm64/mm: Check PUD_TYPE_TABLE in pud_bad()
      arm64/mm: Check pmd_table() in pmd_trans_huge()

Suzuki K Poulose (3):
      dma: Fix encryption bit clearing for dma_to_phys
      dma: Introduce generic dma_addr_*crypted helpers
      arm64: realm: Use aliased addresses for device DMA to shared buffers

Thomas Weißschuh (1):
      arm64: mm: Don't use %pK through printk

Vincenzo Frascino (1):
      perf: arm_pmuv3: Add support for ARM Rainier PMU

Will Deacon (1):
      Merge branch 'perf/m1-guest-events' of git://git.kernel.org/pub/scm/linux/kernel/git/oupton/linux into for-next/perf

Yicong Yang (4):
      cpu/SMT: Provide a default topology_is_primary_thread()
      arch_topology: Support SMT control for OF based system
      arm64: topology: Support SMT control on ACPI based system
      arm64: Kconfig: Enable HOTPLUG_SMT

Yue Haibing (1):
      arm64/fpsimd: Remove unused declaration fpsimd_kvm_prepare()

Yunhui Cui (2):
      perf/dwc_pcie: fix some unreleased resources
      perf/dwc_pcie: fix duplicate pci_dev devices

Yury Khrustalev (3):
      mm/pkey: Add PKEY_UNRESTRICTED macro
      selftests/mm: Use PKEY_UNRESTRICTED macro
      selftests/powerpc: Use PKEY_UNRESTRICTED macro

 Documentation/admin-guide/pm/cpufreq.rst           |  17 +-
 Documentation/arch/arm64/booting.rst               |  22 +++
 arch/arm64/Kconfig                                 |   3 +-
 arch/arm64/include/asm/apple_m1_pmu.h              |   1 +
 arch/arm64/include/asm/asm-extable.h               |  10 +-
 arch/arm64/include/asm/asm-uaccess.h               |   4 +
 arch/arm64/include/asm/cputype.h                   |  14 ++
 arch/arm64/include/asm/el2_setup.h                 |  25 +++
 arch/arm64/include/asm/extable.h                   |   4 +-
 arch/arm64/include/asm/fpsimd.h                    |   1 -
 arch/arm64/include/asm/kernel-pgtable.h            |   8 +-
 arch/arm64/include/asm/mem_encrypt.h               |  11 ++
 arch/arm64/include/asm/pgtable-hwdef.h             |  35 ++--
 arch/arm64/include/asm/pgtable-prot.h              |  36 ++--
 arch/arm64/include/asm/pgtable.h                   |  80 +++++---
 arch/arm64/include/asm/por.h                       |  11 +-
 arch/arm64/include/asm/spectre.h                   |   1 -
 arch/arm64/include/asm/sysreg.h                    |  15 +-
 arch/arm64/kernel/pi/map_range.c                   |   6 +-
 arch/arm64/kernel/proton-pack.c                    | 208 +++++++++++----------
 arch/arm64/kernel/signal.c                         |   2 +-
 arch/arm64/kernel/topology.c                       | 182 +++++++++++++++++-
 arch/arm64/kvm/at.c                                |   8 +-
 arch/arm64/kvm/ptdump.c                            |   4 +-
 arch/arm64/lib/clear_user.S                        |  25 ++-
 arch/arm64/lib/copy_from_user.S                    |  10 +
 arch/arm64/lib/copy_template.S                     |  10 +
 arch/arm64/lib/copy_to_user.S                      |  10 +
 arch/arm64/mm/extable.c                            |  40 +++-
 arch/arm64/mm/fault.c                              |   4 +-
 arch/arm64/mm/hugetlbpage.c                        |  20 +-
 arch/arm64/mm/kasan_init.c                         |   6 +-
 arch/arm64/mm/mmu.c                                |  10 +-
 arch/arm64/mm/physaddr.c                           |   2 +-
 arch/arm64/mm/ptdump.c                             |   4 +-
 arch/arm64/tools/gen-sysreg.awk                    |  31 +--
 arch/arm64/tools/sysreg                            | 105 ++++++++++-
 arch/powerpc/include/asm/topology.h                |   1 +
 arch/x86/include/asm/topology.h                    |   2 +-
 arch/x86/kernel/cpu/aperfmperf.c                   |   2 +-
 arch/x86/kernel/cpu/proc.c                         |   7 +-
 drivers/base/arch_topology.c                       |  26 ++-
 drivers/cpufreq/Kconfig.x86                        |  12 ++
 drivers/cpufreq/cpufreq.c                          |  38 +++-
 drivers/perf/apple_m1_cpu_pmu.c                    |  70 ++++---
 drivers/perf/arm-cmn.c                             |   5 +-
 drivers/perf/arm_cspmu/ampere_cspmu.c              |  32 +---
 drivers/perf/arm_cspmu/arm_cspmu.c                 |  81 ++------
 drivers/perf/arm_cspmu/arm_cspmu.h                 |  57 +++++-
 drivers/perf/arm_cspmu/nvidia_cspmu.c              |  22 ++-
 drivers/perf/arm_pmu.c                             |   8 +-
 drivers/perf/arm_pmuv3.c                           |  11 +-
 drivers/perf/arm_v7_pmu.c                          |  50 -----
 drivers/perf/dwc_pcie_pmu.c                        |  51 +++--
 include/linux/cpufreq.h                            |   2 +-
 include/linux/dma-direct.h                         |  13 +-
 include/linux/mem_encrypt.h                        |  23 +++
 include/linux/perf/arm_pmu.h                       |  13 +-
 include/linux/topology.h                           |  23 +++
 include/uapi/asm-generic/mman-common.h             |   1 +
 .../selftests/arm64/mte/check_hugetlb_options.c    |  19 +-
 tools/testing/selftests/mm/mseal_test.c            |   6 +-
 tools/testing/selftests/mm/pkey-helpers.h          |   3 +-
 tools/testing/selftests/mm/pkey_sighandler_tests.c |   4 +-
 tools/testing/selftests/mm/protection_keys.c       |   2 +-
 tools/testing/selftests/powerpc/include/pkeys.h    |   5 +-
 .../testing/selftests/powerpc/mm/pkey_exec_prot.c  |   2 +-
 tools/testing/selftests/powerpc/mm/pkey_siginfo.c  |   2 +-
 tools/testing/selftests/powerpc/ptrace/core-pkey.c |   6 +-
 .../testing/selftests/powerpc/ptrace/ptrace-pkey.c |   6 +-
 70 files changed, 1111 insertions(+), 479 deletions(-)

Re: [GIT PULL] arm64 updates 6.15-rc1

[Linus Torvalds]

On Tue, Mar 25, 2025 at 12:53 PM Catalin Marinas
<catalin.marinas@arm.com> wrote:
>
> Please pull the arm64 updates for 6.15-rc1 below.

This was in my spam folder. The reason is that your email
configuration is wrong, and lacks the proper DKIM signature.

You have

    From: Catalin Marinas <catalin.marinas@arm.com>

but it doesn't actually have the DKIM signature from arm.com...

It looks like you sent it through the kernel.org smtp server using
git-send-email, but it doesn't have the kernel.org DKIM either (but it
may be that kernel.org only signs things that say "From:
xyzzy@kernel.org").

             Linus

Re: [GIT PULL] arm64 updates 6.15-rc1

[Catalin Marinas]

On Tue, Mar 25, 2025 at 01:12:45PM -0700, Linus Torvalds wrote:
> On Tue, Mar 25, 2025 at 12:53 PM Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > Please pull the arm64 updates for 6.15-rc1 below.
> 
> This was in my spam folder. The reason is that your email
> configuration is wrong, and lacks the proper DKIM signature.
> 
> You have
> 
>     From: Catalin Marinas <catalin.marinas@arm.com>
> 
> but it doesn't actually have the DKIM signature from arm.com...
> 
> It looks like you sent it through the kernel.org smtp server using
> git-send-email, but it doesn't have the kernel.org DKIM either (but it
> may be that kernel.org only signs things that say "From:
> xyzzy@kernel.org").

Hmm, I thought that setting "Return-Path: cmarinas@kernel.org" would be
enough. This header left my machine but seems to have disappeared in the
lore archive. Not sure how much difference it would have made, IIUC
that's more for SPF than DKIM.

If the envelope sender doesn't work, I may have to switch to using
cmarinas@kernel.org, at least for pull requests. Arm has an SMTP server
that doesn't add the legal disclaimer but I've had similar problems with
it in the past (the expected sender was ...@foss.arm.com; maybe IT fixed
it in the meantime).

Anyway, thanks for letting me know. I'll dig further.

-- 
Catalin

Re: [GIT PULL] arm64 updates 6.15-rc1

[Linus Torvalds]

On Tue, 25 Mar 2025 at 17:18, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> Hmm, I thought that setting "Return-Path: cmarinas@kernel.org" would be
> enough.

No, DKIM is designed to make forging emails hard, and that very much
means that it checks the "from" address, not some random header that
humans never look at.

> This header left my machine but seems to have disappeared in the
> lore archive. Not sure how much difference it would have made, IIUC
> that's more for SPF than DKIM.

I do see the

   Return-Path: <cmarinas@kernel.org>

but no, that shouldn't make any difference at all, because that's not
what dkim matches.

The spf is fine, but honestly, spf on its own is kind of useless.

> If the envelope sender doesn't work, I may have to switch to using
> cmarinas@kernel.org, at least for pull requests.

That's fine, and is probably the easiest thing to do.

            Linus

Re: [GIT PULL] arm64 updates 6.15-rc1

[Steven Rostedt]

On Tue, 25 Mar 2025 17:48:12 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > This header left my machine but seems to have disappeared in the
> > lore archive. Not sure how much difference it would have made, IIUC
> > that's more for SPF than DKIM.  
> 
> I do see the
> 
>    Return-Path: <cmarinas@kernel.org>
> 
> but no, that shouldn't make any difference at all, because that's not
> what dkim matches.

Now I wonder if you see any of my emails that I have been sending?

I have my own email server which is on a dynamic IP which most ISPs will
simply drop because of that, so I route my email through kernel.org.

I just sent myself a few test emails and there's no DKIM signature, unless
I manually edit the From to use my kernel.org email (which I have never
used before).

> 
> The spf is fine, but honestly, spf on its own is kind of useless.
> 
> > If the envelope sender doesn't work, I may have to switch to using
> > cmarinas@kernel.org, at least for pull requests.  
> 
> That's fine, and is probably the easiest thing to do.

I may have to do the same if you can see this email (which I manually
updated the From address to be kernel.org), but not my previous pull
requests.

I wonder if there's a way I can work with Konstantin to allow kernel.org to
have a signature for goodmis.org ? Not sure if that's even possible.

In case you missed my previous pull requests, they are here:

  https://lore.kernel.org/all/20250325180527.5fc0a1fa@gandalf.local.home/
  https://lore.kernel.org/all/20250325193935.66020aa3@gandalf.local.home/
  https://lore.kernel.org/all/20250326115109.32b69701@gandalf.local.home/

-- Steve

Re: [GIT PULL] arm64 updates 6.15-rc1

[Linus Torvalds]

On Wed, 26 Mar 2025 at 09:39, Steven Rostedt <rostedt@kernel.org> wrote:
>
> Now I wonder if you see any of my emails that I have been sending?

Your emails are fine. You're using a kernel.org address, and you're
going through smtp.kernel.org, so they have a perfectly proper DKIM
signature:

   Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF624C4CEE2;
Wed, 26 Mar 2025 16:39:38 +0000 (UTC)
   DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1743007179; [...]

> I have my own email server which is on a dynamic IP which most ISPs will
> simply drop because of that, so I route my email through kernel.org.
>
> I just sent myself a few test emails and there's no DKIM signature, unless
> I manually edit the From to use my kernel.org email (which I have never
> used before).

If you don't see a DKIM signature, it's probably because when you send
emails to yourself, they never actually go outside your own little
smtp setup, and never go through kernel.org at all.

               Linus

Re: [GIT PULL] arm64 updates 6.15-rc1

[Steven Rostedt]

On Wed, 26 Mar 2025 09:51:06 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> If you don't see a DKIM signature, it's probably because when you send
> emails to yourself, they never actually go outside your own little
> smtp setup, and never go through kernel.org at all.

Using claws-mail it just uses kernel.org directly, where as my sendmail
scripts use my own server which goes through kernel.org.

When sending to another email of mine (rostedt@kihontech.com) the headers are:

Return-Path: <SRS0=fOit=WN=goodmis.org=rostedt@kernel.org>
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on mailmammoth
X-Spam-Level: 
X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DMARC_MISSING,
 HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_VALIDITY_CERTIFIED,
 RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE,SPF_HELO_NONE,SPF_PASS
 autolearn=ham autolearn_force=no version=4.0.0
X-Original-To: rostedt@kihontech.com
Delivered-To: catchall@goodmis.org
Received: from rostedt.homelinux.com [172.100.189.27]
 by mailmammoth with IMAP (fetchmail-6.4.37)
 for <rostedt@localhost> (single-drop); Wed, 26 Mar 2025 12:13:10 -0400 (EDT)
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by mailmammoth.local.home (Postfix) with ESMTP id 8EE602014D
 for <rostedt@kihontech.com>; Wed, 26 Mar 2025 12:13:09 -0400 (EDT)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 60B5A439EF
 for <rostedt@kihontech.com>; Wed, 26 Mar 2025 16:13:08 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5492CC4CEE2
 for <rostedt@kihontech.com>; Wed, 26 Mar 2025 16:13:08 +0000 (UTC)

So it definitely goes through kernel.org.

But it has no DKIM headers.

-- Steve

Re: [GIT PULL] arm64 updates 6.15-rc1

[Linus Torvalds]

On Wed, 26 Mar 2025 at 10:11, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> So it definitely goes through kernel.org.
>
> But it has no DKIM headers.

Funky.

There's definitely something strange going on, because your *previous*
email to me did have the DKIM signature:

  Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF624C4CEE2...
  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;[..]
  [...]
  Date: Wed, 26 Mar 2025 12:40:25 -0400
  Subject: Re: [GIT PULL] arm64 updates 6.15-rc1
  Message-ID: <20250326124025.1966bf8a@gandalf.local.home>

and gmail was explicitly happy with it:

  ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [...]

but then this later one didn't:

  Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CDA5C4CEE2...
  [...]
  Date: Wed, 26 Mar 2025 13:12:00 -0400
  Message-ID: <20250326131200.1c86c657@gandalf.local.home>

and for some reason gmail also didn't actually react to the lack of
DKIM on that second one and only talks about how spf was fine.

Konstantin? Can you tell what's going on?

               Linus

Re: [GIT PULL] arm64 updates 6.15-rc1

[Steven Rostedt]

On Wed, 26 Mar 2025 10:25:22 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, 26 Mar 2025 at 10:11, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > So it definitely goes through kernel.org.
> >
> > But it has no DKIM headers.  
> 
> Funky.
> 
> There's definitely something strange going on, because your *previous*
> email to me did have the DKIM signature:

That's because I had manually changed my "From:" from "rostedt@goodmis.org"
to "rostedt@kernel.org", which in my test emails, added the DKIM signatures.

-- Steve

Re: [GIT PULL] arm64 updates 6.15-rc1

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]

Hi Linus,

On Wed, 26 Mar 2025 10:25:22 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Wed, 26 Mar 2025 at 10:11, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > So it definitely goes through kernel.org.
> >
> > But it has no DKIM headers.  
> 
> Funky.
> 
> There's definitely something strange going on, because your *previous*
> email to me did have the DKIM signature:
> 
>   Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF624C4CEE2...
>   DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;[..]
>   [...]
>   Date: Wed, 26 Mar 2025 12:40:25 -0400
>   Subject: Re: [GIT PULL] arm64 updates 6.15-rc1
>   Message-ID: <20250326124025.1966bf8a@gandalf.local.home>
> 
> and gmail was explicitly happy with it:
> 
>   ARC-Authentication-Results: i=1; mx.google.com;
>        dkim=pass [...]
> 
> but then this later one didn't:
> 
>   Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CDA5C4CEE2...
>   [...]
>   Date: Wed, 26 Mar 2025 13:12:00 -0400
>   Message-ID: <20250326131200.1c86c657@gandalf.local.home>
> 
> and for some reason gmail also didn't actually react to the lack of
> DKIM on that second one and only talks about how spf was fine.
> 
> Konstantin? Can you tell what's going on?

My understanding is this:

for normal SPF checks (i.e. not DMARC's SPF checks) the test is done on
the envelope sender and in Steve's case, goodmis.org DNS SPF record
says that anything from goodmis.org can come from the kernel.org
servers.  DMARC applies the SPF check to the From: header address.

for DKIM checks, the test is against the From: header address.  The
kernel.org servers can only sign emails that have a From header using a
kernel.org email address (or any other domain they have access to the
private DKIM keys for).  So they cannot sign emails that have a From:
header using a goodmis.org email address (presumably).

Presumably the SPF check passing is sufficient for the GMail servers.

DMARC requires that its SPF check or its DKIM check to pass.  (But
goodmis.org has no DMARC DNS record, while kernel.org does)
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] arm64 updates 6.15-rc1

[Steven Rostedt]

On Thu, 27 Mar 2025 09:45:02 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> My understanding is this:
> 
> for normal SPF checks (i.e. not DMARC's SPF checks) the test is done on
> the envelope sender and in Steve's case, goodmis.org DNS SPF record
> says that anything from goodmis.org can come from the kernel.org
> servers.  DMARC applies the SPF check to the From: header address.

Ah right. Thanks for looking into this. This brings back a memory where I added:

 "v=spf1 include:kernel.org"

to the DNS TXT record for goodmis.org.

-- Steve

Re: [GIT PULL] arm64 updates 6.15-rc1

[pr-tracker-bot]

The pull request you sent on Tue, 25 Mar 2025 19:53:22 +0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2d09a9449ecd9a2b9fdac62408c12ee20b6307d2

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html