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

2024-05-02 Thread Peter Zijlstra
On Wed, May 01, 2024 at 11:31:02AM -0400, Michael S. Tsirkin wrote: > On Wed, May 01, 2024 at 12:51:51PM +0200, Peter Zijlstra wrote: > > I'm still wondering why exactly it is imperative for t2 to preempt t1. > > Is there some unexpressed serialization / spin-waiting ? > > > I am not sure but I

Re: [PATCH v15 3/4] dts: zynqmp: add properties for TCM in remoteproc

2024-05-02 Thread Michal Simek
On 4/12/24 20:37, Tanmay Shah wrote: Add properties as per new bindings in zynqmp remoteproc node to represent TCM address and size. This patch also adds alternative remoteproc node to represent remoteproc cluster in split mode. By default lockstep mode is enabled and users should disable it

Re: [PATCH 20/20] [RFC] sh: dma: Remove unused functionality

2024-05-02 Thread John Paul Adrian Glaubitz
e: > > > > dma_extend(), get_dma_info_by_name(), register_chan_caps(), and > > > > request_dma_bycap() are unused. Remove them, and all related code. > > > > > > > > Signed-off-by: Geert Uytterhoeven > > > > I assume we could re-add

Re: [PATCH 20/20] [RFC] sh: dma: Remove unused functionality

2024-05-02 Thread Geert Uytterhoeven
register_chan_caps(), and > > > request_dma_bycap() are unused. Remove them, and all related code. > > > > > > Signed-off-by: Geert Uytterhoeven > > I assume we could re-add these again in case we need them, but it would be > > good > > if Yoshinori could comment on whe

Re: [PATCH 12/20] sh: dma: Remove unused dmac_search_free_channel()

2024-05-02 Thread Geert Uytterhoeven
Hi Adrian, On Wed, May 1, 2024 at 11:09 AM John Paul Adrian Glaubitz wrote: > On Fri, 2024-03-01 at 22:02 +0100, Geert Uytterhoeven wrote: > > arch/sh/drivers/dma/dma-api.c:164:5: warning: no previous prototype for > > 'dmac_search_free_channel' [-Wmissing-prototypes] > > > >

Re: [PATCH] tracing: Fix uaf issue in tracing_open_file_tr

2024-05-02 Thread 吳澤南
On Wed, 2024-05-01 at 23:50 -0400, Steven Rostedt wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Thu, 2 May 2024 03:10:24 + > Tze-nan Wu (吳澤南) wrote: > > > > > > Sorry for my late reply, I'm

Re: [PATCH] tracing: Fix uaf issue in tracing_open_file_tr

2024-05-01 Thread 吳澤南
On Wed, 2024-05-01 at 23:50 -0400, Steven Rostedt wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Thu, 2 May 2024 03:10:24 + > Tze-nan Wu (吳澤南) wrote: > > > > > > Sorry for my late reply, I'm

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

2024-05-01 Thread Guillaume Morin
On 30 Apr 21:25, David Hildenbrand wrote: > > I tried to get the hugepd stuff right but this was the first I heard > > about it :-) Afaict follow_huge_pmd and friends were already DTRT > > I'll have to have a closer look at some details (the hugepd writability > check looks a bit odd), but it's

Re: [PATCH] tracing: Fix uaf issue in tracing_open_file_tr

2024-05-01 Thread Steven Rostedt
On Thu, 2 May 2024 03:10:24 + Tze-nan Wu (吳澤南) wrote: > > > Sorry for my late reply, I'm testing the patch on my machine now. > Test will be done in four hours. > > There's something I'm worrying about in the patch, > what I'm worrying about is commented in the code below. > >

Re: [PATCH resend ftrace] Asynchronous grace period for register_ftrace_direct()

2024-05-01 Thread Paul E. McKenney
On Thu, May 02, 2024 at 11:05:01AM +0900, Masami Hiramatsu wrote: > On Wed, 1 May 2024 16:12:37 -0700 > "Paul E. McKenney" wrote: > > > Note that the immediate pressure for this patch should be relieved by the > > NAPI patch series [1], but this sort of problem could easily arise again. > > > >

