Re: [PATCH net-next v3 2/2] ipvs: allow some sysctls in non-init user namespaces

2024-05-03 Thread Julian Anastasov
Hello, On Thu, 18 Apr 2024, Alexander Mikhalitsyn wrote: > Let's make all IPVS sysctls writtable even when > network namespace is owned by non-initial user namespace. > > Let's make a few sysctls to be read-only for non-privileged users: > - sync_qlen_max > - sync_sock_size > -

Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-05-03 Thread Waiman Long
On 12/31/23 23:14, Waiman Long wrote: On 12/31/23 16:55, David Laight wrote: per_cpu_ptr() indexes __per_cpu_offset[] with the cpu number. This requires the cpu number be 64bit. However the value is osq_lock() comes from a 32bit xchg() and there isn't a way of telling gcc the high bits are

Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe

2024-05-03 Thread Jiri Olsa
On Fri, May 03, 2024 at 01:34:53PM +0200, Peter Zijlstra wrote: > On Thu, May 02, 2024 at 02:23:08PM +0200, Jiri Olsa wrote: > > Adding uretprobe syscall instead of trap to speed up return probe. > > > > At the moment the uretprobe setup/path is: > > > > - install entry uprobe > > > > -

RE: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-05-03 Thread David Laight
From: Waiman Long > Sent: 03 May 2024 17:00 > To: David Laight ; 'linux-kernel@vger.kernel.org' > ker...@vger.kernel.org>; 'pet...@infradead.org' > Cc: 'mi...@redhat.com' ; 'w...@kernel.org' > ; 'boqun.f...@gmail.com' > ; 'Linus Torvalds' ; > 'virtualization@lists.linux- > foundation.org' ;

Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe

2024-05-03 Thread Peter Zijlstra
On Thu, May 02, 2024 at 02:23:08PM +0200, Jiri Olsa wrote: > Adding uretprobe syscall instead of trap to speed up return probe. > > At the moment the uretprobe setup/path is: > > - install entry uprobe > > - when the uprobe is hit, it overwrites probed function's return address > on

Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe

2024-05-03 Thread Edgecombe, Rick P
On Fri, 2024-05-03 at 15:04 +0200, Jiri Olsa wrote: > On Fri, May 03, 2024 at 01:34:53PM +0200, Peter Zijlstra wrote: > > On Thu, May 02, 2024 at 02:23:08PM +0200, Jiri Olsa wrote: > > > Adding uretprobe syscall instead of trap to speed up return probe. > > > > > > At the moment the uretprobe

Re: [PATCHv4 bpf-next 0/7] uprobe: uretprobe speed up

2024-05-03 Thread Jiri Olsa
On Fri, May 03, 2024 at 11:03:24AM -0700, Andrii Nakryiko wrote: > On Thu, May 2, 2024 at 1:04 PM Jiri Olsa wrote: > > > > On Thu, May 02, 2024 at 09:43:02AM -0700, Andrii Nakryiko wrote: > > > On Thu, May 2, 2024 at 5:23 AM Jiri Olsa wrote: > > > > > > > > hi, > > > > as part of the effort on

Re: [PATCHv4 bpf-next 0/7] uprobe: uretprobe speed up

2024-05-03 Thread Andrii Nakryiko
On Thu, May 2, 2024 at 1:04 PM Jiri Olsa wrote: > > On Thu, May 02, 2024 at 09:43:02AM -0700, Andrii Nakryiko wrote: > > On Thu, May 2, 2024 at 5:23 AM Jiri Olsa wrote: > > > > > > hi, > > > as part of the effort on speeding up the uprobes [0] coming with > > > return uprobe optimization by

[REGRESSION][v6.8-rc1] virtio-pci: Introduce admin virtqueue

2024-05-03 Thread Joseph Salisbury
Hi Feng, During testing, a kernel bug was identified with the suspend/resume functionality on instances running in a public cloud [0].  This bug is a regression introduced in v6.8-rc1.  After a kernel bisect, the following commit was identified as the cause of the regression:   

Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe

