On Tue, Apr 2, 2024 at 11:21 PM Michael S. Tsirkin wrote:
>
> VDPA_GET_VRING_SIZE by mistake uses the already occupied
> ioctl # 0x80 and we never noticed - it happens to work
> because the direction and size are different, but confuses
> tools such as perf which like to look at just the number,
On Tue, Apr 02, 2024 at 05:21:39PM -0400, Michael S. Tsirkin wrote:
VDPA_GET_VRING_SIZE by mistake uses the already occupied
ioctl # 0x80 and we never noticed - it happens to work
because the direction and size are different, but confuses
tools such as perf which like to look at just the number,
On Wed, 2024-03-27 at 17:22 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> When a cgroup usage reaches its limit, and it is to be charged, i.e.,
> sgx_cgroup_try_charge() called for new allocations, the cgroup needs to
> reclaim pages from its LRU or LRUs of its descendants to
On Tue, 02 Apr 2024 22:55:36 +0200, Duje Mihanović wrote:
> Hello,
>
> This series adds initial support for the Marvell PXA1908 SoC and
> "samsung,coreprimevelte", a smartphone using the SoC.
>
> USB works and the phone can boot a rootfs from an SD card, but there are
> some warnings in the
On Wed, 3 Apr 2024 11:47:41 +0200
Jiri Olsa wrote:
> On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> > Hi Jiri,
> >
> > On Tue, 2 Apr 2024 11:33:00 +0200
> > Jiri Olsa wrote:
> >
> > > Adding uretprobe syscall instead of trap to speed up return probe.
> >
> > This is
On 4/2/24 6:58 PM, Andrii Nakryiko wrote:
On Mon, Apr 1, 2024 at 12:16 PM Kui-Feng Lee wrote:
rethook_find_ret_addr() prints a warning message and returns 0 when the
target task is running and not the "current" task to prevent returning an
incorrect return address. However, this check is
Again, I leave this to you and Jiri, but
On 04/03, Masami Hiramatsu wrote:
>
> On Wed, 3 Apr 2024 11:47:41 +0200
> > > set in the user function, what happen if the user function directly
> > > calls this syscall? (maybe it consumes shadow stack?)
> >
> > the process should receive SIGILL if
On Sun, Mar 31, 2024 at 04:20:30PM -0400, Michael S. Tsirkin wrote:
> On Fri, Mar 29, 2024 at 10:16:41AM -0700, Breno Leitao wrote:
> > @@ -3814,13 +3815,24 @@ static int virtnet_set_rxfh(struct net_device *dev,
> > return -EOPNOTSUPP;
> >
> > if (rxfh->indir) {
> > +
On Tue, 2 Apr 2024 22:21:00 -0700
Andrii Nakryiko wrote:
> > I just checked our fleet-wide production data for the last 24 hours.
> > Within the kprobe/kretprobe code path (ftrace_trampoline and
> > everything called from it), rcu_is_watching (both calls, see below)
> > cause 0.484% CPU cycles
I leave this to you and Masami, but...
On 04/03, Jiri Olsa wrote:
>
> On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> >
> > This is interesting approach. But I doubt we need to add additional
> > syscall just for this purpose. Can't we use another syscall or ioctl?
>
> so the
On Tue, 2 Apr 2024 21:00:19 -0700
Andrii Nakryiko wrote:
> I just noticed another rcu_is_watching() call, in rethook_try_get(),
> which seems to be a similar and complementary validation check to the
> one we are putting under CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING option
> in this patch. It
On Tue Apr 2, 2024 at 6:42 PM EEST, Dave Hansen wrote:
> On 3/30/24 04:23, Jarkko Sakkinen wrote:
> >>> I also wonder is cgroup-tools dependency absolutely required or could
> >>> you just have a function that would interact with sysfs?
> >> I should have checked email before hit the send button
On Fri, 29 Mar 2024 14:40:55 -0400
Steven Rostedt wrote:
> > +static vm_fault_t tracing_buffers_mmap_fault(struct vm_fault *vmf)
> > +{
> > + return VM_FAULT_SIGBUS;
> > +}
>
> If this is all it does, I don't believe it's needed.
>
> > +
> > +#ifdef CONFIG_TRACER_MAX_TRACE
> > +static int
On Wed, Apr 03, 2024 at 10:13:52AM -0400, Steven Rostedt wrote:
> On Fri, 29 Mar 2024 14:40:55 -0400
> Steven Rostedt wrote:
>
> > > +static vm_fault_t tracing_buffers_mmap_fault(struct vm_fault *vmf)
> > > +{
> > > + return VM_FAULT_SIGBUS;
> > > +}
> >
> > If this is all it does, I don't
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1)
From: Jason Xing
Adjust the paramenter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
---
include/net/request_sock.h | 3 ++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
---
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
---
include/net/tcp.h | 2 +-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 2 +-
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we don't need to implement those duplicated reset reasons.
This patch replaces all the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/ipv4/tcp_ipv4.c | 8
net/ipv6/tcp_ipv6.c | 8
From: Jason Xing
It relys on what reset options in MPTCP does as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces all the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/subflow.c | 26 --
1 file changed, 20
On 4/1/24 17:46, Mathieu Poirier wrote:
> On Fri, Mar 29, 2024 at 11:57:43AM +0100, Arnaud POULIQUEN wrote:
>>
>>
>> On 3/27/24 18:14, Mathieu Poirier wrote:
>>> On Tue, Mar 26, 2024 at 08:31:33PM +0100, Arnaud POULIQUEN wrote:
On 3/25/24 17:51, Mathieu Poirier wrote:
> On
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset()).
On 4/3/2024 5:21 AM, Michael S. Tsirkin wrote:
VDPA_GET_VRING_SIZE by mistake uses the already occupied
ioctl # 0x80 and we never noticed - it happens to work
because the direction and size are different, but confuses
tools such as perf which like to look at just the number,
and breaks the
On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> Hi Jiri,
>
> On Tue, 2 Apr 2024 11:33:00 +0200
> Jiri Olsa wrote:
>
> > Adding uretprobe syscall instead of trap to speed up return probe.
>
> This is interesting approach. But I doubt we need to add additional
> syscall just
> > > > Given the discussion around per-cpu rw semaphore and need for
> > > > (internal) batched attachment API for uprobes, do you think you can
> > > > apply this patch as is for now? We can then gain initial improvements
> > > > in scalability that are also easy to backport, and Jonathan will
在 2024/4/1 上午4:20, Michael S. Tsirkin 写道:
On Fri, Mar 29, 2024 at 10:16:41AM -0700, Breno Leitao wrote:
There is a bug when setting the RSS options in virtio_net that can break
the whole machine, getting the kernel into an infinite loop.
Running the following command in any QEMU virtual
From: Arnd Bergmann
When CONFIG_PERF_EVENTS, a 'make W=1' build produces a warning about the
unused ftrace_event_id_fops variable:
kernel/trace/trace_events.c:2155:37: error: 'ftrace_event_id_fops' defined but
not used [-Werror=unused-const-variable=]
2155 | static const struct
On Wed, 3 Apr 2024 11:53:14 -0700
"Paul E. McKenney" wrote:
> @@ -5366,6 +5366,13 @@ static void remove_direct_functions_hash(struct
> ftrace_hash *hash, unsigned long
> }
> }
>
> +static void register_ftrace_direct_cb(struct rcu_head *rhp)
> +{
> + struct ftrace_hash *fhp =
On 4/3/24 10:57, Ondřej Jirman wrote:
> Hi Sakari and Luis,
>
> On Wed, Apr 03, 2024 at 04:25:41PM GMT, Sakari Ailus wrote:
>> Hi Luis, Ondrej,
>>
>> On Wed, Apr 03, 2024 at 09:03:52AM -0600, g...@luigi311.com wrote:
>>> From: Luis Garcia
>>>
>>> On some boards powerdown signal needs to be
Kui-Feng Lee wrote:
> rethook_find_ret_addr() prints a warning message and returns 0 when the
> target task is running and not the "current" task to prevent returning an
> incorrect return address. However, this check is incomplete as the target
> task can still transition to the running state
On 4/3/24 12:49, Pavel Machek wrote:
> Hi!
>
>> From: Luis Garcia
>>
>> Add powerdown-gpio binding as it is required for some boards
>
> "." at end of sentence.
>
>> Signed-off-by: Ondrej Jirman
>> Signed-off-by: Luis Garcia
>
> If the patch is from Ondrej, he should be in From:, I believe.
On 4/3/24 11:03, Ondřej Jirman wrote:
> Hi,
>
> On Wed, Apr 03, 2024 at 04:28:59PM GMT, Sakari Ailus wrote:
>> Hi Luis,
>>
>> Could you unify the subject prefix for the driver patches, please? E.g.
>> "media: imx258: " would be fine.
>>
>> On Wed, Apr 03, 2024 at 09:03:53AM -0600,
On Wed, 3 Apr 2024 12:16:28 -0700
"Paul E. McKenney" wrote:
> commit 717c7c894d4b ("fs/proc: Add boot loader arguments as comment to
> /proc/bootconfig") adds bootloader argument comments into /proc/bootconfig.
>
> /proc/bootconfig shows boot_command_line[] multiple times following
> every xbc
commit 717c7c894d4b ("fs/proc: Add boot loader arguments as comment to
/proc/bootconfig") adds bootloader argument comments into /proc/bootconfig.
/proc/bootconfig shows boot_command_line[] multiple times following
every xbc key value pair, that's duplicated and not necessary.
Remove redundant
On 4/3/24 10:23, Sakari Ailus wrote:
> Hi Luis,
>
> On Wed, Apr 03, 2024 at 09:03:50AM -0600, g...@luigi311.com wrote:
>> From: Luis Garcia
>>
>> Use understandable macros instead of raw values.
>>
>> Signed-off-by: Ondrej Jirman
>> Signed-off-by: Luis Garcia
>> ---
>>
Introduce CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING config option to
control whether ftrace low-level code performs additional
rcu_is_watching()-based validation logic in an attempt to catch noinstr
violations.
This check is expected to never be true and is mostly useful for
low-level validation of
Take into account CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING when validating
that RCU is watching when trying to setup rethooko on a function entry.
This further (in addition to improvements in the previous patch)
improves BPF multi-kretprobe (which rely on rethook) runtime throughput
by 2.3%,
On Wed, Apr 03, 2024 at 03:29:12PM -0400, Steven Rostedt wrote:
> On Wed, 3 Apr 2024 11:53:14 -0700
> "Paul E. McKenney" wrote:
>
> > @@ -5366,6 +5366,13 @@ static void remove_direct_functions_hash(struct
> > ftrace_hash *hash, unsigned long
> > }
> > }
> >
> > +static void
On Tue, Apr 02, 2024 at 02:14:58PM +0800, Ubisectech Sirius wrote:
> > On Tue, Apr 02, 2024 at 09:50:54AM +0800, Ubisectech Sirius wrote:
> >>> On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> >>> Hello.
> >>> We are Ubisectech Sirius Team, the vulnerability lab of China
Hi Jonathan,
Thanks for your feedback. I will fix them (inlined) in the next V11.
No worries, it's never too late!
On Wed, Apr 3, 2024 at 9:52 AM Jonathan Cameron
wrote:
>
> On Tue, 2 Apr 2024 00:17:37 +
> "Ho-Ren (Jack) Chuang" wrote:
>
> > Since different memory devices require finding,
On Wed, 3 Apr 2024 15:39:44 +0100
Vincent Donnefort wrote:
> > Do you plan on sending out a v20 series?
>
> Of course, let me spin that this week! Got also few typos to fix in the doc
> and
> I believe an include missing for riscv.
No rush, I'll be on PTO until next Tuesday, and will not
A few minor comments inline.
> diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h
> index a44c03c2ba3a..16769552a338 100644
> --- a/include/linux/memory-tiers.h
> +++ b/include/linux/memory-tiers.h
> @@ -140,12 +140,13 @@ static inline int mt_perf_to_adistance(struct
>
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.
So would this change make sense?
When running heavy test workloads with KASAN enabled, RCU Tasks grace
periods can extend for many tens of seconds,
There is a bug when setting the RSS options in virtio_net that can break
the whole machine, getting the kernel into an infinite loop.
Running the following command in any QEMU virtual machine with virtionet
will reproduce this problem:
# ethtool -X eth0 hfunc toeplitz
This is how the
On Tue Apr 2, 2024 at 8:40 PM EEST, Michal Koutný wrote:
> On Tue, Apr 02, 2024 at 11:20:21AM -0500, Haitao Huang
> wrote:
> > Do we really want to have it implemented in c?
>
> I only pointed to the available C boilerplate.
>
> > There are much fewer lines of
> > code in shell scripts. Note we
On Tue Apr 2, 2024 at 7:20 PM EEST, Haitao Huang wrote:
> On Tue, 02 Apr 2024 06:58:40 -0500, Jarkko Sakkinen
> wrote:
>
> > On Tue Apr 2, 2024 at 2:23 PM EEST, Michal Koutný wrote:
> >> Hello.
> >>
> >> On Sat, Mar 30, 2024 at 01:26:08PM +0200, Jarkko Sakkinen
> >> wrote:
> >> > > > It'd be
On Tue Apr 2, 2024 at 8:31 PM EEST, Haitao Huang wrote:
> On Tue, 02 Apr 2024 02:43:25 -0500, Jarkko Sakkinen
> wrote:
>
> > On Tue Apr 2, 2024 at 4:42 AM EEST, Haitao Huang wrote:
> >> Make cgroup test scripts ash compatible.
> >> Remove cg-tools dependency.
> >> Add documentation for
On Wed, Apr 3, 2024 at 4:05 AM Jonthan Haslam wrote:
>
> > > > > Given the discussion around per-cpu rw semaphore and need for
> > > > > (internal) batched attachment API for uprobes, do you think you can
> > > > > apply this patch as is for now? We can then gain initial improvements
> > > > > in
On Tue, 2 Apr 2024 00:17:37 +
"Ho-Ren (Jack) Chuang" wrote:
> Since different memory devices require finding, allocating, and putting
> memory types, these common steps are abstracted in this patch,
> enhancing the scalability and conciseness of the code.
>
> Signed-off-by: Ho-Ren (Jack)
On Wed, Apr 3, 2024 at 7:09 AM Masami Hiramatsu wrote:
>
> On Wed, 3 Apr 2024 11:47:41 +0200
> Jiri Olsa wrote:
>
> > On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> > > Hi Jiri,
> > >
> > > On Tue, 2 Apr 2024 11:33:00 +0200
> > > Jiri Olsa wrote:
> > >
> > > > Adding
On Wed, 3 Apr 2024 15:31:38 +0800 Jason Xing wrote:
> It's based on top of
> https://patchwork.kernel.org/project/netdevbpf/list/?series=840182
Please post as RFC if there's a dependency.
We don't maintain patch queues for people.
--
pw-bot: cr
On Wed, Apr 3, 2024 at 5:58 PM Masami Hiramatsu wrote:
>
> On Wed, 3 Apr 2024 09:58:12 -0700
> Andrii Nakryiko wrote:
>
> > On Wed, Apr 3, 2024 at 7:09 AM Masami Hiramatsu wrote:
> > >
> > > On Wed, 3 Apr 2024 11:47:41 +0200
> > > Jiri Olsa wrote:
> > >
> > > > On Wed, Apr 03, 2024 at
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(_write)().
>
> Replace those, and additionally, replace a couple of other
> WARN_ON_ONCE() introduced in the same patch for actual failure
>
Hi Jonathan,
Thank you for your feedback. I will fix them (inlined) in the next V11.
On Wed, Apr 3, 2024 at 10:04 AM Jonathan Cameron
wrote:
>
> A few minor comments inline.
>
> > diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h
> > index a44c03c2ba3a..16769552a338
On Wed, 3 Apr 2024 09:58:12 -0700
Andrii Nakryiko wrote:
> On Wed, Apr 3, 2024 at 7:09 AM Masami Hiramatsu wrote:
> >
> > On Wed, 3 Apr 2024 11:47:41 +0200
> > Jiri Olsa wrote:
> >
> > > On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> > > > Hi Jiri,
> > > >
> > > > On Tue,
On Fri, Mar 29, 2024 at 5:52 PM Michael S. Tsirkin wrote:
>
> On Fri, Mar 29, 2024 at 05:38:25PM +0800, Cindy Lu wrote:
> > Add a document explaining the reconnect process, including what the
> > Userspace App needs to do and how it works with the kernel.
> >
> > Signed-off-by: Cindy Lu
> > ---
Fix the following -Wformat-security compile warnings adding missing
format arguments:
latency-collector.c: In function ‘show_available’:
latency-collector.c:938:17: warning: format not a string literal and
no format arguments [-Wformat-security]
938 | warnx(no_tracer_msg);
On Thu, Apr 4, 2024 at 9:50 AM Jakub Kicinski wrote:
>
> On Wed, 3 Apr 2024 15:31:38 +0800 Jason Xing wrote:
> > It's based on top of
> > https://patchwork.kernel.org/project/netdevbpf/list/?series=840182
>
> Please post as RFC if there's a dependency.
> We don't maintain patch queues for
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Mon, 1 Apr 2024 15:36:03 +0800 you wrote:
> From: Jason Xing
>
> Before this, we miss some cases where the TCP layer could send RST but
> we cannot trace it. So I decided to complete it :)
>
> v4
> Link:
>
Add a document explaining the reconnect process, including what the
Userspace App needs to do and how it works with the kernel.
Signed-off-by: Cindy Lu
---
Documentation/userspace-api/vduse.rst | 41 +++
1 file changed, 41 insertions(+)
diff --git
60 matches
Mail list logo