Re: [PATCH] tracing: Fix uaf issue in tracing_open_file_tr

2024-05-01 Thread 吳澤南
On Mon, 2024-04-29 at 14:46 -0400, Steven Rostedt wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Sun, 28 Apr 2024 20:28:37 -0400 > Steven Rostedt wrote: > > > > Looking for any suggestion or solution,

Re: [PATCH resend ftrace] Asynchronous grace period for register_ftrace_direct()

2024-05-01 Thread Google
On Wed, 1 May 2024 16:12:37 -0700 "Paul E. McKenney" wrote: > Note that the immediate pressure for this patch should be relieved by the > NAPI patch series [1], but this sort of problem could easily arise again. > > When running heavy test workloads with KASAN enabled, RCU Tasks grace > periods

Re: [v3] tracing/probes: Fix memory leak in traceprobe_parse_probe_arg_body()

2024-05-01 Thread Google
On Mon, 29 Apr 2024 15:55:09 +0200 Markus Elfring wrote: > … > > > it jumps to the label 'out' instead of 'fail' by mistake.In the result, > … > > > > Looks good to me. > > * Do you care for a typo in this change description? > > * Would you like to read any improved (patch) version

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

2024-05-01 Thread syzbot
Hello, syzbot has tested the proposed patch and the reproducer did not trigger any issue: Reported-and-tested-by: syzbot+98edc2df894917b34...@syzkaller.appspotmail.com Tested on: commit: f138e94c KASAN: slab-use-after-free Read in vhost_task.. git tree:

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

2024-05-01 Thread Michael S. Tsirkin
On Wed, May 01, 2024 at 10:57:38AM -0500, Mike Christie wrote: > On 5/1/24 2:50 AM, Hillf Danton wrote: > > On Wed, 1 May 2024 02:01:20 -0400 Michael S. Tsirkin > >> > >> and then it failed testing. > >> > > So did my patch [1] but then the reason was spotted [2,3] > > > > [1]

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

2024-05-01 Thread Michael S. Tsirkin
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git f138e94c1f0dbeae721917694fb2203446a68ea9

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

2024-05-01 Thread Michael S. Tsirkin
On Wed, May 01, 2024 at 10:57:38AM -0500, Mike Christie wrote: > On 5/1/24 2:50 AM, Hillf Danton wrote: > > On Wed, 1 May 2024 02:01:20 -0400 Michael S. Tsirkin > >> > >> and then it failed testing. > >> > > So did my patch [1] but then the reason was spotted [2,3] > > > > [1]

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

2024-05-01 Thread Mike Christie
On 5/1/24 2:50 AM, Hillf Danton wrote: > On Wed, 1 May 2024 02:01:20 -0400 Michael S. Tsirkin >> >> and then it failed testing. >> > So did my patch [1] but then the reason was spotted [2,3] > > [1] https://lore.kernel.org/lkml/20240430110209.4310-1-hdan...@sina.com/ > [2]

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

2024-05-01 Thread Michael S. Tsirkin
On Wed, May 01, 2024 at 12:51:51PM +0200, Peter Zijlstra wrote: > On Tue, Apr 30, 2024 at 12:50:05PM +0200, Tobias Huschle wrote: > > 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

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

2024-05-01 Thread Google
On Tue, 30 Apr 2024 14:23:27 -0400 Steven Rostedt wrote: > 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

Re: [PATCH 20/20] [RFC] sh: dma: Remove unused functionality