2024-05-03 Thread Edgecombe, Rick P
+Some more shadow stack folks from other archs. We are discussing how uretprobes work with shadow stack. Context: https://lore.kernel.org/lkml/ZjU4ganRF1Cbiug6@krava/ On Fri, 2024-05-03 at 21:18 +0200, Jiri Olsa wrote: > > hack below seems to fix it for the current uprobe setup, > we need

Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe

2024-05-03 Thread Edgecombe, Rick P
On Fri, 2024-05-03 at 22:17 +0200, Jiri Olsa wrote: > when uretprobe is created, kernel overwrites the return address on user > stack to point to user space trampoline, so the setup is in kernel hands I mean for uprobes in general. I'm didn't have any specific ideas in mind, but in general when

Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-05-03 Thread Waiman Long
On 5/3/24 17:10, David Laight wrote: From: Waiman Long Sent: 03 May 2024 17:00 ... David, Could you respin the series based on the latest upstream code? I've just reapplied the patches to 'master' and they all apply cleanly and diffing the new patches to the old ones gives no differences.

Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe

2024-05-03 Thread Jiri Olsa
On Fri, May 03, 2024 at 07:38:18PM +, Edgecombe, Rick P wrote: > +Some more shadow stack folks from other archs. We are discussing how > uretprobes > work with shadow stack. > > Context: > https://lore.kernel.org/lkml/ZjU4ganRF1Cbiug6@krava/ > > On Fri, 2024-05-03 at 21:18 +0200, Jiri Olsa

RE: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-05-03 Thread David Laight
From: Waiman Long > Sent: 03 May 2024 17:00 ... > David, > > Could you respin the series based on the latest upstream code? I've just reapplied the patches to 'master' and they all apply cleanly and diffing the new patches to the old ones gives no differences. So I think they should still apply.

Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe

2024-05-03 Thread Jiri Olsa
On Fri, May 03, 2024 at 03:53:15PM +, Edgecombe, Rick P wrote: > On Fri, 2024-05-03 at 15:04 +0200, Jiri Olsa wrote: > > On Fri, May 03, 2024 at 01:34:53PM +0200, Peter Zijlstra wrote: > > > On Thu, May 02, 2024 at 02:23:08PM +0200, Jiri Olsa wrote: > > > > Adding uretprobe syscall instead of

Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe

2024-05-03 Thread Deepak Gupta
On Fri, May 03, 2024 at 07:38:18PM +, Edgecombe, Rick P wrote: +Some more shadow stack folks from other archs. We are discussing how uretprobes work with shadow stack. Context: https://lore.kernel.org/lkml/ZjU4ganRF1Cbiug6@krava/ Thanks Rick. Yeah I didn't give enough attention to

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

2024-05-03 Thread Mike Rapoport
On Fri, May 03, 2024 at 01:23:30AM +0100, Liviu Dudau wrote: > On Thu, May 02, 2024 at 04:07:05PM -0700, Luis Chamberlain wrote: > > On Thu, May 02, 2024 at 11:50:36PM +0100, Liviu Dudau wrote: > > > On Mon, Apr 29, 2024 at 09:29:20AM -0700, Luis Chamberlain wrote: > > > > On Mon, Apr 29, 2024 at

[PATCH v10] remoteproc: qcom: Move minidump related layout and API to soc/qcom directory

2024-05-03 Thread Mukesh Ojha
Currently, Qualcomm Minidump is being used to collect mini version of remoteproc coredump with the help of boot firmware however, Minidump as a feature is not limited to be used only for remote processor and can also be used for Application processors. So, in preparation of using it move the

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

2024-05-03 Thread Mukesh Ojha
On 4/30/2024 7:08 PM, Bjorn Andersson wrote: 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

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

2024-05-03 Thread Liviu Dudau
On Fri, May 03, 2024 at 09:28:25AM +0300, Mike Rapoport wrote: > On Fri, May 03, 2024 at 01:23:30AM +0100, Liviu Dudau wrote: > > On Thu, May 02, 2024 at 04:07:05PM -0700, Luis Chamberlain wrote: > > > On Thu, May 02, 2024 at 11:50:36PM +0100, Liviu Dudau wrote: > > > > On Mon, Apr 29, 2024 at