Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-04-30 Thread Michael S. Tsirkin
On Tue, Apr 30, 2024 at 08:01:11PM -0500, Mike Christie wrote: > On 4/30/24 7:15 PM, Hillf Danton wrote: > > On Tue, Apr 30, 2024 at 11:23:04AM -0500, Mike Christie wrote: > >> On 4/30/24 8:05 AM, Edward Adam Davis wrote: > >>> static int vhost_task_fn(void *data) > >>> { > >>> struct

Re: [PATCH V1] soc: qcom: smp2p: Introduce tracepoint support

2024-04-30 Thread Bjorn Andersson
On Tue, Apr 30, 2024 at 04:18:27PM -0700, Chris Lew wrote: > On 4/29/2024 12:55 AM, Sudeepgoud Patil wrote: > > Introduce tracepoint support for smp2p providing useful logging > > for communication between clients. > > > > Let's add some more description as to why these tracepoint are useful. Do

Re: [PATCH net-next v8] net/ipv4: add tracepoint for icmp_send

2024-04-30 Thread Jakub Kicinski
On Mon, 29 Apr 2024 17:15:57 +0800 (CST) xu.xi...@zte.com.cn wrote: > Introduce a tracepoint for icmp_send, which can help users to get more > detail information conveniently when icmp abnormal events happen. Rebase please, it doesn't apply. And please put the change log under the --- delimiter.

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-04-30 Thread Mike Christie
On 4/30/24 7:15 PM, Hillf Danton wrote: > On Tue, Apr 30, 2024 at 11:23:04AM -0500, Mike Christie wrote: >> On 4/30/24 8:05 AM, Edward Adam Davis wrote: >>> static int vhost_task_fn(void *data) >>> { >>> struct vhost_task *vtsk = data; >>> @@ -51,7 +51,7 @@ static int vhost_task_fn(void

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-04-30 Thread Hillf Danton
On Tue, Apr 30, 2024 at 11:23:04AM -0500, Mike Christie wrote: > On 4/30/24 8:05 AM, Edward Adam Davis wrote: > > static int vhost_task_fn(void *data) > > { > > struct vhost_task *vtsk = data; > > @@ -51,7 +51,7 @@ static int vhost_task_fn(void *data) > > schedule(); > >

Re: [PATCH V1] soc: qcom: smp2p: Introduce tracepoint support

2024-04-30 Thread Chris Lew
On 4/29/2024 12:55 AM, Sudeepgoud Patil wrote: Introduce tracepoint support for smp2p providing useful logging for communication between clients. Let's add some more description as to why these tracepoint are useful. Do they help us track latency? debugging information for us? for

Re: [PATCH] virtio_net: Warn if insufficient queue length for transmitting

2024-04-30 Thread Michael S. Tsirkin
On Tue, Apr 30, 2024 at 03:35:09PM -0400, Darius Rad wrote: > The transmit queue is stopped when the number of free queue entries is less > than 2+MAX_SKB_FRAGS, in start_xmit(). If the queue length (QUEUE_NUM_MAX) > is less than then this, transmission will immediately trigger a netdev >

[PATCH v13 13/14] Docs/x86/sgx: Add description for cgroup support

2024-04-30 Thread Haitao Huang
From: Sean Christopherson Add initial documentation of how to regulate the distribution of SGX Enclave Page Cache (EPC) memory via the Miscellaneous cgroup controller. Signed-off-by: Sean Christopherson Co-developed-by: Kristen Carlson Accardi Signed-off-by: Kristen Carlson Accardi

[PATCH v13 14/14] selftests/sgx: Add scripts for EPC cgroup testing

2024-04-30 Thread Haitao Huang
With different cgroups, the script starts one or multiple concurrent SGX selftests (test_sgx), each to run the unclobbered_vdso_oversubscribed test case, which loads an enclave of EPC size equal to the EPC capacity available on the platform. The script checks results against the expectation set

[PATCH v13 12/14] x86/sgx: Turn on per-cgroup EPC reclamation

2024-04-30 Thread Haitao Huang
From: Kristen Carlson Accardi Previous patches have implemented all infrastructure needed for per-cgroup EPC page tracking and reclaiming. But all reclaimable EPC pages are still tracked in the global LRU as sgx_epc_page_lru() always returns reference to the global LRU. Change

[PATCH v13 11/14] x86/sgx: Abstract check for global reclaimable pages

2024-04-30 Thread Haitao Huang
From: Kristen Carlson Accardi For the global reclaimer to determine if any page available for reclamation at the global level, it currently only checks for emptiness of the global LRU. That will be inadequate when pages are tracked in multiple LRUs, one per cgroup. For this purpose, create a new

[PATCH v13 09/14] x86/sgx: Implement async reclamation for cgroup

2024-04-30 Thread Haitao Huang
From: Kristen Carlson Accardi In cases EPC pages need be allocated during a page fault and the cgroup usage is near its limit, an asynchronous reclamation needs be triggered to avoid blocking the page fault handling. Create a workqueue, corresponding work item and function definitions for EPC

[PATCH v13 08/14] x86/sgx: Add basic EPC reclamation flow for cgroup

2024-04-30 Thread Haitao Huang
From: Kristen Carlson Accardi Currently in the EPC page allocation, the kernel simply fails the allocation when the current EPC cgroup fails to charge due to its usage reaching limit. This is not ideal. When that happens, a better way is to reclaim EPC page(s) from the current EPC cgroup

[PATCH v13 07/14] x86/sgx: Abstract tracking reclaimable pages in LRU

2024-04-30 Thread Haitao Huang
From: Kristen Carlson Accardi The SGX driver tracks reclaimable EPC pages by adding a newly allocated page into the global LRU list in sgx_mark_page_reclaimable(), and doing the opposite in sgx_unmark_page_reclaimable(). To support SGX EPC cgroup, the SGX driver will need to maintain an LRU

[PATCH v13 06/14] x86/sgx: Add sgx_epc_lru_list to encapsulate LRU list

2024-04-30 Thread Haitao Huang
From: Sean Christopherson Introduce a data structure to wrap the existing reclaimable list and its spinlock. Each cgroup later will have one instance of this structure to track EPC pages allocated for processes associated with the same cgroup. Just like the global SGX reclaimer (ksgxd), an EPC

[PATCH v13 10/14] x86/sgx: Charge mem_cgroup for per-cgroup reclamation

2024-04-30 Thread Haitao Huang
Enclave Page Cache(EPC) memory can be swapped out to regular system memory, and the consumed memory should be charged to a proper mem_cgroup. Currently the selection of mem_cgroup to charge is done in sgx_encl_get_mem_cgroup(). But it considers all contexts other than the ksgxd thread are user

[PATCH v13 05/14] x86/sgx: Implement basic EPC misc cgroup functionality

2024-04-30 Thread Haitao Huang
From: Kristen Carlson Accardi SGX Enclave Page Cache (EPC) memory allocations are separate from normal RAM allocations, and are managed solely by the SGX subsystem. The existing cgroup memory controller cannot be used to limit or account for SGX EPC memory, which is a desirable feature in some

[PATCH v13 04/14] cgroup/misc: Add SGX EPC resource type

2024-04-30 Thread Haitao Huang
From: Kristen Carlson Accardi Add SGX EPC memory, MISC_CG_RES_SGX_EPC, to be a valid resource type for the misc controller. Signed-off-by: Kristen Carlson Accardi Co-developed-by: Haitao Huang Signed-off-by: Haitao Huang Reviewed-by: Jarkko Sakkinen Reviewed-by: Kai Huang Tested-by: Jarkko

[PATCH v13 03/14] cgroup/misc: Export APIs for SGX driver

2024-04-30 Thread Haitao Huang
From: Kristen Carlson Accardi The SGX EPC cgroup will reclaim EPC pages when usage in a cgroup reaches its or ancestor's limit. This requires a walk from the current cgroup up to the root similar to misc_cg_try_charge(). Export misc_cg_parent() to enable this walk. The SGX driver also needs

[PATCH v13 02/14] cgroup/misc: Add per resource callbacks for CSS events

2024-04-30 Thread Haitao Huang
From: Kristen Carlson Accardi The misc cgroup controller (subsystem) currently does not perform resource type specific action for Cgroups Subsystem State (CSS) events: the 'css_alloc' event when a cgroup is created and the 'css_free' event when a cgroup is destroyed. Define callbacks for those

[PATCH v13 00/14] Add Cgroup support for SGX EPC memory

2024-04-30 Thread Haitao Huang
SGX Enclave Page Cache (EPC) memory allocations are separate from normal RAM allocations, and are managed solely by the SGX subsystem. The existing cgroup memory controller cannot be used to limit or account for SGX EPC memory, which is a desirable feature in some environments, e.g., support for

[PATCH v13 01/14] x86/sgx: Replace boolean parameters with enums

2024-04-30 Thread Haitao Huang
Replace boolean parameters for 'reclaim' in the function sgx_alloc_epc_page() and its callers with an enum. Also opportunistically remove non-static declaration of __sgx_alloc_epc_page() and a typo Signed-off-by: Haitao Huang Suggested-by: Jarkko Sakkinen Suggested-by: Dave Hansen

[PATCH] virtio_net: Warn if insufficient queue length for transmitting

2024-04-30 Thread Darius Rad
The transmit queue is stopped when the number of free queue entries is less than 2+MAX_SKB_FRAGS, in start_xmit(). If the queue length (QUEUE_NUM_MAX) is less than then this, transmission will immediately trigger a netdev watchdog timeout. Report this condition earlier and more directly.

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

2024-04-30 Thread David Hildenbrand
On 26.04.24 21:55, Guillaume Morin wrote: On 26 Apr 9:19, David Hildenbrand wrote: A couple of points: a) Don't use page_mapcount(). Either folio_mapcount(), but likely you want to check PageAnonExclusive. b) If you're not following the can_follow_write_pte/_pmd model, you are doing

Re: [PATCH v7 6/6] remoteproc: qcom: enable in-kernel PD mapper

2024-04-30 Thread Chris Lew
On 4/26/2024 6:36 PM, Dmitry Baryshkov wrote: On Sat, 27 Apr 2024 at 04:03, Chris Lew wrote: On 4/24/2024 2:28 AM, Dmitry Baryshkov wrote: diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c b/drivers/remoteproc/qcom_q6v5_adsp.c index 1d24c9b656a8..02d0c626b03b 100644 ---

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

2024-04-30 Thread Guillaume Morin
On 30 Apr 20:21, David Hildenbrand wrote: > Sorry for not replying earlier, was busy with other stuff. I'll try getiing > that stuff into shape and send it out soonish. No worries. Let me know what you think of the FOLL_FORCE patch when you have a sec. > > I went with using one write uprobe

[PATCH] eventfs/tracing: Add callback for release of an eventfs_inode

2024-04-30 Thread Steven Rostedt
From: "Steven Rostedt (Google)" Synthetic events create and destroy tracefs files when they are created and removed. The tracing subsystem has its own file descriptor representing the state of the events attached to the tracefs files. There's a race between the eventfs files and this file

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

2024-04-30 Thread David Hildenbrand
On 30.04.24 17:22, Guillaume Morin wrote: On 26 Apr 21:55, Guillaume Morin wrote: On 26 Apr 9:19, David Hildenbrand wrote: A couple of points: a) Don't use page_mapcount(). Either folio_mapcount(), but likely you want to check PageAnonExclusive. b) If you're not following the

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-04-30 Thread Michael S. Tsirkin
On Tue, Apr 30, 2024 at 11:23:04AM -0500, Mike Christie wrote: > On 4/30/24 8:05 AM, Edward Adam Davis wrote: > > static int vhost_task_fn(void *data) > > { > > struct vhost_task *vtsk = data; > > @@ -51,7 +51,7 @@ static int vhost_task_fn(void *data) > > schedule(); > >

[PATCH] scripts/spdxcheck: Add count of missing files to stats output

2024-04-30 Thread Bird, Tim
Add a count of files missing an SPDX header to the stats output. This is useful detailed information for working on SPDX header additions. Signed-off-by: Tim Bird --- scripts/spdxcheck.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/spdxcheck.py b/scripts/spdxcheck.py index

[PATCH v3 4/4] dax/bus.c: Use the right locking mode (read vs write) in size_show

2024-04-30 Thread Vishal Verma
In size_show(), the dax_dev_rwsem only needs a read lock, but was acquiring a write lock. Change it to down_read_interruptible() so it doesn't unnecessarily hold a write lock. Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem") Cc: Dan Williams Reviewed-by: Dan

[PATCH v3 3/4] dax/bus.c: Don't use down_write_killable for non-user processes

2024-04-30 Thread Vishal Verma
Change an instance of down_write_killable() to a simple down_write() where there is no user process that might want to interrupt the operation. Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem") Reported-by: Dan Williams Reviewed-by: Dan Williams Signed-off-by:

[PATCH v3 1/4] dax/bus.c: replace WARN_ON_ONCE() with lockdep asserts

2024-04-30 Thread Vishal Verma
In [1], Dan points out that all of the WARN_ON_ONCE() usage in the referenced patch should be replaced with lockdep_assert_held, or lockdep_held_assert_write(). Replace these as appropriate. Link: https://lore.kernel.org/r/65f0b5ef41817_aa2229...@dwillia2-mobl3.amr.corp.intel.com.notmuch [1]

[PATCH v3 2/4] dax/bus.c: fix locking for unregister_dax_dev / unregister_dax_mapping paths

2024-04-30 Thread Vishal Verma
Commit c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem") aimed to undo device_lock() abuses for protecting changes to dax-driver internal data-structures like the dax_region resource tree to device-dax-instance range structures. However, the device_lock() was

Re: [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1

2024-04-30 Thread Mathieu Poirier
On Tue, Apr 30, 2024 at 04:23:05PM +0530, Beleswar Padhi wrote: > PSC controller has a limitation that it can only power-up the second core > when the first core is in ON state. Power-state for core0 should be equal > to or higher than core1, else the kernel is seen hanging during rproc > loading.

Re: [PATCH v4 0/4] Support MT8188 SCP core 1

2024-04-30 Thread Mathieu Poirier
On Tue, Apr 30, 2024 at 09:15:30AM +0800, Olivia Wen wrote: > Change in v4: > Updating the description of PATCH v4 4/4. > > Olivia Wen (4): > dt-bindings: remoteproc: mediatek: Support MT8188 dual-core SCP > remoteproc: mediatek: Support MT8188 SCP core 1 > remoteproc: mediatek: Support

Re: [PATCH v9 00/36] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph

2024-04-30 Thread Andrii Nakryiko
On Tue, Apr 30, 2024 at 6:32 AM Masami Hiramatsu wrote: > > On Mon, 29 Apr 2024 13:25:04 -0700 > Andrii Nakryiko wrote: > > > On Mon, Apr 29, 2024 at 6:51 AM Masami Hiramatsu > > wrote: > > > > > > Hi Andrii, > > > > > > On Thu, 25 Apr 2024 13:31:53 -0700 > > > Andrii Nakryiko wrote: > > > >

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-04-30 Thread Mike Christie
On 4/30/24 8:05 AM, Edward Adam Davis wrote: > static int vhost_task_fn(void *data) > { > struct vhost_task *vtsk = data; > @@ -51,7 +51,7 @@ static int vhost_task_fn(void *data) > schedule(); > } > > - mutex_lock(>exit_mutex); > + mutex_lock(_mutex);

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

2024-04-30 Thread Guillaume Morin
On 26 Apr 21:55, Guillaume Morin wrote: > > On 26 Apr 9:19, David Hildenbrand wrote: > > A couple of points: > > > > a) Don't use page_mapcount(). Either folio_mapcount(), but likely you want > > to check PageAnonExclusive. > > > > b) If you're not following the can_follow_write_pte/_pmd model,

Re: [PATCH 2/2] x86/sgx: Resolve EREMOVE page vs EAUG page data race

2024-04-30 Thread Dmitrii Kuvaiskii
On Mon, Apr 29, 2024 at 04:11:03PM +0300, Jarkko Sakkinen wrote: > On Mon Apr 29, 2024 at 1:43 PM EEST, Dmitrii Kuvaiskii wrote: > > Two enclave threads may try to add and remove the same enclave page > > simultaneously (e.g., if the SGX runtime supports both lazy allocation > > and

Re: [PATCH 1/2] x86/sgx: Resolve EAUG race where losing thread returns SIGBUS

2024-04-30 Thread Dmitrii Kuvaiskii
On Mon, Apr 29, 2024 at 04:04:24PM +0300, Jarkko Sakkinen wrote: > On Mon Apr 29, 2024 at 1:43 PM EEST, Dmitrii Kuvaiskii wrote: > > Two enclave threads may try to access the same non-present enclave page > > simultaneously (e.g., if the SGX runtime supports lazy allocation). The > > threads will

Re: [PATCH 0/2] x86/sgx: Fix two data races in EAUG/EREMOVE flows

2024-04-30 Thread Dmitrii Kuvaiskii
On Mon, Apr 29, 2024 at 04:06:39PM +0300, Jarkko Sakkinen wrote: > On Mon Apr 29, 2024 at 1:43 PM EEST, Dmitrii Kuvaiskii wrote: > > SGX runtimes such as Gramine may implement EDMM-based lazy allocation of > > enclave pages and may support MADV_DONTNEED semantics [1]. The former > > implies

Re: [PATCH v9 1/3] soc: qcom: Add qcom_rproc_minidump module

2024-04-30 Thread Bjorn Andersson
On Tue, Mar 26, 2024 at 07:43:12PM +0530, Mukesh Ojha wrote: > Add qcom_rproc_minidump module in a preparation to remove > minidump specific code from driver/remoteproc/qcom_common.c > and provide needed exported API, this as well helps to > abstract minidump specific data layout from qualcomm's >

Re: [PATCH v9 00/36] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph

2024-04-30 Thread Google
On Mon, 29 Apr 2024 13:25:04 -0700 Andrii Nakryiko wrote: > On Mon, Apr 29, 2024 at 6:51 AM Masami Hiramatsu wrote: > > > > Hi Andrii, > > > > On Thu, 25 Apr 2024 13:31:53 -0700 > > Andrii Nakryiko wrote: > > > > > Hey Masami, > > > > > > I can't really review most of that code as I'm

[PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-04-30 Thread Edward Adam Davis
[syzbot reported] BUG: KASAN: slab-use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in atomic_long_read include/linux/atomic/atomic-instrumented.h:3188 [inline] BUG: KASAN: slab-use-after-free in __mutex_unlock_slowpath+0xef/0x750

Re: [PATCH v7 05/16] module: make module_memory_{alloc,free} more self-contained

2024-04-30 Thread Philippe Mathieu-Daudé
On 29/4/24 14:16, Mike Rapoport wrote: From: "Mike Rapoport (IBM)" Move the logic related to the memory allocation and freeing into module_memory_alloc() and module_memory_free(). Signed-off-by: Mike Rapoport (IBM) --- kernel/module/main.c | 64 +++-

[PATCH v22 4/5] Documentation: tracing: Add ring-buffer mapping

2024-04-30 Thread Vincent Donnefort
It is now possible to mmap() a ring-buffer to stream its content. Add some documentation and a code example. Signed-off-by: Vincent Donnefort diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index 5092d6c13af5..0b300901fd75 100644 --- a/Documentation/trace/index.rst

[PATCH v22 3/5] tracing: Allow user-space mapping of the ring-buffer

2024-04-30 Thread Vincent Donnefort
Currently, user-space extracts data from the ring-buffer via splice, which is handy for storage or network sharing. However, due to splice limitations, it is imposible to do real-time analysis without a copy. A solution for that problem is to let the user-space map the ring-buffer directly. The

[PATCH v22 2/5] ring-buffer: Introducing ring-buffer mapping functions

2024-04-30 Thread Vincent Donnefort
In preparation for allowing the user-space to map a ring-buffer, add a set of mapping functions: ring_buffer_{map,unmap}() And controls on the ring-buffer: ring_buffer_map_get_reader() /* swap reader and head */ Mapping the ring-buffer also involves: A unique ID for each subbuf of the

[PATCH v22 1/5] ring-buffer: Allocate sub-buffers with __GFP_COMP

2024-04-30 Thread Vincent Donnefort
In preparation for the ring-buffer memory mapping, allocate compound pages for the ring-buffer sub-buffers to enable us to map them to user-space with vm_insert_pages(). Signed-off-by: Vincent Donnefort diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index

[PATCH v22 0/5] Introducing trace buffer mapping by user-space

2024-04-30 Thread Vincent Donnefort
The tracing ring-buffers can be stored on disk or sent to network without any copy via splice. However the later doesn't allow real time processing of the traces. A solution is to give userspace direct access to the ring-buffer pages via a mapping. An application can now become a consumer of the

[PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs

2024-04-30 Thread Beleswar Padhi
PSC controller has a limitation that it can only power-up the second core when the first core is in ON state. Power-state for core0 should be equal to or higher than core1. Therefore, prevent core1 from powering up before core0 during the start process from sysfs. Similarly, prevent core0 from

[PATCH v3 1/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1

2024-04-30 Thread Beleswar Padhi
From: Apurva Nandan PSC controller has a limitation that it can only power-up the second core when the first core is in ON state. Power-state for core0 should be equal to or higher than core1, else the kernel is seen hanging during rproc loading. Make the powering up of cores sequential, by

[PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1

2024-04-30 Thread Beleswar Padhi
PSC controller has a limitation that it can only power-up the second core when the first core is in ON state. Power-state for core0 should be equal to or higher than core1, else the kernel is seen hanging during rproc loading. Make the powering up of cores sequential, by waiting for the current

Re: EEVDF/vhost regression (bisected to 86bfbb7ce4f6 sched/fair: Add lag based placement)

2024-04-30 Thread Tobias Huschle
It took me a while, but I was able to figure out why EEVDF behaves different then CFS does. I'm still waiting for some official confirmation of my assumptions but it all seems very plausible to me. Leaving aside all the specifics of vhost and kworkers, a more general description of the scenario

Re: [PATCH v2 2/2] LoongArch: Add steal time support in guest side

2024-04-30 Thread maobibo
On 2024/4/30 下午4:23, Huacai Chen wrote: Hi, Bibo, On Tue, Apr 30, 2024 at 9:45 AM Bibo Mao wrote: Percpu struct kvm_steal_time is added here, its size is 64 bytes and also defined as 64 bytes, so that the whole structure is in one physical page. When vcpu is onlined, function

[syzbot] [net?] [virt?] [kvm?] KASAN: slab-use-after-free Read in vhost_task_fn

2024-04-30 Thread syzbot
Hello, syzbot found the following issue on: HEAD commit:bb7a2467e6be Add linux-next specific files for 20240426 git tree: linux-next console+strace: https://syzkaller.appspot.com/x/log.txt?x=123bf96b18 kernel config: https://syzkaller.appspot.com/x/.config?x=5c6a0288262dd108

Re: [PATCH v2 2/2] LoongArch: Add steal time support in guest side

2024-04-30 Thread Huacai Chen
Hi, Bibo, On Tue, Apr 30, 2024 at 9:45 AM Bibo Mao wrote: > > Percpu struct kvm_steal_time is added here, its size is 64 bytes and > also defined as 64 bytes, so that the whole structure is in one physical > page. > > When vcpu is onlined, function pv_enable_steal_time() is called. This >

Re: [PATCH v4 4/4] remoteproc: mediatek: Add IMGSYS IPI command

2024-04-30 Thread AngeloGioacchino Del Regno
Il 30/04/24 03:15, Olivia Wen ha scritto: Add an IPI command definition for communication with IMGSYS through SCP mailbox. Signed-off-by: Olivia Wen Reviewed-by: AngeloGioacchino Del Regno

[syzbot] Monthly trace report (Apr 2024)

2024-04-30 Thread syzbot
Hello trace maintainers/developers, This is a 31-day syzbot report for the trace subsystem. All related reports/information can be found at: https://syzkaller.appspot.com/upstream/s/trace During the period, 3 new issues were detected and 2 were fixed. In total, 9 issues are still open and 34

Re: [PATCH v9 1/3] soc: qcom: Add qcom_rproc_minidump module

2024-04-30 Thread Mukesh Ojha
Gentle ping.. -Mukesh On 3/26/2024 7:43 PM, Mukesh Ojha wrote: Add qcom_rproc_minidump module in a preparation to remove minidump specific code from driver/remoteproc/qcom_common.c and provide needed exported API, this as well helps to abstract minidump specific data layout from qualcomm's