2024-05-01 Thread John Paul Adrian Glaubitz
gt; int (*configure)(struct dma_channel *chan, unsigned long flags); > > - int (*extend)(struct dma_channel *chan, unsigned long op, void *param); > > }; > > > > struct dma_channel { > > @@ -118,8 +117,6 @@ extern int dma_xfer(unsigned int chan, unsigned lo

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

2024-05-01 Thread Peter Zijlstra
On Tue, Apr 30, 2024 at 12:50:05PM +0200, Tobias Huschle wrote: > 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

Re: [PATCH 00/20] sh: Fix missing prototypes

2024-05-01 Thread John Paul Adrian Glaubitz
; create mode 100644 arch/sh/boot/compressed/cache.h > create mode 100644 arch/sh/boot/compressed/misc.h > For the whole series: Reviewed-by: John Paul Adrian Glaubitz I would still like to get feedback from Yoshinori on patch #20 though, i.e. "sh: dma: Remove unused functionali

Re: [PATCH 20/20] [RFC] sh: dma: Remove unused functionality

2024-05-01 Thread John Paul Adrian Glaubitz
const char *dev_id); > extern int get_dma_residue(unsigned int chan); > extern struct dma_info *get_dma_info(unsigned int chan); > extern struct dma_channel *get_dma_channel(unsigned int chan); > @@ -128,10 +125,6 @@ extern void dma_configure_channel(unsigned int chan, > uns

Re: [PATCH 12/20] sh: dma: Remove unused dmac_search_free_channel()

2024-05-01 Thread John Paul Adrian Glaubitz
Hi Geert, On Fri, 2024-03-01 at 22:02 +0100, Geert Uytterhoeven wrote: > arch/sh/drivers/dma/dma-api.c:164:5: warning: no previous prototype for > 'dmac_search_free_channel' [-Wmissing-prototypes] > > dmac_search_free_channel() never had a user in upstream, remove it. > > Signed-off-by: Geert

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

2024-05-01 Thread Hillf Danton
On Wed, 1 May 2024 02:01:20 -0400 Michael S. Tsirkin > > and then it failed testing. > So did my patch [1] but then the reason was spotted [2,3] [1] https://lore.kernel.org/lkml/20240430110209.4310-1-hdan...@sina.com/ [2] https://lore.kernel.org/lkml/20240430225005.4368-1-hdan...@sina.com/ [3]

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

2024-05-01 Thread Michael S. Tsirkin
On Wed, May 01, 2024 at 08:15:44AM +0800, 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 @@

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 >

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

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(); > >

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
cause it should be a single callback version of > > > kretprobe-multi. > > I ran another benchmark (prctl loop, attached), the origin kernel result is > here; > > # sh ./benchmark.sh > count = 1000, took 6.748133 sec > > And the patched kernel result; > &

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
t; and `MADV_DONTNEED` semantics). Consider this race: > > > > 1. T1 performs page removal in sgx_encl_remove_pages() and stops right > >after removing the page table entry and right before re-acquiring the > >enclave lock to EREMOVE and xa_erase(>page_array) the p

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
t = 1000, took 6.644095 sec I confirmed that the parf result has no big difference. Thank you, > > > > > > > > These numbers are pretty stable and look to be more or less > > > representative. > > > > > > As you can see, kprobes got a bit fa

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 +++-

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

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

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

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

2024-04-29 Thread Dan Williams
Verma, Vishal L wrote: > > > @@ -560,15 +551,12 @@ static ssize_t delete_store(struct device *dev, > > > struct device_attribute *attr, > > >   if (!victim) > > >   return -ENXIO; > > >   > > > - rc = down_write_killable(_region_rwsem); > > > - if (rc) > > > - return rc; > > > -

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

2024-04-29 Thread Beleswar Prasad Padhi
Hello, On 26/04/24 22:39, Mathieu Poirier wrote: Good day, On Wed, Apr 24, 2024 at 06: 35: 03PM +0530, Beleswar Padhi wrote: > From: Apurva Nandan > > PSC controller has a limitation that it can only power-up the second core > when the first core is in ON ZjQcmQRYFpfptBannerStart This message

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

2024-04-29 Thread Verma, Vishal L
On Mon, 2024-04-29 at 18:25 -0700, Dan Williams wrote: > Vishal Verma wrote: > > Commit c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local > > rwsem") > > was a bit overzealous in eliminating device_lock() usage, and ended up > > removing a couple of lock acquisitions which were

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

2024-04-29 Thread Haitao Huang
On Mon, 29 Apr 2024 17:18:05 -0500, Huang, Kai wrote: /* @@ -42,7 +63,8 @@ static inline struct sgx_epc_lru_list *sgx_lru_list(struct sgx_epc_page *epc_pag */ static inline bool sgx_can_reclaim(void) { -return !list_empty(_global_lru.reclaimable); +return

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

2024-04-29 Thread Dan Williams
Vishal Verma wrote: > 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. > > Cc: Dan Williams > Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a

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

2024-04-29 Thread Dan Williams
Vishal Verma wrote: > 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 >

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

2024-04-29 Thread Dan Williams
Vishal Verma wrote: > Commit c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local > rwsem") > was a bit overzealous in eliminating device_lock() usage, and ended up > removing a couple of lock acquisitions which were needed, and as a > result, fix some of the conditional locking

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

2024-04-29 Thread Dan Williams
Vishal Verma wrote: > 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: >

Re: [PATCH v2 0/4] vhost: Cleanup

2024-04-29 Thread Gavin Shan
On 4/30/24 04:50, Michael S. Tsirkin wrote: On Mon, Apr 29, 2024 at 08:13:56PM +1000, Gavin Shan wrote: This is suggested by Michael S. Tsirkin according to [1] and the goal is to apply smp_rmb() inside vhost_get_avail_idx() if needed. With it, the caller of the function needn't to worry about

Re: [PATCH v2 1/4] vhost: Improve vhost_get_avail_idx() with smp_rmb()

2024-04-29 Thread Gavin Shan
On 4/30/24 04:44, Michael S. Tsirkin wrote: On Mon, Apr 29, 2024 at 08:13:57PM +1000, Gavin Shan wrote: From: "Michael S. Tsirkin" All the callers of vhost_get_avail_idx() are concerned to the memory *with* the memory barrier Thanks, will be corrected in v3. barrier, imposed by

Re: [PATCH v2 2/4] vhost: Drop variable last_avail_idx in vhost_get_vq_desc()

2024-04-29 Thread Gavin Shan
On 4/30/24 04:45, Michael S. Tsirkin wrote: On Mon, Apr 29, 2024 at 08:13:58PM +1000, Gavin Shan wrote: The local variable @last_avail_idx is equivalent to vq->last_avail_idx. So the code can be simplified a bit by dropping the local variable @last_avail_idx. No functional change intended.

Re: [PATCH RFC] rethook: inline arch_rethook_trampoline_callback() in assembly code

2024-04-29 Thread Andrii Nakryiko
On Wed, Apr 24, 2024 at 5:02 PM Andrii Nakryiko wrote: > > At the lowest level, rethook-based kretprobes on x86-64 architecture go > through arch_rethoook_trampoline() function, manually written in > assembly, which calls into a simple arch_rethook_trampoline_callback() > function, written in C,

Re: [PATCH bpf-next] bpf: add support to read cpu_entry in bpf program

2024-04-29 Thread Yonghong Song
On 4/27/24 8:18 AM, Florian Lehner wrote: Add new field "cpu_entry" to bpf_perf_event_data which could be read by bpf programs attached to perf events. The value contains the CPU value recorded by specifying sample_type with PERF_SAMPLE_CPU when calling perf_event_open(). You can use

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

2024-04-29 Thread Huang, Kai
 /* @@ -42,7 +63,8 @@ static inline struct sgx_epc_lru_list *sgx_lru_list(struct sgx_epc_page *epc_pag   */  static inline bool sgx_can_reclaim(void)  { -    return !list_empty(_global_lru.reclaimable); +    return !sgx_cgroup_lru_empty(misc_cg_root()) || +  

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

2024-04-29 Thread Andrii Nakryiko
this. > > > > > As you can see, kprobes got a bit faster, kprobe-multi seems to be > > about the same, though. > > > > Then (I suppose they are "legacy") kretprobes got quite noticeably > > slower, almost by 10%. Not sure why, but looks real after r

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

2024-04-29 Thread Andrii Nakryiko
pretty stable and look to be more or less representative. > > > > As you can see, kprobes got a bit faster, kprobe-multi seems to be > > about the same, though. > > > > Then (I suppose they are "legacy") kretprobes got quite noticeably > > slower, almost by

Re: [PATCH v2 0/4] vhost: Cleanup

2024-04-29 Thread Michael S. Tsirkin
On Mon, Apr 29, 2024 at 08:13:56PM +1000, Gavin Shan wrote: > This is suggested by Michael S. Tsirkin according to [1] and the goal > is to apply smp_rmb() inside vhost_get_avail_idx() if needed. With it, > the caller of the function needn't to worry about memory barriers. Since > we're here,

Re: [PATCH v2 4/4] vhost: Reformat vhost_{get, put}_user()

2024-04-29 Thread Michael S. Tsirkin
On Mon, Apr 29, 2024 at 08:14:00PM +1000, Gavin Shan wrote: > Reformat the macros to use tab as the terminator for each line so > that it looks clean. > > No functional change intended. > > Signed-off-by: Gavin Shan Just messes up history for no real gain. > --- > drivers/vhost/vhost.c | 60

Re: [PATCH v2 3/4] vhost: Improve vhost_get_avail_head()

2024-04-29 Thread Michael S. Tsirkin
On Mon, Apr 29, 2024 at 08:13:59PM +1000, Gavin Shan wrote: > Improve vhost_get_avail_head() so that the head or errno is returned. > With it, the relevant sanity checks are squeezed to vhost_get_avail_head() > and vhost_get_vq_desc() is further simplified. > > No functional change intended. > >

Re: [PATCH v2 2/4] vhost: Drop variable last_avail_idx in vhost_get_vq_desc()

2024-04-29 Thread Michael S. Tsirkin
On Mon, Apr 29, 2024 at 08:13:58PM +1000, Gavin Shan wrote: > The local variable @last_avail_idx is equivalent to vq->last_avail_idx. > So the code can be simplified a bit by dropping the local variable > @last_avail_idx. > > No functional change intended. > > Signed-off-by: Gavin Shan > --- >

Re: [PATCH] tracing: Fix uaf issue in tracing_open_file_tr

2024-04-29 Thread Steven Rostedt
On Sun, 28 Apr 2024 20:28:37 -0400 Steven Rostedt wrote: > > Looking for any suggestion or solution, appreciate. > > Yeah, I do not think eventfs should be involved in this. It needs to be > protected at a higher level (in the synthetic/dynamic event code). > > I'm just coming back from

Re: [PATCH v2 1/4] vhost: Improve vhost_get_avail_idx() with smp_rmb()

2024-04-29 Thread Michael S. Tsirkin
On Mon, Apr 29, 2024 at 08:13:57PM +1000, Gavin Shan wrote: > From: "Michael S. Tsirkin" > > All the callers of vhost_get_avail_idx() are concerned to the memory *with* the memory barrier > barrier, imposed by smp_rmb() to ensure the order of the available > ring entry read and avail_idx read.

Re: [syzbot] [bpf?] [trace?] WARNING in group_send_sig_info

2024-04-29 Thread Yonghong Song
On 4/27/24 9:34 AM, syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:443574b03387 riscv, bpf: Fix kfunc parameters incompatibil.. git tree: bpf console output: https://syzkaller.appspot.com/x/log.txt?x=11ca8fe718 kernel config:

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

2024-04-29 Thread Haitao Huang
On Mon, 29 Apr 2024 11:43:05 -0500, Jarkko Sakkinen wrote: On Mon Apr 29, 2024 at 7:18 PM EEST, Haitao Huang wrote: Hi Jarkko On Sun, 28 Apr 2024 17:03:17 -0500, Jarkko Sakkinen wrote: > On Fri Apr 26, 2024 at 5:28 PM EEST, Dave Hansen wrote: >> On 4/16/24 07:15, Jarkko Sakkinen wrote:

Re: [PATCHv3 bpf-next 6/7] selftests/bpf: Add uretprobe compat test

2024-04-29 Thread Andrii Nakryiko
On Mon, Apr 29, 2024 at 12:39 AM Jiri Olsa wrote: > > On Fri, Apr 26, 2024 at 11:06:53AM -0700, Andrii Nakryiko wrote: > > On Sun, Apr 21, 2024 at 12:43 PM Jiri Olsa wrote: > > > > > > Adding test that adds return uprobe inside 32 bit task > > > and verify the return uprobe and attached bpf

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

2024-04-29 Thread Jarkko Sakkinen
On Mon Apr 29, 2024 at 7:18 PM EEST, Haitao Huang wrote: > Hi Jarkko > > On Sun, 28 Apr 2024 17:03:17 -0500, Jarkko Sakkinen > wrote: > > > On Fri Apr 26, 2024 at 5:28 PM EEST, Dave Hansen wrote: > >> On 4/16/24 07:15, Jarkko Sakkinen wrote: > >> > On Tue Apr 16, 2024 at 8:42 AM EEST, Huang,

Re: [PATCHv3 bpf-next 5/7] selftests/bpf: Add uretprobe syscall call from user space test

2024-04-29 Thread Andrii Nakryiko
On Mon, Apr 29, 2024 at 12:33 AM Jiri Olsa wrote: > > On Fri, Apr 26, 2024 at 11:03:29AM -0700, Andrii Nakryiko wrote: > > On Sun, Apr 21, 2024 at 12:43 PM Jiri Olsa wrote: > > > > > > Adding test to verify that when called from outside of the > > > trampoline provided by kernel, the uretprobe

Re: [PATCH v7 00/16] mm: jit/text allocator

2024-04-29 Thread Luis Chamberlain
On Mon, Apr 29, 2024 at 03:16:04PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Hi, > > The patches are also available in git: > https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=execmem/v7 > > v7 changes: > * define MODULE_{VADDR,END} for riscv32 to fix

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

2024-04-29 Thread Haitao Huang
Hi Jarkko On Sun, 28 Apr 2024 17:03:17 -0500, Jarkko Sakkinen wrote: On Fri Apr 26, 2024 at 5:28 PM EEST, Dave Hansen wrote: On 4/16/24 07:15, Jarkko Sakkinen wrote: > On Tue Apr 16, 2024 at 8:42 AM EEST, Huang, Kai wrote: > Yes, exactly. I'd take one week break and cycle the kselftest

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

2024-04-29 Thread Haitao Huang
On Mon, 29 Apr 2024 05:49:13 -0500, Huang, Kai wrote: +/* + * Get the per-cgroup or global LRU list that tracks the given reclaimable page. + */ static inline struct sgx_epc_lru_list *sgx_lru_list(struct sgx_epc_page *epc_page) { +#ifdef CONFIG_CGROUP_MISC + /* +*

Re: [PATCH 1/2] dt-bindings: remoteproc: qcom,smd-edge: Mark qcom,ipc as deprecated

2024-04-29 Thread Rob Herring
On Thu, 25 Apr 2024 21:14:30 +0200, Luca Weiss wrote: > Deprecate the qcom,ipc way of accessing the mailbox in favor of the > 'mboxes' property. > > Update the example to use mboxes. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml | 3 ++-

Re: [PATCH 2/2] dt-bindings: soc: qcom,smp2p: Mark qcom,ipc as deprecated

2024-04-29 Thread Rob Herring
On Thu, 25 Apr 2024 21:14:31 +0200, Luca Weiss wrote: > Deprecate the qcom,ipc way of accessing the mailbox in favor of the > 'mboxes' property. > > Update the example to use mboxes. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml | 3 ++- > 1

Re: [PATCH v9 29/36] bpf: Enable kprobe_multi feature if CONFIG_FPROBE is enabled

2024-04-29 Thread Google
On Thu, 25 Apr 2024 13:09:32 -0700 Andrii Nakryiko wrote: > On Mon, Apr 15, 2024 at 6:22 AM Masami Hiramatsu (Google) > wrote: > > > > From: Masami Hiramatsu (Google) > > > > Enable kprobe_multi feature if CONFIG_FPROBE is enabled. The pt_regs is > > converted from ftrace_regs by

Re: [PATCH v9 36/36] fgraph: Skip recording calltime/rettime if it is not nneeded

2024-04-29 Thread Google
On Thu, 25 Apr 2024 13:15:08 -0700 Andrii Nakryiko wrote: > On Mon, Apr 15, 2024 at 6:25 AM Masami Hiramatsu (Google) > wrote: > > > > From: Masami Hiramatsu (Google) > > > > Skip recording calltime and rettime if the fgraph_ops does not need it. > > This is a kind of performance optimization

Re: 回复:WARNING in current_check_refer_path

2024-04-29 Thread Mickaël Salaün
On Mon, Apr 29, 2024 at 05:16:57PM +0800, Ubisectech Sirius wrote: > > Hello, > > > Thanks for the report. Could you please provide a reproducer? > > > Regards, > > Mickaël > > Hi. > The Poc file has seed to you as attachment. Indeed, but could you please trim down the file. There are 650

Re: [v3] tracing/probes: Fix memory leak in traceprobe_parse_probe_arg_body()

2024-04-29 Thread Markus Elfring
… > > it jumps to the label 'out' instead of 'fail' by mistake.In the result, … > > Looks good to me. * Do you care for a typo in this change description? * Would you like to read any improved (patch) version descriptions (or changelogs)? Regards, Markus

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

2024-04-29 Thread Google
to be > about the same, though. > > Then (I suppose they are "legacy") kretprobes got quite noticeably > slower, almost by 10%. Not sure why, but looks real after re-running > benchmarks a bunch of times and getting stable results. Hmm, kretprobe on x86 should use ftrac

Re: [PATCH v3] tracing/probes: Fix memory leak in traceprobe_parse_probe_arg_body()

2024-04-29 Thread Google
Hi LuMing, On Sat, 27 Apr 2024 08:23:47 +0100 lumingyindet...@126.com wrote: > From: LuMingYin > > If traceprobe_parse_probe_arg_body() failed to allocate 'parg->fmt', > it jumps to the label 'out' instead of 'fail' by mistake.In the result, > the buffer 'tmp' is not freed in this case and

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

2024-04-29 Thread Jarkko Sakkinen
ms page removal in sgx_encl_remove_pages() and stops right >after removing the page table entry and right before re-acquiring the >enclave lock to EREMOVE and xa_erase(>page_array) the page. > 2. T2 tries to access the page, and #PF[not_present] is raised. The >cond

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

2024-04-29 Thread Jarkko Sakkinen
On Mon Apr 29, 2024 at 4:22 PM EEST, Jarkko Sakkinen wrote: > On Mon Apr 29, 2024 at 4:04 PM EEST, Jarkko Sakkinen wrote: > > > Fix these two bugs (1) by returning VM_FAULT_NOPAGE to the generic Linux > > > fault handler so that no signal is sent to userspace, and (2) by > > > replacing

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

2024-04-29 Thread Jarkko Sakkinen
On Mon Apr 29, 2024 at 4:04 PM EEST, Jarkko Sakkinen wrote: > > Fix these two bugs (1) by returning VM_FAULT_NOPAGE to the generic Linux > > fault handler so that no signal is sent to userspace, and (2) by > > replacing sgx_encl_free_epc_page() with sgx_free_epc_page() so that no > > EREMOVE is

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

2024-04-29 Thread Jarkko Sakkinen
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 #PF-based page allocation, and the latter implies the usage of >

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

2024-04-29 Thread Jarkko Sakkinen
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 end up in sgx_encl_eaug_page(), racing to acquire the > enclave lock. The

Re: [PATCH 5.15,5.10,5.4,4.19 0/2] Fix warning when tracing with large filenames

2024-04-29 Thread Greg KH
On Wed, Apr 24, 2024 at 07:20:07PM -0300, Thadeu Lima de Souza Cascardo wrote: > The warning described on patch "tracing: Increase PERF_MAX_TRACE_SIZE to > handle Sentinel1 and docker together" can be triggered with a perf probe on > do_execve with a large path. As PATH_MAX is larger than

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

2024-04-29 Thread Huang, Kai
> +/* > + * Get the per-cgroup or global LRU list that tracks the given reclaimable > page. > + */ > static inline struct sgx_epc_lru_list *sgx_lru_list(struct sgx_epc_page > *epc_page) > { > +#ifdef CONFIG_CGROUP_MISC > + /* > + * epc_page->sgx_cg here is never NULL during a

<    5   6   7   8   9   10   11   12   13   14   >