* [PATCH] docs: fix typo in Sphinx custom CSS
From: omkarbhor4011 @ 2026-05-22 0:31 UTC (permalink / raw)
To: corbet; +Cc: skhan, linux-doc, linux-kernel, Omkarbhor4011
From: omkarbhor4011 <Omkarbhor4011@gmail.com>
Signed-off-by: omkarbhor4011 <Omkarbhor4011@gmail.com>
---
Documentation/sphinx-static/custom.css | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
index f91393426..5aa0a1ed9 100644
--- a/Documentation/sphinx-static/custom.css
+++ b/Documentation/sphinx-static/custom.css
@@ -30,7 +30,7 @@ img.logo {
margin-bottom: 20px;
}
-/* The default is to use -1em, wich makes it override text */
+/* The default is to use -1em, which makes it override text */
li { text-indent: 0em; }
/*
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v4 02/16] vfio/pci: Preserve vfio-pci device files across Live Update
From: David Matlack @ 2026-05-21 23:49 UTC (permalink / raw)
To: Vipin Sharma
Cc: kvm, linux-doc, linux-kernel, linux-kselftest, linux-pci,
ajayachandra, alex, amastro, ankita, apopple, chrisl, corbet,
graf, jacob.pan, jgg, jgg, jrhilke, julianr, kevin.tian, leon,
leonro, lukas, michal.winiarski, parav, pasha.tatashin, praan,
pratyush, rananta, rientjes, rodrigo.vivi, rppt, saeedm, skhan,
skhawaja, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260511234802.2280368-3-vipinsh@google.com>
On 2026-05-11 04:47 PM, Vipin Sharma wrote:
> +static int vfio_pci_liveupdate_freeze(struct liveupdate_file_op_args *args)
> +{
> + struct vfio_device *device = vfio_device_from_file(args->file);
> + struct vfio_pci_core_device *vdev;
> + struct pci_dev *pdev;
> + int ret;
> +
> + vdev = container_of(device, struct vfio_pci_core_device, vdev);
> + pdev = vdev->pdev;
> +
> + guard(mutex)(&device->dev_set->lock);
> +
> + /*
> + * Userspace must disable interrupts on the device prior to freeze so
> + * that the device does not send any interrupts until new interrupt
> + * handlers have been established by the next kernel.
> + */
> + if (vdev->irq_type != VFIO_PCI_NUM_IRQS) {
> + pci_err(pdev, "Freeze failed! Interrupts are still enabled.\n");
> + return -EINVAL;
> + }
> +
> + guard(rwsem_write)(&vdev->memory_lock);
> +
> + /*
> + * Userspace must make sure device is not in the lower power state for
> + * live update. We may relax this in future.
> + */
> + if (pdev->current_state != PCI_D0) {
> + pci_err(pdev, "Freeze failed! Device not in D0 state.\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Reset is a temporary measure to provide kernel after kexec a clean
> + * device while VFIO live update work is under development and not
> + * fully supported. It will go away once continuous DMA support is
> + * added to device preservation.
> + */
> + vfio_pci_zap_bars(vdev);
> + ret = pci_load_saved_state(pdev, vdev->pci_saved_state);
> + if (ret)
> + return ret;
> + pci_clear_master(pdev);
> + vfio_pci_core_try_reset(vdev);
I am seeing the following lockdep splat get triggered by this reset when
testing with this commit using vfio_pci_liveupdate_kexec_test. It seems to be
related to taking memory_lock above.
[ 2710.299017][T75672] ======================================================
[ 2710.305908][T75672] WARNING: possible circular locking dependency detected
[ 2710.312797][T75672] 7.1.0-dbg-DEV #59 Tainted: G S
[ 2710.319077][T75672] ------------------------------------------------------
[ 2710.325967][T75672] kexec/75672 is trying to acquire lock:
[ 2710.331474][T75672] ff46fd4fdbaeef08 (&group->mutex){+.+.}-{4:4}, at: pci_dev_reset_iommu_prepare+0x6e/0x1a0
[ 2710.341336][T75672]
[ 2710.341336][T75672] but task is already holding lock:
[ 2710.348574][T75672] ff46fd501f9a19a8 (&vdev->memory_lock){++++}-{4:4}, at: vfio_pci_liveupdate_freeze+0x51/0x100
[ 2710.358764][T75672]
[ 2710.358764][T75672] which lock already depends on the new lock.
[ 2710.358764][T75672]
[ 2710.369031][T75672]
[ 2710.369031][T75672] the existing dependency chain (in reverse order) is:
[ 2710.377916][T75672]
[ 2710.377916][T75672] -> #4 (&vdev->memory_lock){++++}-{4:4}:
[ 2710.385675][T75672] down_read+0x3d/0x150
[ 2710.390235][T75672] vfio_pci_mmap_huge_fault+0xb9/0x160
[ 2710.396091][T75672] __do_fault+0x46/0x140
[ 2710.400734][T75672] do_pte_missing+0x4c3/0xff0
[ 2710.405803][T75672] handle_mm_fault+0x7c4/0xb30
[ 2710.410961][T75672] fixup_user_fault+0x115/0x270
[ 2710.416209][T75672] vaddr_get_pfns+0x1a1/0x390
[ 2710.421286][T75672] vfio_pin_pages_remote+0x148/0x4d0
[ 2710.426959][T75672] vfio_pin_map_dma+0xcc/0x260
[ 2710.432116][T75672] vfio_iommu_type1_ioctl+0xda4/0xec0
[ 2710.437884][T75672] __se_sys_ioctl+0x71/0xc0
[ 2710.442790][T75672] do_syscall_64+0x15f/0x710
[ 2710.447788][T75672] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2710.454074][T75672]
[ 2710.454074][T75672] -> #3 (&mm->mmap_lock){++++}-{4:4}:
[ 2710.461489][T75672] down_read_killable+0x48/0x180
[ 2710.466821][T75672] mmap_read_lock_killable+0x12/0x50
[ 2710.472505][T75672] lock_mm_and_find_vma+0x11d/0x130
[ 2710.478093][T75672] do_user_addr_fault+0x3a0/0x6c0
[ 2710.483521][T75672] exc_page_fault+0x68/0xa0
[ 2710.488423][T75672] asm_exc_page_fault+0x26/0x30
[ 2710.493669][T75672] filldir+0xe2/0x190
[ 2710.498047][T75672] ext4_readdir+0xb47/0xcf0
[ 2710.502950][T75672] iterate_dir+0x84/0x160
[ 2710.507677][T75672] __se_sys_getdents+0x74/0x120
[ 2710.512929][T75672] do_syscall_64+0x15f/0x710
[ 2710.517919][T75672] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2710.524202][T75672]
[ 2710.524202][T75672] -> #2 (&type->i_mutex_dir_key#4){++++}-{4:4}:
[ 2710.532478][T75672] down_read+0x3d/0x150
[ 2710.537030][T75672] lookup_slow+0x26/0x50
[ 2710.541675][T75672] link_path_walk+0x42c/0x580
[ 2710.546743][T75672] path_openat+0xd1/0xde0
[ 2710.551466][T75672] do_file_open_root+0x114/0x250
[ 2710.556798][T75672] file_open_root+0x89/0xb0
[ 2710.561703][T75672] kernel_read_file_from_path_initns+0xba/0x130
[ 2710.568342][T75672] _request_firmware+0x4ab/0x8c0
[ 2710.573677][T75672] request_firmware_direct+0x36/0x50
[ 2710.579356][T75672] request_microcode_fw+0xf2/0x510
[ 2710.584869][T75672] reload_store+0x197/0x230
[ 2710.589766][T75672] kernfs_fop_write_iter+0x13f/0x1d0
[ 2710.595452][T75672] vfs_write+0x2be/0x3b0
[ 2710.600097][T75672] ksys_write+0x73/0x100
[ 2710.604735][T75672] do_syscall_64+0x15f/0x710
[ 2710.609723][T75672] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2710.616009][T75672]
[ 2710.616009][T75672] -> #1 (cpu_hotplug_lock){++++}-{0:0}:
[ 2710.623591][T75672] cpus_read_lock+0x3b/0xd0
[ 2710.628499][T75672] __cpuhp_state_add_instance+0x19/0x40
[ 2710.634443][T75672] iova_domain_init_rcaches+0x1ef/0x230
[ 2710.640385][T75672] iommu_setup_dma_ops+0x175/0x540
[ 2710.645891][T75672] iommu_device_register+0x188/0x220
[ 2710.651564][T75672] intel_iommu_init+0x35a/0x440
[ 2710.656811][T75672] pci_iommu_init+0x16/0x40
[ 2710.661713][T75672] do_one_initcall+0xf5/0x3a0
[ 2710.666786][T75672] do_initcall_level+0x82/0xa0
[ 2710.671953][T75672] do_initcalls+0x43/0x70
[ 2710.676672][T75672] kernel_init_freeable+0x152/0x1d0
[ 2710.682266][T75672] kernel_init+0x1a/0x130
[ 2710.686996][T75672] ret_from_fork+0x16b/0x310
[ 2710.691991][T75672] ret_from_fork_asm+0x1a/0x30
[ 2710.697151][T75672]
[ 2710.697151][T75672] -> #0 (&group->mutex){+.+.}-{4:4}:
[ 2710.704478][T75672] __lock_acquire+0x14c6/0x2800
[ 2710.709729][T75672] lock_acquire+0xd3/0x2c0
[ 2710.714542][T75672] __mutex_lock+0x8f/0xcd0
[ 2710.719349][T75672] pci_dev_reset_iommu_prepare+0x6e/0x1a0
[ 2710.725461][T75672] pcie_flr+0x32/0xc0
[ 2710.729842][T75672] __pci_reset_function_locked+0x84/0x120
[ 2710.735954][T75672] vfio_pci_core_try_reset+0x96/0xe0
[ 2710.741630][T75672] vfio_pci_liveupdate_freeze+0x89/0x100
[ 2710.747653][T75672] luo_file_freeze+0xba/0x280
[ 2710.752725][T75672] luo_session_serialize+0x69/0x190
[ 2710.758321][T75672] liveupdate_reboot+0x19/0x30
[ 2710.763490][T75672] kernel_kexec+0x2f/0xa0
[ 2710.768220][T75672] __se_sys_reboot+0xfd/0x210
[ 2710.773301][T75672] do_syscall_64+0x15f/0x710
[ 2710.778284][T75672] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2710.784568][T75672]
[ 2710.784568][T75672] other info that might help us debug this:
[ 2710.784568][T75672]
[ 2710.794663][T75672] Chain exists of:
[ 2710.794663][T75672] &group->mutex --> &mm->mmap_lock --> &vdev->memory_lock
[ 2710.794663][T75672]
[ 2710.807543][T75672] Possible unsafe locking scenario:
[ 2710.807543][T75672]
[ 2710.814863][T75672] CPU0 CPU1
[ 2710.820106][T75672] ---- ----
[ 2710.825352][T75672] lock(&vdev->memory_lock);
[ 2710.829904][T75672] lock(&mm->mmap_lock);
[ 2710.836620][T75672] lock(&vdev->memory_lock);
[ 2710.843682][T75672] lock(&group->mutex);
[ 2710.847798][T75672]
[ 2710.847798][T75672] *** DEADLOCK ***
[ 2710.847798][T75672]
[ 2710.855818][T75672] 7 locks held by kexec/75672:
[ 2710.860457][T75672] #0: ffffffff90a81330 (system_transition_mutex){+.+.}-{4:4}, at: __se_sys_reboot+0xe4/0x210
[ 2710.870554][T75672] #1: ffffffff90e1d0c0 (luo_session_global.outgoing.rwsem){+.+.}-{4:4}, at: luo_session_serialize+0x1f/0x190
[ 2710.882043][T75672] #2: ff46fd50602b7ae0 (&session->mutex){+.+.}-{4:4}, at: luo_session_serialize+0x4f/0x190
[ 2710.891972][T75672] #3: ff46fd500bec0788 (&luo_file->mutex){+.+.}-{4:4}, at: luo_file_freeze+0x65/0x280
[ 2710.901463][T75672] #4: ff46fd509d8106a8 (&new_dev_set->lock){+.+.}-{4:4}, at: vfio_pci_liveupdate_freeze+0x36/0x100
[ 2710.912086][T75672] #5: ff46fd501f9a19a8 (&vdev->memory_lock){++++}-{4:4}, at: vfio_pci_liveupdate_freeze+0x51/0x100
[ 2710.922701][T75672] #6: ff46fd4fd416c1f0 (&dev->mutex){....}-{4:4}, at: pci_dev_trylock+0x25/0x60
[ 2710.931676][T75672]
[ 2710.931676][T75672] stack backtrace:
[ 2710.937439][T75672] CPU: 193 UID: 0 PID: 75672 Comm: kexec Tainted: G S 7.1.0-dbg-DEV #59 PREEMPTLAZY
[ 2710.937442][T75672] Tainted: [S]=CPU_OUT_OF_SPEC
[ 2710.937442][T75672] Hardware name: Google Izumi-EMR/izumi, BIOS 0.20251023.0-0 10/23/2025
[ 2710.937443][T75672] Call Trace:
[ 2710.937446][T75672] <TASK>
[ 2710.937448][T75672] dump_stack_lvl+0x54/0x70
[ 2710.937453][T75672] print_circular_bug+0x2e1/0x300
[ 2710.937455][T75672] check_noncircular+0xf9/0x120
[ 2710.937456][T75672] ? __bfs+0x129/0x200
[ 2710.937458][T75672] __lock_acquire+0x14c6/0x2800
[ 2710.937460][T75672] ? __lock_acquire+0x1240/0x2800
[ 2710.937463][T75672] ? pci_dev_reset_iommu_prepare+0x6e/0x1a0
[ 2710.937465][T75672] lock_acquire+0xd3/0x2c0
[ 2710.937466][T75672] ? pci_dev_reset_iommu_prepare+0x6e/0x1a0
[ 2710.937468][T75672] ? lock_is_held_type+0x76/0x100
[ 2710.937471][T75672] ? pci_dev_reset_iommu_prepare+0x6e/0x1a0
[ 2710.937473][T75672] __mutex_lock+0x8f/0xcd0
[ 2710.937473][T75672] ? pci_dev_reset_iommu_prepare+0x6e/0x1a0
[ 2710.937475][T75672] ? lockdep_hardirqs_on_prepare+0x151/0x210
[ 2710.937477][T75672] ? _raw_spin_unlock_irqrestore+0x35/0x50
[ 2710.937482][T75672] pci_dev_reset_iommu_prepare+0x6e/0x1a0
[ 2710.937484][T75672] pcie_flr+0x32/0xc0
[ 2710.937485][T75672] __pci_reset_function_locked+0x84/0x120
[ 2710.937487][T75672] vfio_pci_core_try_reset+0x96/0xe0
[ 2710.937489][T75672] vfio_pci_liveupdate_freeze+0x89/0x100
[ 2710.937490][T75672] luo_file_freeze+0xba/0x280
[ 2710.937492][T75672] luo_session_serialize+0x69/0x190
[ 2710.937493][T75672] liveupdate_reboot+0x19/0x30
[ 2710.937495][T75672] kernel_kexec+0x2f/0xa0
[ 2710.937496][T75672] __se_sys_reboot+0xfd/0x210
[ 2710.937497][T75672] ? check_object+0x1ee/0x390
[ 2710.937500][T75672] ? lock_release+0xef/0x350
[ 2710.937501][T75672] ? kmem_cache_free+0x1b5/0x520
[ 2710.937506][T75672] ? _raw_spin_unlock_irqrestore+0x35/0x50
[ 2710.937508][T75672] ? kmem_cache_free+0x1b5/0x520
[ 2710.937509][T75672] ? __x64_sys_close+0x3d/0x80
[ 2710.937510][T75672] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2710.937511][T75672] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2710.937512][T75672] do_syscall_64+0x15f/0x710
[ 2710.937514][T75672] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2710.937515][T75672] RIP: 0033:0x7fa57e4f2513
[ 2710.937519][T75672] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 89 fa b8 a9 00 00 00 bf ad de e1 fe be 69 19 12 28 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 f7 d8 48 8b 0d db 2c 07 00 64 89 01 48
[ 2710.937520][T75672] RSP: 002b:00007ffd16943748 EFLAGS: 00000246 ORIG_RAX: 00000000000000a9
[ 2710.937523][T75672] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fa57e4f2513
[ 2710.937524][T75672] RDX: 0000000045584543 RSI: 0000000028121969 RDI: 00000000fee1dead
[ 2710.937526][T75672] RBP: 00007ffd16943a60 R08: 0000000000000009 R09: 00007fa57e5672e0
[ 2710.937527][T75672] R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffd169438e0
[ 2710.937528][T75672] R13: 0000000000000000 R14: 00007ffd169438e0 R15: 0000000000000001
[ 2710.937532][T75672] </TASK>
> + pci_restore_state(pdev);
> + return 0;
> }
^ permalink raw reply
* Re: [PATCH] tpm: tpm_tis: Add optional delay after relinquish
From: Jarkko Sakkinen @ 2026-05-21 23:48 UTC (permalink / raw)
To: Jim Broadus; +Cc: linux-integrity, linux-kernel, linux-doc, peterhuewe, jgg
In-Reply-To: <20260519060926.103727-1-jbroadus@gmail.com>
On Mon, May 18, 2026 at 11:09:26PM -0700, Jim Broadus wrote:
> Some TPMs fail to grant locality when requested immediately after being
> relinquished. In this case, the TPM_ACCESS_REQUEST_USE bit of the
> TPM_ACCESS register is cleared immediately without setting
> TPM_ACCESS_ACTIVE_LOCALITY.
>
> This issue can be seen at boot since tpm_chip_start, called right
> after locality is relinquished, fails. This causes the probe to fail:
>
> tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -1
>
> This occurs on some older Dell Latitudes and maybe others. To work
> around this, add a "settle" boolean param to tpm_tis. When this is
> enabled, a delay is added after locality is relinquished.
>
> Signed-off-by: Jim Broadus <jbroadus@gmail.com>
It would be better idea first to replace priv->manufacturer_id with
priv->did_vid, and make necessary changes to sites where it is used.
Then in the if-statement compare DID/VID of the device to priv->did_vid
and apply quirk only if it matches.
> ---
> Documentation/admin-guide/kernel-parameters.txt | 7 +++++++
> drivers/char/tpm/tpm_tis.c | 7 +++++++
> drivers/char/tpm/tpm_tis_core.c | 3 +++
> drivers/char/tpm/tpm_tis_core.h | 1 +
> 4 files changed, 18 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 4d0f545fb3ec..5b7111033fbb 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -7651,6 +7651,13 @@ Kernel parameters
> defined by Trusted Computing Group (TCG) see
> https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
>
> + tpm_tis.settle= [HW,TPM]
> + Format: <bool>
> + When enabled, this adds a delay after locality is
> + relinquished. Some TPMs will fail to grant locality if
> + requested immediately after being relinquished. This
> + causes the probe to fail.
> +
> tp_printk [FTRACE]
> Have the tracepoints sent to printk as well as the
> tracing ring buffer. This is useful for early boot up
> diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
> index 9aa230a63616..8ac0ea78570e 100644
> --- a/drivers/char/tpm/tpm_tis.c
> +++ b/drivers/char/tpm/tpm_tis.c
> @@ -101,6 +101,10 @@ module_param(force, bool, 0444);
> MODULE_PARM_DESC(force, "Force device probe rather than using ACPI entry");
> #endif
>
> +static bool settle;
> +module_param(settle, bool, 0444);
> +MODULE_PARM_DESC(settle, "Add settle time after relinquish");
> +
> #if defined(CONFIG_PNP) && defined(CONFIG_ACPI)
> static int has_hid(struct acpi_device *dev, const char *hid)
> {
> @@ -242,6 +246,9 @@ static int tpm_tis_init(struct device *dev, struct tpm_info *tpm_info)
> if (itpm || is_itpm(ACPI_COMPANION(dev)))
> set_bit(TPM_TIS_ITPM_WORKAROUND, &phy->priv.flags);
>
> + if (settle)
> + set_bit(TPM_TIS_SETTLE_AFTER_RELINQUISH, &phy->priv.flags);
> +
> return tpm_tis_core_init(dev, &phy->priv, irq, &tpm_tcg,
> ACPI_HANDLE(dev));
> }
> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
> index 21d79ad3b164..68be26fa5817 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -184,6 +184,9 @@ static int tpm_tis_relinquish_locality(struct tpm_chip *chip, int l)
> __tpm_tis_relinquish_locality(priv, l);
> mutex_unlock(&priv->locality_count_mutex);
>
> + if (test_bit(TPM_TIS_SETTLE_AFTER_RELINQUISH, &priv->flags))
> + tpm_msleep(TPM_TIMEOUT);
> +
> return 0;
> }
>
> diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
> index 6c3aa480396b..413cac5e0f31 100644
> --- a/drivers/char/tpm/tpm_tis_core.h
> +++ b/drivers/char/tpm/tpm_tis_core.h
> @@ -90,6 +90,7 @@ enum tpm_tis_flags {
> TPM_TIS_DEFAULT_CANCELLATION = 2,
> TPM_TIS_IRQ_TESTED = 3,
> TPM_TIS_STATUS_VALID_RETRY = 4,
> + TPM_TIS_SETTLE_AFTER_RELINQUISH = 5,
> };
>
> struct tpm_tis_data {
> --
> 2.54.0
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v3 0/3] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
From: Andrew Morton @ 2026-05-21 23:33 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: Liam.Howlett, david, jgg, corbet, leon, ljs, mhocko, rppt, shuah,
skhan, surenb, vbabka, linux-doc, linux-kernel, linux-kselftest,
linux-mm
In-Reply-To: <177928604779.589431.14703161356676674288.stgit@skinsburskii>
On Wed, 20 May 2026 07:09:19 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> This series extends the HMM framework to support userfaultfd-backed memory
> by allowing the mmap read lock to be dropped during hmm_range_fault().
>
> Some page fault handlers — most notably userfaultfd — require the mmap lock
> to be released so that userspace can resolve the fault. The current HMM
> interface never sets FAULT_FLAG_ALLOW_RETRY, making it impossible to fault
> in pages from userfaultfd-registered regions.
>
> This series follows the established int *locked pattern from
> get_user_pages_remote() in mm/gup.c. A new entry point,
> hmm_range_fault_unlockable(), accepts an int *locked parameter. When the
> mmap lock is dropped during fault resolution (VM_FAULT_RETRY or
> VM_FAULT_COMPLETED), the function returns 0 with *locked = 0, signalling
> the caller to restart its walk. The existing hmm_range_fault() is
> refactored into a thin wrapper that passes NULL, preserving current
> behavior for all existing callers.
>
> Faulting hugetlb pages on the unlockable path is not supported because
> walk_hugetlb_range() unconditionally holds and releases
> hugetlb_vma_lock_read across the callback; if the mmap lock is dropped
> inside the callback, the VMA may be freed before the walk framework's
> unlock. Hugetlb pages already present in page tables are handled normally.
> Possible approaches to lift this limitation are documented in
> Documentation/mm/hmm.rst.
Thanks. AI review identified one possible issue, possibly a duplicate
from the v2 series?
https://sashiko.dev/#/patchset/177928604779.589431.14703161356676674288.stgit@skinsburskii
I'll take no action at this stage, shall await reviewer input. Please
poke me in a week or so if nothing has happened.
Which is quite possible - things seem rather hectic at this time and
we're almost at -rc5!
^ permalink raw reply
* Re: [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Bagas Sanjaya @ 2026-05-21 23:26 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Stefan Dösinger, Linus Walleij, Krzysztof Kozlowski,
linux-arm-kernel, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260521191458.177046-1-rdunlap@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
On Thu, May 21, 2026 at 12:14:57PM -0700, Randy Dunlap wrote:
> Fix multiple documentation build warnings.
> Improve punctuation and formatting of the rendered output.
Much better, thanks!
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 27/30] KVM: x86: Add KVM_VCPU_TSC_EFFECTIVE_FREQ attribute
From: David Woodhouse @ 2026-05-21 22:40 UTC (permalink / raw)
To: Sean Christopherson
Cc: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Paul Durrant,
Jonathan Cameron, Sascha Bischoff, Marc Zyngier, Joey Gouly,
Jack Allister, Dongli Zhang, joe.jin, kvm, linux-doc,
linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <ag-Hf2liLSX9q0rS@google.com>
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]
On Thu, 2026-05-21 at 15:30 -0700, Sean Christopherson wrote:
> On Thu, May 21, 2026, David Woodhouse wrote:
> > On Sat, 2026-05-09 at 23:46 +0100, David Woodhouse wrote:
> > > From: David Woodhouse <dwmw@amazon.co.uk>
> > That does leave userspace still needing a way to get the APIC bus
> > frequency, to populate CPUID. So maybe I'll just make an attribute
> > which returns that as a single value.
>
> Already exists, KVM_CAP_X86_APIC_BUS_CYCLES_NS. The TDX architecture decided
> that unconditionally telling guests the virtual APIC bus runs at 400Mhz was a
> brilliant idea.
Ah, thanks.
So KVM always exposes 1GHz by default regardless of the actual host?
Which is why there's no *get* method?
(Well... getting KVM_CAP_APIC_BUS_CYCLES_NS returns
APIC_BUS_CYCLE_NS_DEFAULT which is 1, so it's basically just returning
1 like a lot of cap queries do, and *not* returning what the period is
actually set to)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v4 27/30] KVM: x86: Add KVM_VCPU_TSC_EFFECTIVE_FREQ attribute
From: Sean Christopherson @ 2026-05-21 22:30 UTC (permalink / raw)
To: David Woodhouse
Cc: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Paul Durrant,
Jonathan Cameron, Sascha Bischoff, Marc Zyngier, Joey Gouly,
Jack Allister, Dongli Zhang, joe.jin, kvm, linux-doc,
linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <3ad6cd109480772ade3c11f23b9c1d7a9855d67e.camel@infradead.org>
On Thu, May 21, 2026, David Woodhouse wrote:
> On Sat, 2026-05-09 at 23:46 +0100, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> That does leave userspace still needing a way to get the APIC bus
> frequency, to populate CPUID. So maybe I'll just make an attribute
> which returns that as a single value.
Already exists, KVM_CAP_X86_APIC_BUS_CYCLES_NS. The TDX architecture decided
that unconditionally telling guests the virtual APIC bus runs at 400Mhz was a
brilliant idea.
^ permalink raw reply
* Re: [PATCH v4 27/30] KVM: x86: Add KVM_VCPU_TSC_EFFECTIVE_FREQ attribute
From: David Woodhouse @ 2026-05-21 21:52 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
Paul Durrant, Jonathan Cameron, Sascha Bischoff, Marc Zyngier,
Joey Gouly, Jack Allister, Dongli Zhang, joe.jin, kvm, linux-doc,
linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260509224824.3264567-28-dwmw2@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
On Sat, 2026-05-09 at 23:46 +0100, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> Add a read-only per-vCPU attribute that reports the effective TSC and
> APIC bus frequencies as seen by the guest, after hardware TSC scaling
> is applied.
>
> This allows userspace to populate CPUID leaf 0x40000010 (the "generic"
> timing information leaf used by FreeBSD, XNU, and VMware) with correct
> values, without KVM needing to modify guest CPUID at runtime.
>
> The effective TSC frequency differs from what userspace requested via
> KVM_SET_TSC_KHZ due to the granularity of hardware scaling and the
> host kernel's measurement of its own TSC frequency.
As I do another pass on this series, I don't think I can stand by that
claim.
Even on AMD where we only have a 32-bit shift for TSC scaling, that's
still 0.23 PPM, or about half a Hz precision when scaling a 2400MHz
TSC.
And this API was returning kHz anyway! So it was as likely to be
*introducing* inaccuracy by returning 2299999kHz when userspace had
actually asked for 2300000 and the real rate ended up being
2399999.9995.
I think I'll drop it; and userspace should just use KVM_GET_TSC_KHZ.
That does leave userspace still needing a way to get the APIC bus
frequency, to populate CPUID. So maybe I'll just make an attribute
which returns that as a single value.
Or *maybe* KVM should just populate leaf 0x40000010 in its default
template? I thought we decided not to do that though, as unsuspecting
userspace might pass it through uncorrected from the default values? We
could put *zero* in the TSC part, but that just seems like it's another
potential weirdness for the guest to see.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v6 21/43] KVM: SEV: Make 'uaddr' parameter optional for KVM_SEV_SNP_LAUNCH_UPDATE
From: Ackerley Tng @ 2026-05-21 21:27 UTC (permalink / raw)
To: Sean Christopherson, Fuad Tabba
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Baoquan He, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka, kvm,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <ag8G7Wq5PbEdKloG@google.com>
Sean Christopherson <seanjc@google.com> writes:
> On Thu, May 21, 2026, Fuad Tabba wrote:
>> Hi,
>>
>> On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
>> <devnull+ackerleytng.google.com@kernel.org> wrote:
>> >
>> > From: Michael Roth <michael.roth@amd.com>
>> >
>> > For vm_memory_attributes=1, in-place conversion/population is not
>> > supported, so the initial contents necessarily must need to come
>> > from a separate src address, which is enforced by the current
>> > implementation. However, for vm_memory_attributes=0, it is possible for
>> > guest memory to be initialized directly from userspace by mmap()'ing the
>> > guest_memfd and writing to it while the corresponding GPA ranges are in
>> > a 'shared' state before converting them to the 'private' state expected
>> > by KVM_SEV_SNP_LAUNCH_UPDATE.
>> >
>> > Update the handling/documentation for KVM_SEV_SNP_LAUNCH_UPDATE to allow
>> > for 'uaddr' to be set to NULL when vm_memory_attributes=0, which
>> > SNP_LAUNCH_UPDATE will then use to determine when it should/shouldn't
>> > copy in data from a separate memory location. Continue to enforce
>> > non-NULL for the original vm_memory_attributes=1 case.
>> >
>> > Signed-off-by: Michael Roth <michael.roth@amd.com>
>> > [Added src_page check in error handling path when the firmware command fails]
>> > [Dropped ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES]
>> > Signed-off-by: Ackerley Tng <ackerleytng@google.com>
>>
>> I'm not very familiar with the SEV-SNP populate flows, but it looks
>> like Sashiko is on to something:
>> https://sashiko.dev/#/patchset/20260507-gmem-inplace-conversion-v6-0-91ab5a8b19a4%40google.com?part=21
>>
>> - a potential read-only page overwrite, because src_page is acquired
>> via get_user_pages_fast() without the FOLL_WRITE flag, but is then
>> overwritten via memcpy
>
> Oof, yeah, that's bad. Adding FOLL_WRITE to kvm_gmem_populate() feels wrong, and
> could break uABI, but doing gup() in SNP code would reintroduce the AB-BA issue
> with filemap_invalidate_lock().
>
> Aha! Not if we use get_user_page_fast_only(). Ugh, but then we'd have to plumb
> the userspace address into the post-populated callback.
>
> Hrm. Given that no one has yelled about overwriting their CPUID page, and given
> that the CPUID page is likely dynamically created and thus is unlikely to be a
> read-only mapping (e.g. versus the initial image), maybe this?
>
Overwriting the CPUID page is by design, I think. IIUC if the SNP
firmware doesn't like something about the CPUID page, it can update
src_page and then return an error to userspace.
Userspace should then check if it agrees with the updated CPUID contents
and then retry if it agrees.
> diff --git arch/x86/kvm/svm/sev.c arch/x86/kvm/svm/sev.c
> index 37d4cfa5d980..c73c028d72c1 100644
> --- arch/x86/kvm/svm/sev.c
> +++ arch/x86/kvm/svm/sev.c
> @@ -2456,6 +2456,7 @@ static int snp_launch_update(struct kvm *kvm, struct kvm_sev_cmd *argp)
> sev_populate_args.type = params.type;
>
> count = kvm_gmem_populate(kvm, params.gfn_start, src, npages,
> + params.type == KVM_SEV_SNP_PAGE_TYPE_CPUID,
I think this makes sense given that writing to src_page can only happen
when params.type == KVM_SEV_SNP_PAGE_TYPE_CPUID (this is explicitly one
of the guards in sev_gmem_post_populate()):
/*
* If the firmware command failed handle the reclaim and cleanup of that
* PFN before reporting an error.
*
* Additionally, when invalid CPUID function entries are detected,
* firmware writes the expected values into the page and leaves it
* unencrypted so it can be used for debugging and error-reporting.
*
* Copy this page back into the source buffer so userspace can use this
* information to provide information on which CPUID leaves/fields
* failed CPUID validation.
*/
if (ret && !snp_page_reclaim(kvm, pfn) &&
sev_populate_args->type == KVM_SEV_SNP_PAGE_TYPE_CPUID &&
sev_populate_args->fw_error == SEV_RET_INVALID_PARAM && src_page) {
void *src_vaddr = kmap_local_page(src_page);
void *dst_vaddr = kmap_local_pfn(pfn);
memcpy(src_vaddr, dst_vaddr, PAGE_SIZE);
kunmap_local(src_vaddr);
kunmap_local(dst_vaddr);
}
> sev_gmem_post_populate, &sev_populate_args);
> if (count < 0) {
> argp->error = sev_populate_args.fw_error;
> diff --git arch/x86/kvm/vmx/tdx.c arch/x86/kvm/vmx/tdx.c
> index f97bcf580e6d..33f35be4455b 100644
> --- arch/x86/kvm/vmx/tdx.c
> +++ arch/x86/kvm/vmx/tdx.c
> @@ -3188,7 +3188,7 @@ static int tdx_vcpu_init_mem_region(struct kvm_vcpu *vcpu, struct kvm_tdx_cmd *c
> };
> gmem_ret = kvm_gmem_populate(kvm, gpa_to_gfn(region.gpa),
> u64_to_user_ptr(region.source_addr),
> - 1, tdx_gmem_post_populate, &arg);
> + 1, false, tdx_gmem_post_populate, &arg);
And TDX doesn't try to write src_page, so this is good too.
> if (gmem_ret < 0) {
> ret = gmem_ret;
> break;
> diff --git include/linux/kvm_host.h include/linux/kvm_host.h
> index 61a3430957f2..b83cda2870ba 100644
> --- include/linux/kvm_host.h
> +++ include/linux/kvm_host.h
> @@ -2596,7 +2596,8 @@ int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, int max_ord
> typedef int (*kvm_gmem_populate_cb)(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn,
> struct page *page, void *opaque);
>
> -long kvm_gmem_populate(struct kvm *kvm, gfn_t gfn, void __user *src, long npages,
> +long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src,
> + long npages, bool writable,
What do you think of need_writable_src instead of just writable for the
variable name?
> kvm_gmem_populate_cb post_populate, void *opaque);
> #endif
>
> diff --git virt/kvm/guest_memfd.c virt/kvm/guest_memfd.c
> index a35a55571a2d..6553d4e032ce 100644
> --- virt/kvm/guest_memfd.c
> +++ virt/kvm/guest_memfd.c
> @@ -858,7 +858,8 @@ static long __kvm_gmem_populate(struct kvm *kvm, struct kvm_memory_slot *slot,
> return ret;
> }
>
> -long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long npages,
> +long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src,
> + long npages, bool writable,
> kvm_gmem_populate_cb post_populate, void *opaque)
> {
> struct kvm_memory_slot *slot;
> @@ -892,8 +893,9 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
>
> if (src) {
> unsigned long uaddr = (unsigned long)src + i * PAGE_SIZE;
> + unsigned int flags = writable ? FOLL_WRITE : 0;
How about using FOLL_WRITE | FOLL_NOFAULT so if it weren't writable to
start with, don't CoW, just error out?
Like you said above the CPUID page provided as src_page would have been
written to before, so it should have been mapped as writable.
>
> - ret = get_user_pages_fast(uaddr, 1, 0, &src_page);
> + ret = get_user_pages_fast(uaddr, 1, flags, &src_page);
If we stick with FOLL_WRITE, this also solves the case where a read-only
mapping or global zero page are provided as src_page, since
get_user_pages_fast() will do a copy-on-write if those were the inputs,
making it writable before the write happens (on failure) in
sev_gmem_post_populate().
> if (ret < 0)
> break;
> if (ret != 1) {
>
>> - an ordering violation with the kunmap_local() calls
>
> Yeesh, that's a new one for me. Thankfully this is 64-bit only, so it's not an
> issue.
>
>> These predate this patch series and are just being touched by the
>> 'src_page' addition, but if Sashiko's right, these should probably be
>> fixed sooner rather than later.
>
> Yeah, ditto with the offset wrapping case.
^ permalink raw reply
* Re: [PATCH v3 0/4] selftests/mm: separate GUP microbenchmarking from functional testing
From: Andrew Morton @ 2026-05-21 21:12 UTC (permalink / raw)
To: Sarthak Sharma
Cc: David Hildenbrand, Jonathan Corbet, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Shuah Khan,
Jason Gunthorpe, John Hubbard, Peter Xu, Leon Romanovsky, Zi Yan,
Baolin Wang, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Mark Brown, linux-kernel, linux-mm, linux-kselftest,
linux-doc
In-Reply-To: <20260521111801.173019-1-sarthak.sharma@arm.com>
On Thu, 21 May 2026 16:47:57 +0530 Sarthak Sharma <sarthak.sharma@arm.com> wrote:
> gup_test.c currently serves two distinct purposes: microbenchmarking
> (GUP_FAST_BENCHMARK, PIN_FAST_BENCHMARK, PIN_LONGTERM_BENCHMARK) and
> functional correctness testing (GUP_BASIC_TEST, PIN_BASIC_TEST,
> DUMP_USER_PAGES_TEST). Mixing these in a single binary means functional
> tests cannot be run or reported individually and run_vmtests.sh must
> invoke the binary multiple times with different flag combinations to
> cover all configurations.
>
> This patch series separates the two concerns: tools/mm/gup_bench for
> benchmarking and tools/testing/selftests/mm/gup_test for functional
> testing. To avoid duplicating HugeTLB and related file helpers, the
> series first moves the common helper code to tools/lib/mm/ so it can be
> shared by both selftests and tools/mm.
>
> ...
>
Thanks.
> These patches apply on top of mm/mm-new.
>
> Changes in v3:
> - Address v2 feedback from Sashiko
Sashiko has thoughts on v3:
https://sashiko.dev/#/patchset/20260521111801.173019-1-sarthak.sharma@arm.com
Probably that's incorrect/ignored material which also appeared against
the v2 series. But sometimes it finds new things so please scan the
output.
I'll hold off on this series for now, shall see what reviewers have to
say.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/mlx5: Apply devlink default eswitch mode during init
From: Mark Bloch @ 2026-05-21 21:02 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Tariq Toukan, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, David S. Miller, Thomas Gleixner, Arnd Bergmann,
Jonathan Corbet, Shuah Khan, Jiri Pirko, Simon Horman,
Saeed Mahameed, Leon Romanovsky, Borislav Petkov (AMD),
Andrew Morton, Randy Dunlap, Petr Mladek, Peter Zijlstra (Intel),
Tejun Heo, Vlastimil Babka, Feng Tang, Christian Brauner,
Dave Hansen, Dapeng Mi, Kees Cook, Marco Elver, Li RongQing,
Eric Biggers, Paul E. McKenney, linux-doc, linux-kernel, netdev,
linux-rdma, Gal Pressman, Dragos Tatulea, Jiri Pirko, Shay Drori,
Moshe Shemesh
In-Reply-To: <20260521152845-11899163-df79-435c-b8c9-d3003403c6c9@linutronix.de>
On 21/05/2026 16:41, Thomas Weißschuh wrote:
> On Thu, May 21, 2026 at 04:16:28PM +0300, Mark Bloch wrote:
> (...)
>
>> NIPA flagged this patch with a build_allmodconfig_warn failure:
>> https://netdev-ctrl.bots.linux.dev/logs/build/1098506/14585935/build_allmodconfig_warn/
>>
>> I do not see how this mlx5 patch is related to the reported issue,
>> but I looked into it anyway.
>>
>> After the kernel has been built once, the issue can be reproduced by rerunning sparse
>> only on version.o, which filters out the unrelated noise. I had an older sparse installed,
>> so I used a local copy:
>>
>> rm -f arch/x86/boot/version.o
>> make V=1 C=1 CHECK=/labhome/mbloch/bin/sparse arch/x86/boot/version.o
>>
>> This gives the same error reported by NIPA:
>>
>> ...
>> ...
>> make -f ./scripts/Makefile.vmlinux
>> make -f ./scripts/Makefile.build obj=arch/x86/boot arch/x86/boot/bzImage
>> make -f ./scripts/Makefile.build obj=arch/x86/boot/compressed arch/x86/boot/compressed/vmlinux
>> # CC arch/x86/boot/version.o
>> gcc -Wp,-MMD,arch/x86/boot/.version.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -std=gnu11 -fms-extensions -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -fno-pic -mno-mmx -mno-sse -fcf-protection=none -ffreestanding -fno-stack-protector -Wno-address-of-packed-member -mpreferred-stack-boundary=2 -D_SETUP -fno-asynchronous-unwind-tables -Wimplicit-fallthrough=5 -DKBUILD_MODFILE='"arch/x86/boot/version"' -DKBUILD_BASENAME='"version"' -DKBUILD_MODNAME='"version"' -D__KBUILD_MODNAME=version -c -o arch/x86/boot/version.o arch/x86/boot/version.c
>> # CHECK arch/x86/boot/version.c
>> /labhome/mbloch/bin/sparse -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ -Wbitwise -Wno-return-void -Wno-unknown-attribute -D__x86_64__ --arch=x86 -mlittle-endian -m64 -Wp,-MMD,arch/x86/boot/.version.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -std=gnu11 -fms-extensions -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -fno-pic -mno-mmx -mno-sse -fcf-protection=none -ffreestanding -fno-stack-protector -Wno-address-of-packed-member -mpreferred-stack-boundary=2 -D_SETUP -fno-asynchronous-unwind-tables -Wimplicit-fallthrough=5 -DKBUILD_MODFILE='"arch/x86/boot/version"' -DKBUILD_BASENAME='"version"' -DKBUILD_MODNAME='"version"' -D__KBUILD_MODNAME=version arch/x86/boot/version.c
>> arch/x86/boot/version.c: note: in included file (through arch/x86/include/uapi/asm/bitsperlong.h, include/uapi/asm-generic/int-ll64.h, include/asm-generic/int-ll64.h, include/uapi/asm-generic/types.h, ...):
>> ./include/asm-generic/bitsperlong.h:23:2: error: Inconsistent word size. Check asm/bitsperlong.h
>> ./include/asm-generic/bitsperlong.h:27:33: error: static assertion failed: "Inconsistent word size. Check asm/bitsperlong.h"
>> # cmd_gen_symversions_c arch/x86/boot/version.o
>> if nm arch/x86/boot/version.o 2>/dev/null | grep -q ' __export_symbol_'; then gcc -E -D__GENKSYMS__ -Wp,-MMD,arch/x86/boot/.version.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -std=gnu11 -fms-extensions -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -fno-pic -mno-mmx -mno-sse -fcf-protection=none -ffreestanding -fno-stack-protector -Wno-address-of-packed-member -mpreferred-stack-boundary=2 -D_SETUP -fno-asynchronous-unwind-tables -Wimplicit-fallthrough=5 -DKBUILD_MODFILE='"arch/x86/boot/version"' -DKBUILD_BASENAME='"version"' -DKBUILD_MODNAME='"version"' -D__KBUILD_MODNAME=version arch/x86/boot/version.c | ./scripts/genksyms/genksyms >> arch/x86/boot/.version.o.cmd; fi
>> # LD arch/x86/boot/setup.elf
>> ld -m elf_x86_64 -z noexecstack -m elf_i386 -z noexecstack -T arch/x86/boot/setup.ld arch/x86/boot/a20.o arch/x86/boot/bioscall.o arch/x86/boot/cmdline.o arch/x86/boot/copy.o arch/x86/boot/cpu.o arch/x86/boot/cpuflags.o arch/x86/boot/cpucheck.o arch/x86/boot/early_serial_console.o arch/x86/boot/edd.o arch/x86/boot/header.o arch/x86/boot/main.o arch/x86/boot/memory.o arch/x86/boot/pm.o arch/x86/boot/pmjump.o arch/x86/boot/printf.o arch/x86/boot/regs.o arch/x86/boot/string.o arch/x86/boot/tty.o arch/x86/boot/video.o arch/x86/boot/video-mode.o arch/x86/boot/version.o arch/x86/boot/video-vga.o arch/x86/boot/video-vesa.o arch/x86/boot/video-bios.o -o arch/x86/boot/setup.elf
>> # OBJCOPY arch/x86/boot/setup.bin
>> objcopy -O binary arch/x86/boot/setup.elf arch/x86/boot/setup.bin
>> # BUILD arch/x86/boot/bzImage
>> (dd if=arch/x86/boot/setup.bin bs=4k conv=sync status=none; cat arch/x86/boot/vmlinux.bin) >arch/x86/boot/bzImage
>> mkdir -p ./arch/x86_64/boot
>> ln -fsn ../../x86/boot/bzImage ./arch/x86_64/boot/bzImage
>>
>> To me this looks like sparse is getting a conflicting set of flags.
>> The command line contains both "-D__x86_64__ -m64" and "-m16 -march=i386 -D_SETUP".
>>
>> I confirmed that the following patch "fixes" the issue, but I do not know whether
>> this is the right fix. This area is outside my comfort zone, so it would be
>> helpful if someone more familiar with the x86 build/sparse flow could take a
>> look:
>>
>> diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
>> index 3f9fb3698d66..80923864f6f9 100644
>> --- a/arch/x86/boot/Makefile
>> +++ b/arch/x86/boot/Makefile
>> @@ -71,6 +71,10 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
>>
>> SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
>>
>> +realmode-checkflags-$(CONFIG_X86_64) := -m32 -U__x86_64__ -D__i386__
>> +REALMODE_CHECKFLAGS := $(filter-out -m64 -D__x86_64__,$(CHECKFLAGS)) $(realmode-checkflags-y)
>> +$(SETUP_OBJS): CHECKFLAGS := $(REALMODE_CHECKFLAGS)
>> +
>> sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [a-zA-Z] \(startup_32\|efi.._stub_entry\|efi\(32\)\?_pe_entry\|input_data\|kernel_info\|_end\|_ehead\|_text\|_e\?data\|_e\?sbat\|z_.*\)$$/\#define ZO_\2 0x\1/p'
>>
>> quiet_cmd_zoffset = ZOFFSET $@
>> diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
>> index a0fb39abc5c8..341b0ff20c3d 100644
>> --- a/arch/x86/realmode/rm/Makefile
>> +++ b/arch/x86/realmode/rm/Makefile
>> @@ -29,6 +29,10 @@ targets += $(realmode-y)
>>
>> REALMODE_OBJS = $(addprefix $(obj)/,$(realmode-y))
>>
>> +realmode-checkflags-$(CONFIG_X86_64) := -m32 -U__x86_64__ -D__i386__
>> +REALMODE_CHECKFLAGS := $(filter-out -m64 -D__x86_64__,$(CHECKFLAGS)) $(realmode-checkflags-y)
>> +$(REALMODE_OBJS): CHECKFLAGS := $(REALMODE_CHECKFLAGS)
>> +
>
> The idea looks good, we do something similar for the 32-bit vDSO:
>
> arch/x86/entry/vdso/vdso32/Makefile
>
> CHECKFLAGS := $(subst -m64,-m32,$(CHECKFLAGS))
> CHECKFLAGS := $(subst -D__x86_64__,-D__i386__,$(CHECKFLAGS))
>
> It seems the same kind of substitution would work here.
> We can add a helper function to arch/x86/Makefile and
> use that also for the compat vDSO.
>
> I am wondering why this didn't show up before.
> Are you going to send a patch or should I?
>
Yes, please take it if you don't mind.
Mark
>
> Thomas
^ permalink raw reply
* Re: [PATCH net-next 3/5] net: phy: Add support for the ADIN1140 PHY
From: Andrew Lunn @ 2026-05-21 20:44 UTC (permalink / raw)
To: Regus, Ciprian
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <1d7f5247b07f44f2a30cfed8f7d3cd6d@analog.com>
On Thu, May 21, 2026 at 08:24:41PM +0000, Regus, Ciprian wrote:
>
> > > +static int adin1140_phy_read_mmd(struct phy_device *phydev, int
> > devnum,
> > > + u16 regnum)
> > > +{
> > > + struct mii_bus *bus = phydev->mdio.bus;
> > > + int addr = phydev->mdio.addr;
> > > +
> > > + return __mdiobus_c45_read(bus, addr, devnum, regnum);
> > > +}
> > > +
> > > +static int adin1140_phy_write_mmd(struct phy_device *phydev, int
> > devnum,
> > > + u16 regnum, u16 val)
> > > +{
> > > + struct mii_bus *bus = phydev->mdio.bus;
> > > + int addr = phydev->mdio.addr;
> > > +
> > > + return __mdiobus_c45_write(bus, addr, devnum, regnum, val);
> > > +}
> >
> > Why do these exist?
> >
>
> The PHY is always probed over C22. Unless read_mmd()/write_mmd() are defined,
> phylib will default to indirect accesses to MMD devices. The 0xD and 0xE PHY registers
> are not implemented, so those transfers won't have any effect.
In oa_tc6_mdiobus_register() there is the comment:
/* OPEN Alliance 10BASE-T1x compliance MAC-PHYs will have both C22 and
* C45 registers space. If the PHY is discovered via C22 bus protocol it
* assumes it uses C22 protocol and always uses C22 registers indirect
* access to access C45 registers. This is because, we don't have a
* clean separation between C22/C45 register space and C22/C45 MDIO bus
* protocols. Resulting, PHY C45 registers direct access can't be used
* which can save multiple SPI bus access. To support this feature, PHY
* drivers can set .read_mmd/.write_mmd in the PHY driver to call
* .read_c45/.write_c45. Ex: drivers/net/phy/microchip_t1s.c
*/
which is what you are doing.
If this was a DT driven device, you would add:
compatible = "ethernet-phy-ieee802.3-c45";
which would result in the device being probed via C45, and is_c45
would be set true.
Maybe we need to improve the situation here. We know C45 is
implemented, it is part of the standard. So maybe we need to set
is_c45?
In oa_tc6_phy_init() we already have:
tc6->phydev->is_internal = true;
what happens if we add
tc6->phydev->is_c45 = true; ?
Maybe this was discussed already once, when oa_tc6.c? I don't
remember.
Andrew
^ permalink raw reply
* RE: [PATCH net-next 3/5] net: phy: Add support for the ADIN1140 PHY
From: Regus, Ciprian @ 2026-05-21 20:24 UTC (permalink / raw)
To: Andrew Lunn
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <2cfa6680-503a-4c4a-91bc-5f9a4331967d@lunn.ch>
> > +static int adin1140_phy_read_mmd(struct phy_device *phydev, int
> devnum,
> > + u16 regnum)
> > +{
> > + struct mii_bus *bus = phydev->mdio.bus;
> > + int addr = phydev->mdio.addr;
> > +
> > + return __mdiobus_c45_read(bus, addr, devnum, regnum);
> > +}
> > +
> > +static int adin1140_phy_write_mmd(struct phy_device *phydev, int
> devnum,
> > + u16 regnum, u16 val)
> > +{
> > + struct mii_bus *bus = phydev->mdio.bus;
> > + int addr = phydev->mdio.addr;
> > +
> > + return __mdiobus_c45_write(bus, addr, devnum, regnum, val);
> > +}
>
> Why do these exist?
>
The PHY is always probed over C22. Unless read_mmd()/write_mmd() are defined,
phylib will default to indirect accesses to MMD devices. The 0xD and 0xE PHY registers
are not implemented, so those transfers won't have any effect.
^ permalink raw reply
* [PATCH v2 2/2] Docs/admin-guide/mm/damon/usage: clarify current_value of quota goals
From: Maksym Shcherba @ 2026-05-21 20:20 UTC (permalink / raw)
To: SeongJae Park
Cc: Maksym Shcherba, Liam R. Howlett, Andrew Morton,
David Hildenbrand, Jonathan Corbet, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Shuah Khan, Suren Baghdasaryan, Vlastimil Babka,
damon, linux-doc, linux-kernel, linux-mm
In-Reply-To: <20260521202020.126500-1-maksym.shcherba@lnu.edu.ua>
The sysfs interface for DAMON quota goals includes a `current_value` file.
This file is not updated by the kernel and only serves to receive user
input.
Clarify in the documentation that the kernel does not update
`current_value`, and that reading it only has meaning when `target_metric`
is set to `user_input`.
While at it, fix missing commas in the goal files list.
Assisted-by: Antigravity:Gemini-3.1-Pro
Signed-off-by: Maksym Shcherba <maksym.shcherba@lnu.edu.ua>
---
Documentation/admin-guide/mm/damon/usage.rst | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index e3e2ccab218a..5b85a7a2ddf0 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -511,10 +511,12 @@ to ``N-1``. Each directory represents each goal and current achievement.
Among the multiple feedback, the best one is used.
Each goal directory contains five files, namely ``target_metric``,
-``target_value``, ``current_value`` ``nid`` and ``path``. Users can set and
+``target_value``, ``current_value``, ``nid``, and ``path``. Users can set and
get the five parameters for the quota auto-tuning goals that specified on the
:ref:`design doc <damon_design_damos_quotas_auto_tuning>` by writing to and
-reading from each of the files. Note that users should further write
+reading from each of the files. Because the kernel does not update
+``current_value``, reading it only makes sense when ``target_metric`` is
+``user_input``. Note that users should further write
``commit_schemes_quota_goals`` to the ``state`` file of the :ref:`kdamond
directory <sysfs_kdamond>` to pass the feedback to DAMON.
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] mm/damon: fix macro arguments and clarify quota goals doc
From: Maksym Shcherba @ 2026-05-21 20:20 UTC (permalink / raw)
To: SeongJae Park
Cc: Maksym Shcherba, Liam R. Howlett, Andrew Morton,
David Hildenbrand, Jonathan Corbet, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Shuah Khan, Suren Baghdasaryan, Vlastimil Babka,
damon, linux-doc, linux-kernel, linux-mm
- Patch 1 fixes missing parentheses in DAMON iterator macro arguments to
prevent potential build failures.
- Patch 2 clarifies in the sysfs documentation that the `current_value` of
quota goals is only for user input and is not updated by the kernel.
Changes from v1
- v1: https://lore.kernel.org/r/20260518190932.42270-1-maksym.shcherba@lnu.edu.ua/
- Drop patches 2, 3, 5, and 6 from v1 (which implemented and documented
update_schemes_quota_goals).
- Clarify `current_value` behavior in the documentation (Patch 2) instead
of modifying the sysfs API.
- Add SeongJae's Reviewed-by tag to the macro bugfix (Patch 1).
- Fix checkpatch.pl email address mismatch warning.
Maksym Shcherba (2):
mm/damon: fix missing parens in macro arguments
Docs/admin-guide/mm/damon/usage: clarify current_value of quota goals
Documentation/admin-guide/mm/damon/usage.rst | 6 ++++--
include/linux/damon.h | 8 ++++----
2 files changed, 8 insertions(+), 6 deletions(-)
base-commit: 85a7d9e080a3f65869f22c2d50b630462fce332b
--
2.34.1
^ permalink raw reply
* [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Randy Dunlap @ 2026-05-21 19:14 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Stefan Dösinger, Linus Walleij,
Krzysztof Kozlowski, linux-arm-kernel, Jonathan Corbet,
Shuah Khan, linux-doc
Fix multiple documentation build warnings.
Improve punctuation and formatting of the rendered output.
Documentation/arch/arm/zte/zx297520v3.rst:66: WARNING: Title underline too short.
3. Building for built-in U-Boot
--------------------------- [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:90: WARNING: Enumerated list ends without a blank line; unexpected unindent. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:116: WARNING: Inline literal start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:137: ERROR: Unexpected indentation. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:138: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:164: WARNING: Inline literal start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:164: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:7: WARNING: Document or section may not begin with a transition. [docutils]
Fixes: 220ae5d36dba ("ARM: zte: Add zx297520v3 platform support")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Stefan Dösinger <stefandoesinger@gmail.com>
Cc: Linus Walleij <linusw@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
Documentation/arch/arm/zte/zx297520v3.rst | 119 +++++++++-----------
1 file changed, 59 insertions(+), 60 deletions(-)
--- linux-next.orig/Documentation/arch/arm/zte/zx297520v3.rst
+++ linux-next/Documentation/arch/arm/zte/zx297520v3.rst
@@ -4,15 +4,13 @@
Booting Linux on ZTE zx297520v3 SoCs
====================================
-...............................................................................
-
Author: Stefan Dösinger
Date : 27 Jan 2026
1. Hardware description
---------------------------
-Zx297520v3 SoCs use a 64 bit capable Cortex-A53 CPU and GICv3, although they
+Zx297520v3 SoCs use a 64-bit capable Cortex-A53 CPU and GICv3, although they
run in arm32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
it seems to lack VFP and NEON.
@@ -27,7 +25,7 @@ Some devices, especially the stationary
Ethernet switch.
Usually the devices have LEDs for status indication, although some have SPI or
-I2C connected displays
+I2C connected displays.
Some have an SD card slot. If it exists, it is a better choice for the root
file system because it easily outperforms the built-in NAND.
@@ -39,7 +37,7 @@ IRQs on either ends.
There is also a Cortex M0 CPU, which is responsible for early HW initialization
and starting the Cortex A53 CPU. It does not have any essential purpose once
-U-Boot is started. A SRAM-Based handover protocol exists to run custom code on
+U-Boot is started. An SRAM-based handover protocol exists to run custom code on
this CPU.
2. Booting via USB
@@ -63,13 +61,13 @@ Contains an U-Boot version that can be u
CPU and interrupt controller to comply with Linux's booting requirements.
3. Building for built-in U-Boot
----------------------------
+-------------------------------
The devices come with an ancient U-Boot that loads legacy uImages from NAND and
boots them without a chance for the user to interrupt. The images are stored in
files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs,
usually mtd4. A file named "fotaflag" switches between the two modes.
-In addition to the uImage header, those files have a 384 byte signature header,
+In addition to the uImage header, those files have a 384-byte signature header,
which is used for authenticating the images on some devices. Most devices have
this authentication disabled and it is enough to pad the uImage files with 384
zero bytes.
@@ -88,7 +86,7 @@ So to build an image that boots from NAN
6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin
7) cat uimg >> ap_recovery.bin
8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the
-free space is not enough.
+ free space is not enough.
9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag
For development, booting ap_recovery.bin is recommended because the normal boot
@@ -113,55 +111,56 @@ the binary blobs.
The assembly code below is given as an example of how to achieve this:
-```
-#include <linux/irqchip/arm-gic-v3.h>
-#include <asm/assembler.h>
-#include <asm/cp15.h>
-
-@ Detect sane bootloaders and skip the hack
-ldr r3, =0xf2000000
-ldr r3, [r3]
-ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
-cmp r3, r4
-beq skip_zx_hack
-@ This allows EL1 to handle ints hat are normally handled by EL2/3.
-ldr r3, =0xf2000000
-str r4, [r3]
-
-cps #MON_MODE
-
-@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
-@ seems to respond only to non-secure addresses. I have taken insipiration from
-@ Raspberry pi's armstub7.S here.
-mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
- @ Allow hypervisor call.
-mcr p15, 0, r3, c1, c1, 0
-
-@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
-ldr r3, =0xF22020a8
-ldr r4, =0x50
-str r4, [r3]
-ldr r3, =0xF22020ac
-ldr r4, =0x14
-str r4, [r3]
-
-@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
-@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
-mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
-orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
-mcr p15, 6, r3, c12, c12, 5
-mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
-orr r3, #(ICC_SRE_EL1_SRE)
-mcr p15, 0, r3, c12, c12, 5
-
-@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
-@ for EL2.
-mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
-orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
-mcr p15, 4, r3, c12, c9, 5
-isb
-
-@ Back to SVC mode
-cps #SVC_MODE
-skip_zx_hack:
-```
+::
+
+ #include <linux/irqchip/arm-gic-v3.h>
+ #include <asm/assembler.h>
+ #include <asm/cp15.h>
+
+ @ Detect sane bootloaders and skip the hack
+ ldr r3, =0xf2000000
+ ldr r3, [r3]
+ ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
+ cmp r3, r4
+ beq skip_zx_hack
+ @ This allows EL1 to handle ints hat are normally handled by EL2/3.
+ ldr r3, =0xf2000000
+ str r4, [r3]
+
+ cps #MON_MODE
+
+ @ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
+ @ seems to respond only to non-secure addresses. I have taken insipiration from
+ @ Raspberry pi's armstub7.S here.
+ mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
+ @ Allow hypervisor call.
+ mcr p15, 0, r3, c1, c1, 0
+
+ @ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
+ ldr r3, =0xF22020a8
+ ldr r4, =0x50
+ str r4, [r3]
+ ldr r3, =0xF22020ac
+ ldr r4, =0x14
+ str r4, [r3]
+
+ @ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
+ @ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
+ mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
+ orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
+ mcr p15, 6, r3, c12, c12, 5
+ mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
+ orr r3, #(ICC_SRE_EL1_SRE)
+ mcr p15, 0, r3, c12, c12, 5
+
+ @ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
+ @ for EL2.
+ mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
+ orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
+ mcr p15, 4, r3, c12, c9, 5
+ isb
+
+ @ Back to SVC mode
+ cps #SVC_MODE
+ skip_zx_hack:
+
^ permalink raw reply
* Re: [PATCH] docs: gpu: todo: fix spelling of "fucntion"
From: Shuah Khan @ 2026-05-21 18:28 UTC (permalink / raw)
To: Godswill Onwusilike, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet
Cc: dri-devel, linux-doc, linux-kernel, Shuah Khan
In-Reply-To: <20260516210141.42971-1-onwusilikegodswill@gmail.com>
On 5/16/26 15:01, Godswill Onwusilike wrote:
> Correct the spelling of "fucntion" to "function" in todo.rst
> documentation
>
> Signed-off-by: Godswill Onwusilike <onwusilikegodswill@gmail.com>
> ---
> Documentation/gpu/todo.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 841e4e986c48..7526ed31b0af 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -1001,4 +1001,4 @@ DRM driver that can run X11 and Weston.
>
> Contact: Thomas Zimmermann <tzimmermann@suse.de>
>
> -Level: Advanced
> +Level: Advanced
> \ No newline at end of file
Hmm. the patch doesn't fix the spelling in the following line mentioned
in the commit log. Instead it removes and adds the same line.
"rename all inlined fucntions according to driver conventions."
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive
From: Song Liu @ 2026-05-21 18:16 UTC (permalink / raw)
To: Sasha Levin
Cc: Daniel Borkmann, linux-kernel, linux-doc, linux-kselftest, bpf,
live-patching, Greg Kroah-Hartman, Andrew Morton, Jonathan Corbet,
Mathieu Desnoyers, Joshua Peisach, Florian Weimer, Breno Leitao,
Anthony Iliopoulos, Michal Hocko, Jiri Olsa, John Fastabend,
Christian Brauner, KP Singh
In-Reply-To: <ag8lOe6dAOgnWmsQ@laps>
On Thu, May 21, 2026 at 8:31 AM Sasha Levin <sashal@kernel.org> wrote:
>
> On Thu, May 21, 2026 at 11:11:16AM +0200, Daniel Borkmann wrote:
> >On 5/19/26 9:57 PM, Sasha Levin wrote:
> >>Sure, this would also work. How do you see this happening? Can we let a certain
> >>user/pid/etc disable the allowlist if they choose to?
> >
> >I don't think we should, given then we're back to square one where root
> >or some other user would be able to just override/bypass an LSM.
>
> killswitch already disables itself when lockdown is active. We can easily
> disable it too when one of the LSMs that cares about this is active.
>
> >[...]
> >>How do you see this working with the allowlist?
> >
> >We should look at the underlying areas where most of the CVE-like fixes
> >took place (these days should be more easily doable given Claude and friends)
> >and based on that either extend ALLOW_ERROR_INJECTION() or (better) create
> >new hooks which BPF LSM can consume where you can then have a policy to reject
> >requests and tighten the attack surface. For example, the AF_ALG stuff you
>
> So we could grow the LSM tentacles deeper into the kernel, and we can see where
> current CVEs are happening, which I suspect is the darker corners of the kernel
> (old unmaintained, rarely used code), but this definitely won't stay the case,
> right? Newer and better LLMs will discover issues elsewhere, and once the low
> hanging fruits are picked off of the current target subsystems, researchers
> will move elsewhere. We will be dooming ourselves to an endless cat and mouse
> game where we go add LSM hooks after some big security issue goes public.
Do we really need to add new LSM hooks for recent CVEs?
The LSM hooks are designed to cover all the user-kernel interfaces. Then
with properly designed policies, we should have coverage for potential CVEs.
Existing LSM hooks may not be perfect, but we can improve the hooks,
potentially with the help of smart LLMs, so that these hooks can cover
future security issues. In some cases, we will need new policies, but I don't
think new hooks will be needed for most of these CVEs.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH v2] kconfig: add optional warnings for changed input values
From: Nicolas Schier @ 2026-05-21 18:09 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Nathan Chancellor, Masahiro Yamada, Jonathan Corbet, Shuah Khan,
linux-kbuild, linux-doc, linux-kernel
In-Reply-To: <20260521022824.38591-1-pengpeng@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 3041 bytes --]
On Thu, May 21, 2026 at 10:28:24AM +0800, Pengpeng Hou wrote:
> When reading .config input, Kconfig stores user-provided values first and
> then resolves the final value after applying dependencies, ranges, and
> other constraints.
>
> If the final value differs from the user's input, Kconfig already tracks
> that state internally, but it does not provide any focused diagnostic to
> show which explicit inputs were adjusted. This is particularly confusing
> for requested values that get forced down by unmet dependencies or
> clamped by ranges.
>
> Add an opt-in diagnostic controlled by KCONFIG_WARN_CHANGED_INPUT. Emit
> the warnings from conf_write() and conf_write_defconfig() after value
> resolution and through the existing message callback path so the default
> behavior stays unchanged and interactive frontends remain usable.
>
> Avoid the conf_message() formatting buffer for this diagnostic so long
> warning lists are not truncated before reaching the callback, and mark
> processed symbols as written before the SYMBOL_WRITE check so duplicate
> menu nodes cannot emit duplicate warnings.
>
> Document the new environment variable and add tests for both olddefconfig
> and savedefconfig.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> Changes since v1: https://lore.kernel.org/all/20260406233001.1-kconfig-warn-changed-input-pengpeng@iscas.ac.cn/
> - rename "found" to "changed_input_found" as suggested by Nicolas
> - avoid the conf_message() 4096-byte formatting buffer so long warning
> lists are not truncated before the callback sees them
> - mark each processed symbol as SYMBOL_WRITTEN before checking
> SYMBOL_WRITE to avoid duplicate warnings for duplicate menu nodes
> - add duplicate-definition selftest coverage
> - do not carry the Reviewed-by/Tested-by tags because v2 changes warning
> emission and duplicate suppression
>
> Documentation/kbuild/kconfig.rst | 5 +
> scripts/kconfig/confdata.c | 107 +++++++++++++++++-
> .../kconfig/tests/warn_changed_input/Kconfig | 40 +++++++
> .../tests/warn_changed_input/__init__.py | 27 +++++
> .../kconfig/tests/warn_changed_input/config | 3 +
> .../tests/warn_changed_input/expected_config | 6 +
> .../warn_changed_input/expected_defconfig | 1 +
> .../tests/warn_changed_input/expected_stdout | 4 +
> 8 files changed, 189 insertions(+), 4 deletions(-)
> create mode 100644 scripts/kconfig/tests/warn_changed_input/Kconfig
> create mode 100644 scripts/kconfig/tests/warn_changed_input/__init__.py
> create mode 100644 scripts/kconfig/tests/warn_changed_input/config
> create mode 100644 scripts/kconfig/tests/warn_changed_input/expected_config
> create mode 100644 scripts/kconfig/tests/warn_changed_input/expected_defconfig
> create mode 100644 scripts/kconfig/tests/warn_changed_input/expected_stdout
>
Thanks a lot!
Tested-by: Nicolas Schier <nsc@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive
From: Song Liu @ 2026-05-21 18:02 UTC (permalink / raw)
To: Sasha Levin
Cc: Daniel Borkmann, linux-kernel, linux-doc, linux-kselftest, bpf,
live-patching, Greg Kroah-Hartman, Andrew Morton, Jonathan Corbet,
Mathieu Desnoyers, Joshua Peisach, Florian Weimer, Breno Leitao,
Anthony Iliopoulos, Michal Hocko, Jiri Olsa, John Fastabend,
Christian Brauner
In-Reply-To: <ag8Y8L2WCcSEDPkG@laps>
On Thu, May 21, 2026 at 7:38 AM Sasha Levin <sashal@kernel.org> wrote:
>
> On Tue, May 19, 2026 at 03:00:15PM -0700, Song Liu wrote:
> >On Tue, May 19, 2026 at 12:57 PM Sasha Levin <sashal@kernel.org> wrote:
> >[...]
> >> >Fully agree with Song here that there is no clear boundary, and that the
> >> >killswitch could lead to arbitrary, hard to debug breakage if applied to
> >> >the wrong function.. introducing worse bugs than the one being mitigated
> >> >or even /short-circuit LSM enforcement/ (engage security_file_open 0,
> >> >engage cap_capable 0, engage apparmor_* etc).
> >>
> >> This is similar to livepatch, right? Do we need guardrails there too?
> >
> >livepatch has the same guardrails as other kernel modules:
> >CONFIG_MODULE_SIG, CONFIG_MODULE_SIG_FORCE, etc.
>
> Which the user can choose to enable or disable. Livepatches will work just fine
> with CONFIG_MODULE_SIG=n, right?
>
> With the whitelist approach, the user has no choice but to accept it.
>
> Would it make sense to allow disabling the whitelist via a kernel config or
> some runtime flag?
I personally think it makes sense to have options to allow bypassing/blocking
more kernel functions than the current allow list. But I don't know whether
we would like to go all the way to allow it for all the ftrace-able functions.
I think we will need some careful analysis on this.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ti: icssg: Add HSR and LRE PA statistics
From: Felix Maurer @ 2026-05-21 17:06 UTC (permalink / raw)
To: Jakub Kicinski
Cc: MD Danish Anwar, Luka Gejak, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Roger Quadros, Andrew Lunn, Meghana Malladi, Jacob Keller,
David Carlier, Vadim Fedorenko, Kevin Hao, netdev, linux-doc,
linux-kernel, linux-arm-kernel, Vladimir Oltean
In-Reply-To: <20260520153303.33692fe3@kernel.org>
On Wed, May 20, 2026 at 03:33:03PM -0700, Jakub Kicinski wrote:
> On Wed, 20 May 2026 15:30:24 +0530 MD Danish Anwar wrote:
> > What should be the next steps here? Is there any existing defined set of
> > stats where I could populate stats from ICSSG firmware for HSR (similar
> > to ndo_get_stats64 callback). Or de we need to implement a new callback
> > that will do this for HSR.
>
> I'd try to plumb this thru ndo_get_offload_stats
> Close enough for my taste, let's see if anyone objects.
I'm not super well versed with the different options for stats we have
at the moment, so I'm definitely not going to object. I'm just going to
note that the stats I listed are applicable to all HSR/PRP interfaces,
not just the ones with hardware offloads. Therefore, it would IMHO be
nice if the two didn't diverge too much in the end and (best case)
userspace can ask for either the one or the other but get the same
structure back (no need to implement it for the software-only interfaces
in this patch series, I can do that afterwards as well).
Thanks,
Felix
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: serial: rs485: remove deprecated .txt binding stub
From: Conor Dooley @ 2026-05-21 16:48 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: krzk+dt, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Conor Dooley, Jonathan Corbet, Shuah Khan, linux-kernel,
linux-serial, devicetree, linux-doc
In-Reply-To: <20260521162137.6325-1-akash.sukhavasi@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2590 bytes --]
On Thu, May 21, 2026 at 11:21:35AM -0500, Akash Sukhavasi wrote:
> The plain text binding file was superseded by the YAML schema in
> commit d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings
> to json-schema"). The file now contains only a redirect notice.
> Remove it, and update references in serial_core.c and
> serial-rs485.rst to point to the YAML schema.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
Unless I am missing something about how docs.kernel.org redirects
magically work or something along those lines,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Cheers,
Conor.
> ---
> Changes in v2:
> - Update references in serial_core.c and serial-rs485.rst to point
> to rs485.yaml (Sashiko review).
>
> v1: https://lore.kernel.org/all/20260521150748.4816-1-akash.sukhavasi@gmail.com/
>
> Documentation/devicetree/bindings/serial/rs485.txt | 1 -
> Documentation/driver-api/serial/serial-rs485.rst | 2 +-
> drivers/tty/serial/serial_core.c | 2 +-
> 3 files changed, 2 insertions(+), 3 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/serial/rs485.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
> deleted file mode 100644
> index a7fe93efc..000000000
> --- a/Documentation/devicetree/bindings/serial/rs485.txt
> +++ /dev/null
> @@ -1 +0,0 @@
> -See rs485.yaml
> diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst
> index dce061ef7..f53043d21 100644
> --- a/Documentation/driver-api/serial/serial-rs485.rst
> +++ b/Documentation/driver-api/serial/serial-rs485.rst
> @@ -132,4 +132,4 @@ RS485 Serial Communications
> 6. References
> =============
>
> -.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.txt
> +.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.yaml
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 89cebdd27..df4589880 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3496,7 +3496,7 @@ EXPORT_SYMBOL_GPL(uart_try_toggle_sysrq);
> * @port: uart device's target port
> *
> * This function implements the device tree binding described in
> - * Documentation/devicetree/bindings/serial/rs485.txt.
> + * Documentation/devicetree/bindings/serial/rs485.yaml.
> */
> int uart_get_rs485_mode(struct uart_port *port)
> {
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2] dt-bindings: serial: rs485: remove deprecated .txt binding stub
From: Akash Sukhavasi @ 2026-05-21 16:21 UTC (permalink / raw)
To: krzk+dt
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-kernel, linux-serial,
devicetree, linux-doc
The plain text binding file was superseded by the YAML schema in
commit d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings
to json-schema"). The file now contains only a redirect notice.
Remove it, and update references in serial_core.c and
serial-rs485.rst to point to the YAML schema.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Changes in v2:
- Update references in serial_core.c and serial-rs485.rst to point
to rs485.yaml (Sashiko review).
v1: https://lore.kernel.org/all/20260521150748.4816-1-akash.sukhavasi@gmail.com/
Documentation/devicetree/bindings/serial/rs485.txt | 1 -
Documentation/driver-api/serial/serial-rs485.rst | 2 +-
drivers/tty/serial/serial_core.c | 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/rs485.txt
diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
deleted file mode 100644
index a7fe93efc..000000000
--- a/Documentation/devicetree/bindings/serial/rs485.txt
+++ /dev/null
@@ -1 +0,0 @@
-See rs485.yaml
diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst
index dce061ef7..f53043d21 100644
--- a/Documentation/driver-api/serial/serial-rs485.rst
+++ b/Documentation/driver-api/serial/serial-rs485.rst
@@ -132,4 +132,4 @@ RS485 Serial Communications
6. References
=============
-.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.txt
+.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.yaml
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 89cebdd27..df4589880 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3496,7 +3496,7 @@ EXPORT_SYMBOL_GPL(uart_try_toggle_sysrq);
* @port: uart device's target port
*
* This function implements the device tree binding described in
- * Documentation/devicetree/bindings/serial/rs485.txt.
+ * Documentation/devicetree/bindings/serial/rs485.yaml.
*/
int uart_get_rs485_mode(struct uart_port *port)
{
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5 10/13] ima: Add support for flushing the hash table when staging measurements
From: Mimi Zohar @ 2026-05-21 16:06 UTC (permalink / raw)
To: Roberto Sassu, corbet, skhan, dmitry.kasatkin, eric.snowberg,
paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, chenste, nramas, Roberto Sassu
In-Reply-To: <20260429160319.4162918-11-roberto.sassu@huaweicloud.com>
On Wed, 2026-04-29 at 18:03 +0200, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Introduce the new kernel option ima_flush_htable to decide whether or not
> the digests of staged measurement entries are flushed from the hash table,
> when they are deleted.
Unless explicitly requested, the existing hash table is not cleared after
exporting the measurement list. Why is clearing the hash table configurable?
The boot command line option does not provide enough information to decide why
you would or wouldn't want to clear the hash table. Please update the patch
description and the boot command line option.
thanks,
Mimi
>
> When the option is enabled, replace the old hash table with a new one,
> by calling ima_alloc_replace_htable(), and completely delete the
> measurements entries.
>
> Note: This code derives from the Alt-IMA Huawei project, whose license is
> GPL-2.0 OR MIT.
>
> Link: https://github.com/linux-integrity/linux/issues/1
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
^ permalink raw reply
* Re: (subset) [PATCH v7 00/10] Support for Samsung S2MU005 PMIC and its sub-devices
From: Lee Jones @ 2026-05-21 16:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, Yassine Oudjana,
Kaustabh Chakraborty
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Conor Dooley, Krzysztof Kozlowski
In-Reply-To: <20260516-s2mu005-pmic-v7-0-73f9702fb461@disroot.org>
On Sat, 16 May 2026 03:08:32 +0530, Kaustabh Chakraborty wrote:
> S2MU005 is an MFD chip manufactured by Samsung Electronics. This is
> found in various devices manufactured by Samsung and others, including
> all Exynos 7870 devices. It is known to have the following features:
>
> 1. Two LED channels with adjustable brightness for use as a torch, or a
> flash strobe.
> 2. An RGB LED with 8-bit channels. Usually programmed as a notification
> indicator.
> 3. An MUIC, which works with USB micro-B (and USB-C?). For the micro-B
> variant though, it measures the ID-GND resistance using an internal
> ADC.
> 4. A charger device, which reports if charger is online, voltage,
> resistance, etc.
>
> [...]
Applied, thanks!
[01/10] dt-bindings: leds: document Samsung S2M series PMIC flash LED device
commit: a794673949f1aa1dd948ce3ea436af48ea83d7b2
[06/10] leds: flash: add support for Samsung S2M series PMIC flash LED device
commit: f0878c58430c378c47aaece1b29484e4ae8d7faf
[07/10] leds: rgb: add support for Samsung S2M series PMIC RGB LED device
commit: 366ed7a6d22e682e6dfd4d64d8f543bc70c6b58e
[08/10] Documentation: leds: document pattern behavior of Samsung S2M series PMIC RGB LEDs
commit: 1795fd2dbe84ef4d393b69a0b2a3b371f810bde5
--
Lee Jones [李琼斯]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox