On Tue, 2025-07-15 at 15:40 +0300, Elena Reshetova wrote:
> Changes since v7 following reviews by Dave:
>
> - change sgx_usage_count to be a normal int type
> and greatly simplify the sgx_inc_usage_count func.
> This results in requiring a mutex for each sgx_(vepc_)open
> but given that the mu
On Thu, Jul 17, 2025 at 07:31:57PM -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 17, 2025 at 10:12:03PM +0200, Lukas Wunner wrote:
> > pciehp_handle_presence_or_link_change() is called from pciehp_ist(),
> > the IRQ thread. During safe removal the IRQ thread is busy in
> > pciehp_unconfigure_devi
On Fri, 18 Jul 2025 10:41:32 +0800 Ye Liu wrote:
> From: Ye Liu
>
> Replace repeated (20 - PAGE_SHIFT) calculations with standard macros:
> - MB_TO_PAGES(mb)converts MB to page count
> - PAGES_TO_MB(pages) converts pages to MB
>
> No functional change.
>
> ...
>
> +/*
> + * Convert betwee
From: Ye Liu
Replace repeated (20 - PAGE_SHIFT) calculations with standard macros:
- MB_TO_PAGES(mb)converts MB to page count
- PAGES_TO_MB(pages) converts pages to MB
No functional change.
Signed-off-by: Ye Liu
---
include/linux/mm.h| 9 +
kernel/rcu/rcuscale.c | 2 +-
kernel
On Thu, Jul 17, 2025 at 9:52 PM Paolo Abeni wrote:
>
> On 7/17/25 8:01 AM, Jason Wang wrote:
> > On Thu, Jul 17, 2025 at 1:55 PM Michael S. Tsirkin wrote:
> >> On Thu, Jul 17, 2025 at 10:03:00AM +0800, Jason Wang wrote:
> >>> On Thu, Jul 17, 2025 at 8:04 AM Jakub Kicinski wrote:
>
> On
On Fri, 18 Jul 2025 01:49:24 +0200 Matthieu Baerts wrote:
> I see that you already marked the mptcp-connect-sh selftest as ignored,
> so I guess we are not causing other troubles with the CI. (We could then
> also apply this series here and ignore the new tests, but it is also
> fine for me to wait
Hi Jakub,
On 17/07/2025 16:42, Jakub Kicinski wrote:
> On Wed, 16 Jul 2025 18:35:11 +0200 Matthieu Baerts wrote:
And just to be sure, no CPU or IO overload at that moment? I didn't see
such errors reported by our CI, but I can try to reproduce them locally
in different conditions.
On Thu, Jul 17, 2025 at 10:12:03PM +0200, Lukas Wunner wrote:
> On Thu, Jul 17, 2025 at 11:11:44AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 14, 2025 at 08:11:04AM +0200, Lukas Wunner wrote:
> > > On Wed, Jul 09, 2025 at 04:55:26PM -0400, Michael S. Tsirkin wrote:
> > > > At the moment, in c
On 7/17/25 4:20 PM, Koralahalli Channabasappa, Smita wrote:
> On 7/17/2025 12:06 PM, Dave Jiang wrote:
>>
>>
>> On 7/17/25 10:58 AM, Koralahalli Channabasappa, Smita wrote:
>>>
>>>
>>> On 7/16/2025 4:48 PM, Alison Schofield wrote:
On Wed, Jul 16, 2025 at 02:29:52PM -0700, Koralahalli Channa
On 7/17/2025 12:06 PM, Dave Jiang wrote:
On 7/17/25 10:58 AM, Koralahalli Channabasappa, Smita wrote:
On 7/16/2025 4:48 PM, Alison Schofield wrote:
On Wed, Jul 16, 2025 at 02:29:52PM -0700, Koralahalli Channabasappa, Smita
wrote:
On 7/16/2025 1:20 PM, Alison Schofield wrote:
On Tue, Jul
On Tuesday, June 17, 2025 2:39:29 PM Central European Summer Time Neeraj Kumar
wrote:
> Added __pmem_region_label_update region label update routine to update
> region label
>
> Signed-off-by: Neeraj Kumar
> ---
> drivers/nvdimm/label.c | 142
> drivers
On 7/17/25 07:52, David Hildenbrand wrote:
> print_bad_pte() looks like something that should actually be a WARN
> or similar, but historically it apparently has proven to be useful to
> detect corruption of page tables even on production systems -- report
> the issue and keep the system running to
On 7/9/25 1:46 PM, Luca Weiss wrote:
> Add a dts for the PMIC used e.g. with Milos SoC-based devices.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 17.07.25 20:29, Lorenzo Stoakes wrote:
On Thu, Jul 17, 2025 at 01:52:08PM +0200, David Hildenbrand wrote:
The huge zero folio is refcounted (+mapcounted -- is that a word?)
differently than "normal" folios, similarly (but different) to the ordinary
shared zeropage.
Yeah, I sort of wonder if
On Thu, Jul 17, 2025 at 11:11:44AM -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 14, 2025 at 08:11:04AM +0200, Lukas Wunner wrote:
> > On Wed, Jul 09, 2025 at 04:55:26PM -0400, Michael S. Tsirkin wrote:
> > > At the moment, in case of a surprise removal, the regular remove
> > > callback is invoke
On 17.07.25 22:03, Lorenzo Stoakes wrote:
On Thu, Jul 17, 2025 at 01:52:11PM +0200, David Hildenbrand wrote:
Let's introduce vm_normal_page_pud(), which ends up being fairly simple
because of our new common helpers and there not being a PUD-sized zero
folio.
Use vm_normal_page_pud() in folio_wa
-/*
- * vm_normal_page -- This function gets the "struct page" associated with a
pte.
+/**
+ * vm_normal_page_pfn() - Get the "struct page" associated with a PFN in a
+ * non-special page table entry.
This is a bit nebulous/confusing, I mean you'll get PTE entries with PT
On Thu, Jul 17, 2025 at 01:52:12PM +0200, David Hildenbrand wrote:
> ... and hide it behind a kconfig option. There is really no need for
> any !xen code to perform this check.
Lovely :)
>
> The naming is a bit off: we want to find the "normal" page when a PTE
> was marked "special". So it's real
On Thu, Jul 17, 2025 at 01:52:11PM +0200, David Hildenbrand wrote:
> Let's introduce vm_normal_page_pud(), which ends up being fairly simple
> because of our new common helpers and there not being a PUD-sized zero
> folio.
>
> Use vm_normal_page_pud() in folio_walk_start() to resolve a TODO,
> stru
On 17.07.25 21:55, Lorenzo Stoakes wrote:
On Thu, Jul 17, 2025 at 08:51:51PM +0100, Lorenzo Stoakes wrote:
@@ -721,37 +772,21 @@ struct page *vm_normal_page_pmd(struct vm_area_struct
*vma, unsigned long addr,
print_bad_page_map(vma, addr, pmd_val(pmd), NULL);
ret
The report will now look something like (dumping pgd to pmd values):
[ 77.943408] BUG: Bad page map in process XXX entry:8001233f5867
[ 77.944077] addr:7fd84bb1c000 vm_flags:08100071 anon_vma: ...
[ 77.945186] pgd:10a89f067 p4d:10a89f067 pud:10e5a2067 pmd:105327067
Not using pgdp_
On Thu, Jul 17, 2025 at 08:51:51PM +0100, Lorenzo Stoakes wrote:
> > @@ -721,37 +772,21 @@ struct page *vm_normal_page_pmd(struct vm_area_struct
> > *vma, unsigned long addr,
> > print_bad_page_map(vma, addr, pmd_val(pmd), NULL);
> > return NULL;
> > }
> > -
> > - if
On Thu, Jul 17, 2025 at 01:52:10PM +0200, David Hildenbrand wrote:
> Let's reduce the code duplication and factor out the non-pte/pmd related
> magic into vm_normal_page_pfn().
>
> To keep it simpler, check the pfn against both zero folios. We could
> optimize this, but as it's only for the !CONFIG
On 30/06/2025 16.32, Petr Pavlu wrote:
> The moduleparam code allows modules to provide their own definition of
> MODULE_PARAM_PREFIX, instead of using the default KBUILD_MODNAME ".".
>
> Commit 730b69d22525 ("module: check kernel param length at compile time,
> not runtime") added a check to ensu
On Thu, Jul 17, 2025 at 01:52:09PM +0200, David Hildenbrand wrote:
> print_bad_pte() looks like something that should actually be a WARN
> or similar, but historically it apparently has proven to be useful to
> detect corruption of page tables even on production systems -- report
> the issue and ke
On 7/17/25 10:58 AM, Koralahalli Channabasappa, Smita wrote:
>
>
> On 7/16/2025 4:48 PM, Alison Schofield wrote:
>> On Wed, Jul 16, 2025 at 02:29:52PM -0700, Koralahalli Channabasappa, Smita
>> wrote:
>>> On 7/16/2025 1:20 PM, Alison Schofield wrote:
On Tue, Jul 15, 2025 at 11:01:23PM -0
On Thu, Jul 17, 2025 at 01:52:08PM +0200, David Hildenbrand wrote:
> The huge zero folio is refcounted (+mapcounted -- is that a word?)
> differently than "normal" folios, similarly (but different) to the ordinary
> shared zeropage.
Yeah, I sort of wonder if we shouldn't just _not_ do any of that
On Fri, Jul 04, 2025 at 08:08:41PM +0900, Shashank Balaji wrote:
> Current cpu.max tests (both the normal one and the nested one) are broken.
>
> They setup cpu.max with 1000 us quota and the default period (100,000 us).
> A cpu hog is run for a duration of 1s as per wall clock time. This correspo
On Thu, Jul 17, 2025 at 01:52:07PM +0200, David Hildenbrand wrote:
> Let's convert to vmf_insert_folio_pmd().
>
> There is a theoretical change in behavior: in the unlikely case there is
> already something mapped, we'll now still call trace_dax_pmd_load_hole()
> and return VM_FAULT_NOPAGE.
>
> Pre
On 7/16/2025 4:48 PM, Alison Schofield wrote:
On Wed, Jul 16, 2025 at 02:29:52PM -0700, Koralahalli Channabasappa, Smita
wrote:
On 7/16/2025 1:20 PM, Alison Schofield wrote:
On Tue, Jul 15, 2025 at 11:01:23PM -0700, Koralahalli Channabasappa, Smita
wrote:
Hi Alison,
On 7/15/2025 2:07 PM,
On Thu, Jul 17, 2025 at 01:52:06PM +0200, David Hildenbrand wrote:
> Just like we do for vmf_insert_page_mkwrite() -> ... ->
> insert_page_into_pte_locked() with the shared zeropage, support the
> huge zero folio in vmf_insert_folio_pmd().
>
> When (un)mapping the huge zero folio in page tables, we
On Thu, Jul 17, 2025 at 01:52:05PM +0200, David Hildenbrand wrote:
> Let's clean it all further up.
>
> No functional change intended.
>
> Reviewed-by: Oscar Salvador
> Reviewed-by: Alistair Popple
> Signed-off-by: David Hildenbrand
LGTM:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/huge_memory.
On Thu, Jul 17, 2025 at 01:52:04PM +0200, David Hildenbrand wrote:
> Let's clean it all further up.
>
> No functional change intended.
>
> Reviewed-by: Oscar Salvador
> Reviewed-by: Alistair Popple
> Signed-off-by: David Hildenbrand
Very nice!
Reviewed-by: Lorenzo Stoakes
> ---
> mm/huge_me
On Thu, Jul 17, 2025 at 8:15 AM Lorenz Bauer wrote:
>
> On Thu, Jul 17, 2025 at 3:49 PM Alexei Starovoitov
> wrote:
>
> > __pa_symbol() should work for start_BTF, but would be good
> > to double check with Ard that the rest stays linear.
>
> Alexei,
>
> This code in the arm64 setup does make me t
On Wed, Jul 16, 2025 at 05:29:00PM -0500, Bjorn Helgaas wrote:
> On Tue, Jul 15, 2025 at 02:28:20AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 14, 2025 at 04:13:51PM -0500, Bjorn Helgaas wrote:
> > > On Mon, Jul 14, 2025 at 02:26:19AM -0400, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 09, 2
On Thu, Jul 17, 2025 at 3:49 PM Alexei Starovoitov
wrote:
> __pa_symbol() should work for start_BTF, but would be good
> to double check with Ard that the rest stays linear.
Alexei,
This code in the arm64 setup does make me think we'll be OK.
kernel_code.start = __pa_symbol(_stext);
kernel_c
On Mon, Jul 14, 2025 at 08:11:04AM +0200, Lukas Wunner wrote:
> On Wed, Jul 09, 2025 at 04:55:26PM -0400, Michael S. Tsirkin wrote:
> > At the moment, in case of a surprise removal, the regular remove
> > callback is invoked, exclusively. This works well, because mostly, the
> > cleanup would be t
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski :
On Wed, 16 Jul 2025 19:57:17 +0800 you wrote:
> The deadlock appears in a stack trace like:
>
> virtnet_probe()
> rtnl_lock()
> virtio_config_changed_work()
> netdev_notify_peers()
> rtnl_lock()
>
On Thu, Jul 17, 2025 at 6:18 AM Lorenz Bauer wrote:
>
> Hi Breno,
>
> Thanks for reaching out.
>
> On Thu, Jul 17, 2025 at 1:39 PM Breno Leitao wrote:
>
> > Should __pa_symbol() be used instead of virt_to_phys()?
>
> I'm not really well versed with mm in general. Looking around a bit I
> found so
On Mon, Jul 14, 2025 at 11:52:05AM +, Peng Fan wrote:
> > Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
> >
> [...]
> > New warnings running 'make CHECK_DTBS=y for
> > arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
> > a7123e857...@nxp.com:
> >
> > arch/
On Wed, Jul 16, 2025 at 04:46:38PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> When the Cortex-M remote core is started and already running before
> Linux boots (typically by the Cortex-A bootloader using a command like
> bootaux), the current driver is unable to attach to it. This
On Wed, 16 Jul 2025 18:35:11 +0200 Matthieu Baerts wrote:
> >> And just to be sure, no CPU or IO overload at that moment? I didn't see
> >> such errors reported by our CI, but I can try to reproduce them locally
> >> in different conditions.
> >
> > None that I can see. The test run ~10min after
On Wed, Jul 16, 2025 at 06:10:03PM -0700, Tiffany Yang wrote:
> Hello,
>
> binder_alloc_selftest provides a robust set of checks for the binder
> allocator, but it rarely runs because it must hook into a running binder
> process and block all other binder threads until it completes. The test
> its
On Wed, 2025-07-16 at 18:37 -0700, Alexei Starovoitov wrote:
> On Mon, Jul 14, 2025 at 5:04 AM KaFai Wan
> wrote:
> >
> > The reuslt:
> >
> > $ tools/testing/selftests/bpf/test_progs --name=tracing_deny
> > #467/1 tracing_deny/migrate_disable:OK
> > #467 tracing_deny:OK
> > Summary
Quote from the virtio specification chapter 4.2.2.2:
"For the device-specific configuration space, the driver MUST use 8 bit
wide accesses for 8 bit wide fields, 16 bit wide and aligned accesses
for 16 bit wide fields and 32 bit wide and aligned accesses for 32 and
64 bit wide fields."
Signed-off
The Virtio GPIO Linux driver reads the configuration space in a way not
conformant with the virtio specification. The hypervisor we are using is
strict in what it accepts so the current behavior causes a problem.
Builds on top of gpio/for-next, tested on Linux v6.5.7.
On 7/17/25 8:01 AM, Jason Wang wrote:
> On Thu, Jul 17, 2025 at 1:55 PM Michael S. Tsirkin wrote:
>> On Thu, Jul 17, 2025 at 10:03:00AM +0800, Jason Wang wrote:
>>> On Thu, Jul 17, 2025 at 8:04 AM Jakub Kicinski wrote:
On Mon, 14 Jul 2025 16:47:52 +0800 Jason Wang wrote:
> This seri
Le Thu, Jul 17, 2025 at 01:53:38PM +0800, Tze-nan Wu a écrit :
> We observed a regression in our customer’s environment after enabling
> CONFIG_LAZY_RCU. In the Android Update Engine scenario, where ioctl() is
> used heavily, we found that callbacks queued via call_rcu_hurry (such as
> percpu_ref_s
Hi Breno,
Thanks for reaching out.
On Thu, Jul 17, 2025 at 1:39 PM Breno Leitao wrote:
> Should __pa_symbol() be used instead of virt_to_phys()?
I'm not really well versed with mm in general. Looking around a bit I
found some explanation in [1]. Your suggested fix does make sense to
me based o
Hello Lorenz,
On Tue, May 20, 2025 at 02:01:17PM +0100, Lorenz Bauer wrote:
> diff --git a/kernel/bpf/sysfs_btf.c b/kernel/bpf/sysfs_btf.c
> index
> 81d6cf90584a7157929c50f62a5c6862e7a3d081..941d0d2427e3a2d27e8f1cff7b6424d0d41817c1
> 100644
> --- a/kernel/bpf/sysfs_btf.c
> +++ b/kernel/bpf/sysfs
On Thu, 17 Jul 2025 at 14:31, Michael S. Tsirkin wrote:
>
> On Thu, Jul 17, 2025 at 10:01:07AM +0100, Will Deacon wrote:
> > Hi all,
> >
> > Here is version four of the patches I previously posted here:
> >
> > v1: https://lore.kernel.org/r/20250625131543.5155-1-w...@kernel.org
> > v2: https:/
On Thu, Jul 17, 2025 at 10:01:07AM +0100, Will Deacon wrote:
> Hi all,
>
> Here is version four of the patches I previously posted here:
>
> v1: https://lore.kernel.org/r/20250625131543.5155-1-w...@kernel.org
> v2: https://lore.kernel.org/r/20250701164507.14883-1-w...@kernel.org
> v3: https
On Thu, Jul 17, 2025 at 10:01:07AM +0100, Will Deacon wrote:
> Hi all,
>
> Here is version four of the patches I previously posted here:
>
> v1: https://lore.kernel.org/r/20250625131543.5155-1-w...@kernel.org
> v2: https://lore.kernel.org/r/20250701164507.14883-1-w...@kernel.org
> v3: https
Fix format-security warnings by using proper format strings when
passing message variables to ksft_exit_fail_msg(),
ksft_test_result_pass(), and ksft_test_result_skip() function.
This prevents potential security issues and eliminates compiler warnings
when building with -Wformat-security.
Signed-
... and hide it behind a kconfig option. There is really no need for
any !xen code to perform this check.
The naming is a bit off: we want to find the "normal" page when a PTE
was marked "special". So it's really not "finding a special" page.
Improve the documentation, and add a comment in the co
Let's reduce the code duplication and factor out the non-pte/pmd related
magic into vm_normal_page_pfn().
To keep it simpler, check the pfn against both zero folios. We could
optimize this, but as it's only for the !CONFIG_ARCH_HAS_PTE_SPECIAL
case, it's not a compelling micro-optimization.
With
Let's introduce vm_normal_page_pud(), which ends up being fairly simple
because of our new common helpers and there not being a PUD-sized zero
folio.
Use vm_normal_page_pud() in folio_walk_start() to resolve a TODO,
structuring the code like the other (pmd/pte) cases. Defer
introducing vm_normal_f
print_bad_pte() looks like something that should actually be a WARN
or similar, but historically it apparently has proven to be useful to
detect corruption of page tables even on production systems -- report
the issue and keep the system running to make it easier to actually detect
what is going wr
The huge zero folio is refcounted (+mapcounted -- is that a word?)
differently than "normal" folios, similarly (but different) to the ordinary
shared zeropage.
For this reason, we special-case these pages in
vm_normal_page*/vm_normal_folio*, and only allow selected callers to
still use them (e.g.,
Let's convert to vmf_insert_folio_pmd().
There is a theoretical change in behavior: in the unlikely case there is
already something mapped, we'll now still call trace_dax_pmd_load_hole()
and return VM_FAULT_NOPAGE.
Previously, we would have returned VM_FAULT_FALLBACK, and the caller
would have za
Just like we do for vmf_insert_page_mkwrite() -> ... ->
insert_page_into_pte_locked() with the shared zeropage, support the
huge zero folio in vmf_insert_folio_pmd().
When (un)mapping the huge zero folio in page tables, we neither
adjust the refcount nor the mapcount, just like for the shared zero
Let's clean it all further up.
No functional change intended.
Reviewed-by: Oscar Salvador
Reviewed-by: Alistair Popple
Signed-off-by: David Hildenbrand
---
mm/huge_memory.c | 36 +---
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/mm/huge_memor
Let's clean it all further up.
No functional change intended.
Reviewed-by: Oscar Salvador
Reviewed-by: Alistair Popple
Signed-off-by: David Hildenbrand
---
mm/huge_memory.c | 72
1 file changed, 24 insertions(+), 48 deletions(-)
diff --git a/m
Based on mm/mm-new from today that contains [2].
Cleanup and unify vm_normal_page_*() handling, also marking the
huge zerofolio as special in the PMD. Add+use vm_normal_page_pud() and
cleanup that XEN vm_ops->find_special_page thingy.
There are plans of using vm_normal_page_*() more widely soon.
On Tue, 15 Jul 2025 22:11:41 +0100, Mark Brown wrote:
> Some build environments for the selftests are not picking up the newly
> added AT_HWCAP3 when using the libc headers, even with headers_install
> (which we require already for the arm64 selftests). As a quick fix add
> local definitions of th
Hi Clément,
On 7/11/25 15:19, Clément Léger wrote:
This selftest tests all the currently emulated instructions (except for
the RV32 compressed ones which are left as a future exercise for a RV32
user). For the FPU instructions, all the FPU registers are tested.
Signed-off-by: Clément Léger
--
Hi all,
Here is version four of the patches I previously posted here:
v1: https://lore.kernel.org/r/20250625131543.5155-1-w...@kernel.org
v2: https://lore.kernel.org/r/20250701164507.14883-1-w...@kernel.org
v3: https://lore.kernel.org/r/20250714152103.6949-1-w...@kernel.org
There are only
On Thu, Jul 17, 2025 at 5:01 PM Will Deacon wrote:
>
> vhost_vsock_alloc_skb() returns NULL for packets advertising a length
> larger than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE in the packet header. However,
> this is only checked once the SKB has been allocated and, if the length
> in the packet header i
On Thu, Jul 17, 2025 at 10:01:09AM +0100, Will Deacon wrote:
When receiving a vsock packet in the guest, only the virtqueue buffer
size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,
virtio_vsock_skb_rx_put() uses the length from the packet header as the
length argument to skb_pu
On Thu, 17 Jul 2025 at 11:10, Jason Wang wrote:
>
> On Thu, Jul 17, 2025 at 5:01 PM Will Deacon wrote:
> >
> > vhost_vsock_alloc_skb() returns NULL for packets advertising a length
> > larger than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE in the packet header. However,
> > this is only checked once the SKB h
When receiving a packet from a guest, vhost_vsock_handle_tx_kick()
calls vhost_vsock_alloc_linear_skb() to allocate and fill an SKB with
the receive data. Unfortunately, these are always linear allocations and
can therefore result in significant pressure on kmalloc() considering
that the maximum pa
When transmitting a vsock packet, virtio_transport_send_pkt_info() calls
virtio_transport_alloc_linear_skb() to allocate and fill SKBs with the
transmit data. Unfortunately, these are always linear allocations and
can therefore result in significant pressure on kmalloc() considering
that the maximu
virtio_vsock_alloc_linear_skb() checks that the requested size is at
least big enough for the packet header (VIRTIO_VSOCK_SKB_HEADROOM).
Of the three callers of virtio_vsock_alloc_linear_skb(), only
vhost_vsock_alloc_skb() can potentially pass a packet smaller than the
header size and, as it alrea
In preparation for using virtio_vsock_skb_rx_put() when populating SKBs
on the vsock TX path, rename virtio_vsock_skb_rx_put() to
virtio_vsock_skb_put().
No functional change.
Reviewed-by: Stefano Garzarella
Signed-off-by: Will Deacon
---
drivers/vhost/vsock.c| 2 +-
include/linux/
In preparation for nonlinear allocations for large SKBs, rename
virtio_vsock_alloc_skb() to virtio_vsock_alloc_linear_skb() to indicate
that it returns linear SKBs unconditionally and switch all callers over
to this new interface for now.
No functional change.
Reviewed-by: Stefano Garzarella
Sig
virtio_vsock_skb_rx_put() only calls skb_put() if the length in the
packet header is not zero even though skb_put() handles this case
gracefully.
Remove the functionally redundant check from virtio_vsock_skb_rx_put()
and, on the assumption that this is a worthwhile optimisation for
handling credit
When receiving a vsock packet in the guest, only the virtqueue buffer
size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,
virtio_vsock_skb_rx_put() uses the length from the packet header as the
length argument to skb_put(), potentially resulting in SKB overflow if
the host has gone
vhost_vsock_alloc_skb() returns NULL for packets advertising a length
larger than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE in the packet header. However,
this is only checked once the SKB has been allocated and, if the length
in the packet header is zero, the SKB may not be freed immediately.
Hoist the size
When allocating receive buffers for the vsock virtio RX virtqueue, an
SKB is allocated with a 4140 data payload (the 44-byte packet header +
VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE). Even when factoring in the SKB
overhead, the resulting 8KiB allocation thanks to the rounding in
kmalloc_reserve() is waste
On 17.07.25 10:38, Alistair Popple wrote:
On Tue, Jul 15, 2025 at 03:23:45PM +0200, David Hildenbrand wrote:
Let's convert to vmf_insert_folio_pmd().
There is a theoretical change in behavior: in the unlikely case there is
already something mapped, we'll now still call trace_dax_pmd_load_hole()
On Tue, Jul 15, 2025 at 03:23:45PM +0200, David Hildenbrand wrote:
> Let's convert to vmf_insert_folio_pmd().
>
> There is a theoretical change in behavior: in the unlikely case there is
> already something mapped, we'll now still call trace_dax_pmd_load_hole()
> and return VM_FAULT_NOPAGE.
>
> P
On 17.07.25 00:27, Andrew Morton wrote:
On Wed, 16 Jul 2025 10:47:29 +0200 David Hildenbrand wrote:
However the series rejects due to the is_huge_zero_pmd ->
is_huge_zero_pfn changes in Luiz's "mm: introduce snapshot_page() v3"
series, so could we please have a redo against present mm-new?
On Wed, Jul 16, 2025 at 11:32:10PM -0700, Kees Cook wrote:
> This really screams for a struct-based way to in-place declare a
> seq_buf. The current macro only works on the stack. I think this
> will work; I'll send a patch once I get it tested:
>
> #define DECLARE_SEQ_BUF(NAME, SIZE) \
On Thu Jul 10, 2025 at 12:30 AM CEST, Rob Herring (Arm) wrote:
>
> On Wed, 09 Jul 2025 13:13:07 +0200, Luca Weiss wrote:
>> Document the bindings for the ADSP, CDSP, MPSS and WPSS PAS on the Milos
>> (e.g. SM7635) SoC.
>>
>> Signed-off-by: Luca Weiss
>> ---
>> .../bindings/remoteproc/qcom,milos-
On Thu, Jun 19, 2025 at 12:04 PM Christian Brauner wrote:
>
> On Thu, 12 Jun 2025 17:40:29 +0800, Chen Linxuan wrote:
> > This patch add a simple functional test for the "abort" file
> > in fusectlfs (/sys/fs/fuse/connections/ID/about).
Miklos,
I see that this patch ended up in your tree.
Pleas
On 17/07/2025 08:54, Luca Weiss wrote:
> No double colon is necessary in the description. Fix it.
>
> Reported-by: Rob Herring
> Closes: https://lore.kernel.org/lkml/20250625150458.ga1182597-r...@kernel.org/
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzy
On 17/07/2025 08:54, Luca Weiss wrote:
> No double colon is necessary in the description. Fix it for all bindings
> so future bindings won't have the same copy-paste mistake.
>
> Reported-by: Rob Herring
> Closes: https://lore.kernel.org/lkml/20250625150458.ga1182597-r...@kernel.org/
> Signed-off
On 17/07/2025 08:54, Luca Weiss wrote:
> No double colon is necessary in the description. Fix it for all bindings
> so future bindings won't have the same copy-paste mistake.
>
> Reported-by: Rob Herring
> Closes: https://lore.kernel.org/lkml/20250625150458.ga1182597-r...@kernel.org/
> Signed-off
88 matches
Mail list logo
