On Tue, Oct 15, 2024 at 6:48 PM 'Liam R. Howlett' via kernel-team
wrote:
>
> * Suren Baghdasaryan [241014 16:36]:
> > Add mas_for_each_rev() function to iterate maple tree nodes in reverse
> > order.
> >
> > Suggested-by: Liam R. Howlett
> > Signed-off-by: Suren Baghdasaryan
>
> I am now sure I
* Suren Baghdasaryan [241014 16:36]:
> Add mas_for_each_rev() function to iterate maple tree nodes in reverse
> order.
>
> Suggested-by: Liam R. Howlett
> Signed-off-by: Suren Baghdasaryan
I am now sure I added a R-B in a reply to this :)
> ---
> include/linux/maple_tree.h | 14 +
On Tue, Oct 15, 2024 at 12:52 PM Sabyrzhan Tasbolatov
wrote:
>
> > Too bad. I guess we have to duplicate both kasan_check_write and
> > check_object_size before both do_strncpy_from_user calls in
> > strncpy_from_user.
>
> Shall we do it once in strncpy_from_user() as I did in v1?
> Please let me
On Tue, Oct 15, 2024 at 2:08 PM Shakeel Butt wrote:
>
> On Mon, Oct 14, 2024 at 07:10:56PM GMT, Suren Baghdasaryan wrote:
> > On Mon, Oct 14, 2024 at 4:51 PM Andrew Morton
> > wrote:
> > >
> > > On Mon, 14 Oct 2024 13:36:43 -0700 Suren Baghdasaryan
> > > wrote:
> > >
> > > > When a module gets
On Mon, Oct 14, 2024 at 07:10:56PM GMT, Suren Baghdasaryan wrote:
> On Mon, Oct 14, 2024 at 4:51 PM Andrew Morton
> wrote:
> >
> > On Mon, 14 Oct 2024 13:36:43 -0700 Suren Baghdasaryan
> > wrote:
> >
> > > When a module gets unloaded there is a possibility that some of the
> > > allocations it
On Tue, Oct 15, 2024, Nikolas Wipper wrote:
> On 15.10.24 17:58, Sean Christopherson wrote:
> > ...
> >
> > And from a performance perspective, synchronizing on kvm->srcu is going to
> > be
> > susceptible to random slowdowns, because writers will have to wait until
> > all vCPUs
> > drop SRCU, e
DAMON debugfs interface was the only user interface of DAMON at the
beginning[1]. However, it turned out the interface would be not good
enough for long-term flexibility and stability.
In Feb 2022[2], we therefore introduced DAMON sysfs interface as an
alternative user interface that aims long-te
On Tue, Oct 15, 2024, Nicolas Saenz Julienne wrote:
> Hi Sean,
>
> On Tue Oct 15, 2024 at 3:58 PM UTC, Sean Christopherson wrote:
> > Before we spend too much time cleaning things up, I want to first settle on
> > the
> > overall design, because it's not clear to me that punting
> > HvTranslateV
On 15.10.24 17:58, Sean Christopherson wrote:
> ...
>
> And from a performance perspective, synchronizing on kvm->srcu is going to be
> susceptible to random slowdowns, because writers will have to wait until all
> vCPUs
> drop SRCU, even if they have nothing to do with PV TLB flushes. E.g. if vC
Hi Sean,
On Tue Oct 15, 2024 at 3:58 PM UTC, Sean Christopherson wrote:
> Before we spend too much time cleaning things up, I want to first settle on
> the
> overall design, because it's not clear to me that punting
> HvTranslateVirtualAddress
> to userspace is a net positive. We agreed that VT
On Tue, Oct 15, 2024 at 09:05:18AM -0700, Oliver Upton wrote:
> On Sat, Oct 12, 2024 at 10:28:10AM +0100, David Woodhouse wrote:
> > On Tue, 2024-10-01 at 08:33 -0700, Oliver Upton wrote:
> > > On Thu, Sep 26, 2024 at 07:37:59PM +0100, David Woodhouse wrote:
> > > > + vm = setup_vm(guest_test
On Mon, Oct 14, 2024 at 6:48 PM Suren Baghdasaryan wrote:
>
> On Mon, Oct 14, 2024 at 4:32 PM Andrew Morton
> wrote:
> >
> > On Mon, 14 Oct 2024 13:36:41 -0700 Suren Baghdasaryan
> > wrote:
> >
> > > Patch #2 copies module tags into virtually contiguous memory which
> > > serves two purposes:
On Sat, Oct 12, 2024 at 10:28:10AM +0100, David Woodhouse wrote:
> On Tue, 2024-10-01 at 08:33 -0700, Oliver Upton wrote:
> > On Thu, Sep 26, 2024 at 07:37:59PM +0100, David Woodhouse wrote:
> > > + vm = setup_vm(guest_test_system_off2, &source, &target);
> > > + vcpu_get_reg(target, KV
On Tue, Oct 15, 2024 at 8:42 AM David Hildenbrand wrote:
>
> On 15.10.24 16:59, Suren Baghdasaryan wrote:
> > On Tue, Oct 15, 2024 at 12:32 AM David Hildenbrand wrote:
> >>
> >> On 15.10.24 01:53, John Hubbard wrote:
> >>> On 10/14/24 4:48 PM, Yosry Ahmed wrote:
> On Mon, Oct 14, 2024 at 1:3
On Tue, Oct 15, 2024, Vitaly Kuznetsov wrote:
> Nikolas Wipper writes:
>
> > On 10.10.24 10:57, Vitaly Kuznetsov wrote:
>
> ...
>
> >>> int kvm_hv_vcpu_flush_tlb(struct kvm_vcpu *vcpu);
> >>> +
> >>> +static inline bool kvm_hv_vcpu_suspended(struct kvm_vcpu *vcpu)
> >>> +{
> >>> + return vcpu-
On 15.10.24 16:59, Suren Baghdasaryan wrote:
On Tue, Oct 15, 2024 at 12:32 AM David Hildenbrand wrote:
On 15.10.24 01:53, John Hubbard wrote:
On 10/14/24 4:48 PM, Yosry Ahmed wrote:
On Mon, Oct 14, 2024 at 1:37 PM Suren Baghdasaryan wrote:
Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store all
On Tue, Oct 15, 2024 at 11:01:44AM -0400, Eric Farman wrote:
> On Mon, 2024-10-14 at 20:43 +0200, Heiko Carstens wrote:
> > On Mon, Oct 14, 2024 at 04:46:16PM +0200, David Hildenbrand wrote:
...
> > +#define DIAG500_SC_STOR_LIMIT 4
...
> I like the idea of a defined constant here instead of hardcod
On Tue, Oct 15, 2024 at 1:10 AM Yosry Ahmed wrote:
>
> On Mon, Oct 14, 2024 at 6:58 PM Suren Baghdasaryan wrote:
> >
> > On Mon, Oct 14, 2024 at 5:03 PM 'John Hubbard' via kernel-team
> > wrote:
> > >
> > > On 10/14/24 4:56 PM, Yosry Ahmed wrote:
> > > > On Mon, Oct 14, 2024 at 4:53 PM John Hubb
On Mon, 2024-10-14 at 20:43 +0200, Heiko Carstens wrote:
> On Mon, Oct 14, 2024 at 04:46:16PM +0200, David Hildenbrand wrote:
> > To support memory devices under QEMU/KVM, such as virtio-mem,
> > we have to prepare our kernel virtual address space accordingly and
> > have to know the highest possib
On Tue, Oct 15, 2024 at 12:32 AM David Hildenbrand wrote:
>
> On 15.10.24 01:53, John Hubbard wrote:
> > On 10/14/24 4:48 PM, Yosry Ahmed wrote:
> >> On Mon, Oct 14, 2024 at 1:37 PM Suren Baghdasaryan
> >> wrote:
> >>>
> >>> Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store allocation tag
> >>> refe
On Tue, Oct 15, 2024 at 5:19 AM 'Mike Rapoport' via kernel-team
wrote:
>
> On Mon, Oct 14, 2024 at 01:36:44PM -0700, Suren Baghdasaryan wrote:
> > The memory reserved for module tags does not need to be backed by
> > physical pages until there are tags to store there. Change the way
> > we reserve
On Tue, 15 Oct 2024 at 16:11, Dongliang Mu wrote:
>
> On Tue, Oct 15, 2024 at 10:09 PM Haoyang Liu
> wrote:
> >
> > fix a typo in dev-tools/kmsan.rst
> >
> > Signed-off-by: Haoyang Liu
> > ---
> > Documentation/dev-tools/kmsan.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
On Tue, Oct 15, 2024 at 10:09 PM Haoyang Liu wrote:
>
> fix a typo in dev-tools/kmsan.rst
>
> Signed-off-by: Haoyang Liu
> ---
> Documentation/dev-tools/kmsan.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/dev-tools/kmsan.rst
> b/Documentation/dev-too
fix a typo in dev-tools/kmsan.rst
Signed-off-by: Haoyang Liu
---
Documentation/dev-tools/kmsan.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kmsan.rst
b/Documentation/dev-tools/kmsan.rst
index 6a48d96c5c85..0dc668b183f6 100644
--- a/Documentatio
On 2024-10-14 04:27, kernel test robot wrote:
Hello,
kernel test robot noticed "WARNING:at_kernel/hazptr.c:#hazptr_scan" on:
commit: c1508707268498a6fd3ca5853ad65f9482c12374 ("[RFC PATCH v3 4/4] sched+mm: Use
hazard pointers to track lazy active mm existence")
url:
https://github.com/intel-
On Thu, Oct 10, 2024 at 04:18:13PM +0100, Marc Zyngier wrote:
> From 20c98d2647c11db1e40768f92c5998ff5d764a3a Mon Sep 17 00:00:00 2001
> From: Marc Zyngier
> Date: Thu, 10 Oct 2024 16:13:26 +0100
> Subject: [PATCH] KVM: arm64: Shave a few bytes from the EL2 idmap code
>
> Our idmap is becoming to
On Mon, Oct 14, 2024 at 01:36:44PM -0700, Suren Baghdasaryan wrote:
> The memory reserved for module tags does not need to be backed by
> physical pages until there are tags to store there. Change the way
> we reserve this memory to allocate only virtual area for the tags
> and populate it with phy
On Tue, Oct 15, 2024 at 6:18 AM Andrey Konovalov wrote:
>
> On Tue, Oct 15, 2024 at 1:10 AM Andrew Morton
> wrote:
> >
> > On Mon, 14 Oct 2024 07:57:00 +0500 Sabyrzhan Tasbolatov
> > wrote:
> >
> > > Migrate the copy_user_test to the KUnit framework to verify out-of-bound
> > > detection via K
On 15.10.24 12:08, Heiko Carstens wrote:
On Tue, Oct 15, 2024 at 10:41:21AM +0200, David Hildenbrand wrote:
On 15.10.24 10:30, Heiko Carstens wrote:
On Mon, Oct 14, 2024 at 09:26:03PM +0200, David Hildenbrand wrote:
On 14.10.24 20:20, Heiko Carstens wrote:
Looks like this could work. But the
On Tue, Oct 15, 2024 at 10:41:21AM +0200, David Hildenbrand wrote:
> On 15.10.24 10:30, Heiko Carstens wrote:
> > On Mon, Oct 14, 2024 at 09:26:03PM +0200, David Hildenbrand wrote:
> > > On 14.10.24 20:20, Heiko Carstens wrote:
> > > > Looks like this could work. But the comment in smp.c above
> >
On 15.10.24 10:53, David Hildenbrand wrote:
On 15.10.24 10:41, David Hildenbrand wrote:
On 15.10.24 10:30, Heiko Carstens wrote:
On Mon, Oct 14, 2024 at 09:26:03PM +0200, David Hildenbrand wrote:
On 14.10.24 20:20, Heiko Carstens wrote:
Looks like this could work. But the comment in smp.c abo
On 15.10.24 10:41, David Hildenbrand wrote:
On 15.10.24 10:30, Heiko Carstens wrote:
On Mon, Oct 14, 2024 at 09:26:03PM +0200, David Hildenbrand wrote:
On 14.10.24 20:20, Heiko Carstens wrote:
Looks like this could work. But the comment in smp.c above
dump_available() needs to be updated.
A
On 15.10.24 10:46, Heiko Carstens wrote:
On Tue, Oct 15, 2024 at 10:32:43AM +0200, David Hildenbrand wrote:
On 15.10.24 10:21, Heiko Carstens wrote:
On Tue, Oct 15, 2024 at 10:16:20AM +0200, David Hildenbrand wrote:
On 15.10.24 10:12, Heiko Carstens wrote:
On Mon, Oct 14, 2024 at 09:35:27PM +
On Tue, Oct 15, 2024 at 10:32:43AM +0200, David Hildenbrand wrote:
> On 15.10.24 10:21, Heiko Carstens wrote:
> > On Tue, Oct 15, 2024 at 10:16:20AM +0200, David Hildenbrand wrote:
> > > On 15.10.24 10:12, Heiko Carstens wrote:
> > > > On Mon, Oct 14, 2024 at 09:35:27PM +0200, David Hildenbrand wro
On 15.10.24 10:30, Heiko Carstens wrote:
On Mon, Oct 14, 2024 at 09:26:03PM +0200, David Hildenbrand wrote:
On 14.10.24 20:20, Heiko Carstens wrote:
Looks like this could work. But the comment in smp.c above
dump_available() needs to be updated.
A right, I remember that there was some outdate
On Mon, Oct 14, 2024 at 09:16:45PM +0200, David Hildenbrand wrote:
> On 14.10.24 20:48, Heiko Carstens wrote:
> > On Mon, Oct 14, 2024 at 04:46:17PM +0200, David Hildenbrand wrote:
> > > to dump. Based on this, support for dumping virtio-mem memory can be
> > Hm.. who will add this support? This lo
On 15.10.24 10:21, Heiko Carstens wrote:
On Tue, Oct 15, 2024 at 10:16:20AM +0200, David Hildenbrand wrote:
On 15.10.24 10:12, Heiko Carstens wrote:
On Mon, Oct 14, 2024 at 09:35:27PM +0200, David Hildenbrand wrote:
On 14.10.24 20:04, Heiko Carstens wrote:
"If only there would be a query subc
On Mon, Oct 14, 2024 at 09:26:03PM +0200, David Hildenbrand wrote:
> On 14.10.24 20:20, Heiko Carstens wrote:
> > Looks like this could work. But the comment in smp.c above
> > dump_available() needs to be updated.
>
> A right, I remember that there was some outdated documentation.
>
> >
> > Are
On Tue, Oct 15, 2024 at 10:16:20AM +0200, David Hildenbrand wrote:
> On 15.10.24 10:12, Heiko Carstens wrote:
> > On Mon, Oct 14, 2024 at 09:35:27PM +0200, David Hildenbrand wrote:
> > > On 14.10.24 20:04, Heiko Carstens wrote:
> > "If only there would be a query subcode available, so that the prog
Nikolas Wipper writes:
> On 10.10.24 10:57, Vitaly Kuznetsov wrote:
...
>>> int kvm_hv_vcpu_flush_tlb(struct kvm_vcpu *vcpu);
>>> +
>>> +static inline bool kvm_hv_vcpu_suspended(struct kvm_vcpu *vcpu)
>>> +{
>>> + return vcpu->arch.hyperv_enabled &&
>>> + READ_ONCE(vcpu->arch.hyperv
On 15.10.24 10:12, Heiko Carstens wrote:
On Mon, Oct 14, 2024 at 09:35:27PM +0200, David Hildenbrand wrote:
On 14.10.24 20:04, Heiko Carstens wrote:
On Mon, Oct 14, 2024 at 04:46:14PM +0200, David Hildenbrand wrote:
If so, it would be nice to document that too; but that is not
necessarily your
On Mon, Oct 14, 2024 at 09:35:27PM +0200, David Hildenbrand wrote:
> On 14.10.24 20:04, Heiko Carstens wrote:
> > On Mon, Oct 14, 2024 at 04:46:14PM +0200, David Hildenbrand wrote:
> > If so, it would be nice to document that too; but that is not
> > necessarily your problem.
>
> I can squash:
>
On Mon, Oct 14, 2024 at 6:58 PM Suren Baghdasaryan wrote:
>
> On Mon, Oct 14, 2024 at 5:03 PM 'John Hubbard' via kernel-team
> wrote:
> >
> > On 10/14/24 4:56 PM, Yosry Ahmed wrote:
> > > On Mon, Oct 14, 2024 at 4:53 PM John Hubbard wrote:
> > >>
> > >> On 10/14/24 4:48 PM, Yosry Ahmed wrote:
>
On Mon, 14 Oct 2024 20:56:59 +0200
Heiko Carstens wrote:
> On Mon, Oct 14, 2024 at 04:46:12PM +0200, David Hildenbrand wrote:
> > Let's finally add s390 support for virtio-mem; my last RFC was sent
> > 4 years ago, and a lot changed in the meantime.
> >
> > The latest QEMU series is available at
On 15.10.24 01:53, John Hubbard wrote:
On 10/14/24 4:48 PM, Yosry Ahmed wrote:
On Mon, Oct 14, 2024 at 1:37 PM Suren Baghdasaryan wrote:
Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store allocation tag
references directly in the page flags. This eliminates memory
overhead caused by page_ext and r
45 matches
Mail list logo
