;left' and 'curr'
could both be NULL, then this will cause NULL pointer issue.
In order to fix this issue, we just need return NULL under the condition
that both 'left' and 'curr' are NULL, meaning that no entity available.
Signed-off-by: Yafang Shao
---
kerne
ecifically.
Signed-off-by: Yafang Shao
---
drivers/tty/sysrq.c | 2 +-
include/linux/sched.h | 1 +
include/linux/sched/debug.h | 6 --
kernel/sched/core.c | 7 ---
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
ind
ecifically.
Signed-off-by: Yafang Shao
---
drivers/tty/sysrq.c | 2 +-
include/linux/sched.h | 1 +
include/linux/sched/debug.h | 6 --
kernel/sched/core.c | 7 ---
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
ind
08, 2017 at 08:53:10PM +0800, Yafang Shao wrote:
>> Sometimes we want to get tasks in TASK_RUNNING sepcifically,
>> instead of dump all tasks.
>> For example, when the loadavg are high, we want to dump
>> tasks in TASK_RUNNING and TASK_UNINTERRUPTIBLE, which contribute
&g
ks (with a new key, or
something else).
But in order to introduce the new key, we should made this change first.
After this change got approved, I will try to make some changes in SysRq.
Thanks
Yafang
2017-08-08 18:24 GMT+08:00 Peter Zijlstra :
> On Tue, Aug 08, 2017 at 04:50:23PM +0800, Yafa
Okay.
I will submit the whole work in a new patch later.
2017-08-08 19:04 GMT+08:00 Peter Zijlstra :
> On Tue, Aug 08, 2017 at 06:36:41PM +0800, Yafang Shao wrote:
>> After this change got approved, I will try to make some changes in SysRq.
>
> No, that's not how it works. Show the whole work.
2017-08-08 19:24 GMT+08:00 Peter Zijlstra :
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?On Tue, Aug 08, 2017 at
> 07:07:26PM +0800, Yafang Shao
he tasks in running state is that
dumping both blocked tasks and running tasks is more helpful than
dump blocked tasks only. That's an improvement.
Signed-off-by: Yafang Shao
---
drivers/tty/sysrq.c | 15 ---
include/linux/sched.h | 1 +
include/linux/sched/deb
2017-08-09 15:43 GMT+08:00 Peter Zijlstra :
> On Wed, Aug 09, 2017 at 06:31:28PM +0800, Yafang Shao wrote:
>> Sometimes we want to get tasks in TASK_RUNNING sepcifically,
>> instead of dump all tasks.
>>
>> For example, when the loadavg are high, we want to dump
&
2017-08-09 17:09 GMT+08:00 Peter Zijlstra :
> On Wed, Aug 09, 2017 at 04:01:49PM +0800, Yafang Shao wrote:
>> 2017-08-09 15:43 GMT+08:00 Peter Zijlstra :
>> > On Wed, Aug 09, 2017 at 06:31:28PM +0800, Yafang Shao wrote:
>> >> Sometimes we want to get task
.
> You diff is broken, this is very much not the clear_buddies() function.
You're right. it is in pick_next_entity().
2017-08-01 16:38 GMT+08:00 Peter Zijlstra :
> On Tue, Aug 01, 2017 at 06:01:56PM +0800, Yafang Shao wrote:
>> When we select CFQ as the scheduler, in function pick_n
Hi Peter,
2017-08-01 17:12 GMT+08:00 Peter Zijlstra :
> On Tue, Aug 01, 2017 at 04:57:43PM +0800, Yafang Shao wrote:
>> > And how would that happen? We only call pick_next_entity(.curr=NULL)
>> > when we _know_ cfs_rq->nr_running.
>>
>> It crashed my machine
newstate)
When do TCP/IP state transition, we should use these two helpers or use
tcp_set_state() other than assigning a value to sk_state directly.
Signed-off-by: Yafang Shao
---
v2: test
---
include/net/tcp.h | 2 ++
net/ipv4/inet_connection_sock.c | 6 +++---
net/ipv4
);
When do TCP/IP state transition, we should use these two helpers or use
tcp_set_state() other than assigning a value to sk_state directly.
Signed-off-by: Yafang Shao
Acked-by: Song Liu
Reviewed-by: Marcelo Ricardo Leitner
---
v3->v4: Do not trace DCCP socket
v2->v3: Per suggestion from M
);
When do TCP/IP state transition, we should use these two helpers or use
tcp_set_state() other than assigning a value to sk_state directly.
Signed-off-by: Yafang Shao
Acked-by: Song Liu
Reviewed-by: Marcelo Ricardo Leitner
Signed-off-by: Yafang Shao
---
v4->v5: Trace only TCP sockets, whate
__sk_state_store(struct sock *sk, int newstate)
When do TCP/IPv4 state transition, we should use these two helpers or
use tcp_set_state() instead of assign a value to sk_state directly.
Signed-off-by: Yafang Shao
---
include/net/tcp.h | 16
include/trace/events/tcp.h
2017-11-09 14:43 GMT+08:00 Alexei Starovoitov :
> On Thu, Nov 09, 2017 at 02:01:38PM +0800, Yafang Shao wrote:
>> With this newly introduced TRACE_EVENT, it will be very easy to minotor
>> TCP/IPv4 state transition.
>>
>> A new TRACE_SYSTEM named tcp is added, in w
, int newstate)
When do TCP/IP state transition, we should use these two helpers or use
tcp_set_state() other than assigning a value to sk_state directly.
Signed-off-by: Yafang Shao
---
include/net/tcp.h | 16
net/ipv4/inet_connection_sock.c | 6 +++---
net
When TCP connetion in TCP_TIME_WAIT or TCP_NEW_SYN_RECV state, it can't
get the sport/dport/saddr/daddr from inet_sock.
trace_tcp_set_state may be called when the oldstate in these two states.
Signed-off-by: Yafang Shao
---
include/trace/events/tcp.h | 33 ++-
2017-11-09 22:58 GMT+08:00 Eric Dumazet :
> On Thu, 2017-11-09 at 06:52 -0800, Eric Dumazet wrote:
>
>> Wow.
>>
>>
>> Since all three variants of sockets (full sockets, request sockets,
>> timewait sockets) are all hashed into ehash table these days, they all
>> have the fields at the same offset
>
2017-11-10 8:57 GMT+08:00 Steven Rostedt :
>
> From: "Steven Rostedt (VMware)"
>
> The TCP trace events (specifically tcp_set_state), maps emums to symbol
> names via __print_symbolic(). But this only works for reading trace events
> from the tracefs trace files. If perf or trace-cmd were to recor
2017-11-10 15:07 GMT+00:00 Steven Rostedt :
> On Fri, 10 Nov 2017 12:56:06 +0800
> Yafang Shao wrote:
>
>> Could the macro tcp_state_name() be renamed ？
>> If is included in include/net/tcp.h, it will
>
> Ideally, you don't want to include trace/events/*.h headers
2017-11-18 1:35 GMT+08:00 Shakeel Butt :
> On Fri, Nov 17, 2017 at 9:09 AM, Yafang Shao wrote:
>> 2017-11-18 0:45 GMT+08:00 Roman Gushchin :
>>> On Sat, Nov 18, 2017 at 12:20:40AM +0800, Yafang Shao wrote:
>>>> 2017-11-17 23:55 GMT+08:00 Roman Gushchin :
>>>
2017-11-18 1:49 GMT+08:00 Shakeel Butt :
> On Fri, Nov 17, 2017 at 9:41 AM, Yafang Shao wrote:
>> 2017-11-18 1:35 GMT+08:00 Shakeel Butt :
>>> On Fri, Nov 17, 2017 at 9:09 AM, Yafang Shao wrote:
>>>> 2017-11-18 0:45 GMT+08:00 Roman Gushchin :
>>>>
newstate)
When do TCP/IP state transition, we should use these two helpers or use
tcp_set_state() other than assigning a value to sk_state directly.
Signed-off-by: Yafang Shao
---
include/net/tcp.h | 2 ++
net/ipv4/inet_connection_sock.c | 6 +++---
net/ipv4/inet_hashtables.c | 2
2017-11-20 20:04 GMT+08:00 Michal Hocko :
> On Fri 17-11-17 09:49:54, Shakeel Butt wrote:
>> On Fri, Nov 17, 2017 at 9:41 AM, Yafang Shao wrote:
> [...]
>> > Of couse that is the best way.
>> > But we can not ensue all applications will do it.
>> > That&#
2017-11-20 20:39 GMT+08:00 Michal Hocko :
> On Mon 20-11-17 20:16:15, Yafang Shao wrote:
>> 2017-11-20 20:04 GMT+08:00 Michal Hocko :
>> > On Fri 17-11-17 09:49:54, Shakeel Butt wrote:
>> >> On Fri, Nov 17, 2017 at 9:41 AM, Yafang Shao wrote:
>> > [...
the whole tcp lifespans with kprobe or ftrace easily.
Signed-off-by: Yafang Shao
---
net/ipv4/inet_connection_sock.c | 6 +++---
net/ipv4/inet_hashtables.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
2017-11-08 14:51 GMT+08:00 David Miller :
> From: Yafang Shao
> Date: Tue, 7 Nov 2017 18:36:28 +0800
>
>> When I hooked the function tcp_set_state with kprobe to track the ipv4/tcp
>> state transistion, I found state transition from TCP_LISTEN to TCP_SYN_RECV
>> is
2017-12-08 4:02 GMT+08:00 Marcelo Ricardo Leitner :
> On Thu, Dec 07, 2017 at 02:10:42PM +0000, Yafang Shao wrote:
>> The TCP/IP transition from TCP_LISTEN to TCP_SYN_RECV and some other
>> transitions are not traced with tcp_set_state tracepoint.
>>
>> In order to tr
2017-12-08 9:41 GMT+08:00 Yafang Shao :
> 2017-12-08 4:02 GMT+08:00 Marcelo Ricardo Leitner :
>> On Thu, Dec 07, 2017 at 02:10:42PM +0000, Yafang Shao wrote:
>>> The TCP/IP transition from TCP_LISTEN to TCP_SYN_RECV and some other
>>> transitions are not traced wi
2017-12-08 23:42 GMT+08:00 David Miller :
> From: Yafang Shao
> Date: Fri, 8 Dec 2017 11:40:23 +0800
>
>> It will looks like these,
>>
>> if (sk->sk_protocol == IPPROTO_TCP)
>> __tcp_set_state(newsk, TCP_SYN_RECV);
>> else
>>
2017-12-09 0:28 GMT+08:00 David Miller :
> From: Yafang Shao
> Date: Fri, 8 Dec 2017 23:50:44 +0800
>
>> 2017-12-08 23:42 GMT+08:00 David Miller :
>>> From: Yafang Shao
>>> Date: Fri, 8 Dec 2017 11:40:23 +0800
>>>
>>>> It will looks like t
state);
- void sk_set_state(struct sock *sk, int state);
As trace header should not be included in other header files,
so they are defined in sock.c.
The protocol such as SCTP maybe compiled as a ko, hence export
sk_set_state().
Signed-off-by: Yafang Shao
---
include/net/sock.h | 15
Hi,
According to the discussion in the mail thread
https://patchwork.kernel.org/patch/10099243/,
tcp_set_state tracepoint is renamed to sock_set_state tracepoint and is moved
to include/trace/events/sock.h.
Using this new tracepoint to trace TCP/DCCP/SCTP state transition.
Yafang Shao (3
With changes in inet_ files, DCCP state transitions are traced with
sock_set_state tracepoint.
Signed-off-by: Yafang Shao
---
net/dccp/proto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
index b68168f..92b9613 100644
--- a/net/dccp
With changes in inet_ files, SCTP state transitions are traced with
sockt_set_state tracepoint.
Signed-off-by: Yafang Shao
---
net/sctp/endpointola.c | 2 +-
net/sctp/sm_sideeffect.c | 4 ++--
net/sctp/socket.c| 14 +++---
3 files changed, 10 insertions(+), 10 deletions
On Fri, Oct 4, 2024 at 11:40 PM tyrone-wu wrote:
>
> Previously when retrieving `bpf_link_info.perf_event` for
> kprobe/uprobe/tracepoint, the `name_len` field was not populated by the
> kernel, leaving it to reflect the value initially set by the user. This
> behavior was inconsistent with how ot
.com/
> Fixes: 1b715e1b0ec5 ("bpf: Support ->fill_link_info for perf_event")
> Signed-off-by: tyrone-wu
> Acked-by: Jiri Olsa
LGTM
Acked-by: Yafang Shao
> ---
> V4 -> V5:
> Link:
> https://lore.kernel.org/bpf/caloahbc5xm7cbfhau3z5x2pquhihecnwaptjcwiovqtkmdz...@
...@mail.gmail.com/
> Fixes: 23cf7aa539dc ("selftests/bpf: Add selftest for fill_link_info")
> Signed-off-by: tyrone-wu
> Acked-by: Jiri Olsa
Acked-by: Yafang Shao
> ---
> V4 -> V5: no change
>
> V3 -> V4:
> Link: https://lore.kernel.org/bpf/Zv_PP6
On Fri, Jan 31, 2025 at 9:18 PM Miroslav Benes wrote:
>
> > >
> > > + What exactly is meant by frequent replacements (busy loop?, once a
> > > minute?)
> >
> > The script:
> >
> > #!/bin/bash
> > while true; do
> > yum install -y ./kernel-livepatch-6.1.12-0.x86_64.rpm
> > ./appl
On Tue, Feb 4, 2025 at 9:21 PM Petr Mladek wrote:
>
> On Mon 2025-01-27 23:34:50, Yafang Shao wrote:
> > On Mon, Jan 27, 2025 at 10:31 PM Petr Mladek wrote:
> > >
> > > On Mon 2025-01-27 14:35:26, Yafang Shao wrote:
> > > > The atomic replace li
On Tue, Feb 4, 2025 at 9:05 PM Petr Mladek wrote:
>
> On Mon 2025-02-03 17:44:52, Yafang Shao wrote:
> > On Fri, Jan 31, 2025 at 9:18 PM Miroslav Benes wrote:
> > >
> > > > >
> > > > > + What exactly is meant by frequent replacements (busy lo
On Fri, Feb 7, 2025 at 5:36 PM Petr Mladek wrote:
>
> On Fri 2025-02-07 11:16:45, Yafang Shao wrote:
> > On Fri, Feb 7, 2025 at 10:31 AM Josh Poimboeuf wrote:
> > > On Mon, Jan 27, 2025 at 02:35:26PM +0800, Yafang Shao wrote:
> > > > - Temporary Loss of Patc
On Sat, Feb 8, 2025 at 12:59 AM Josh Poimboeuf wrote:
>
> On Fri, Feb 07, 2025 at 11:16:45AM +0800, Yafang Shao wrote:
> > On Fri, Feb 7, 2025 at 10:31 AM Josh Poimboeuf wrote:
> > > Why does this happen?
> >
> > It occurs during the KLP transition. It seems like
On Fri, Feb 7, 2025 at 7:01 PM Petr Mladek wrote:
>
> On Wed 2025-02-05 14:16:42, Yafang Shao wrote:
> > On Tue, Feb 4, 2025 at 9:05 PM Petr Mladek wrote:
> > >
> > > On Mon 2025-02-03 17:44:52, Yafang Shao wrote:
> > > > On Fri, Jan
On Fri, Feb 7, 2025 at 9:58 PM Petr Mladek wrote:
>
> On Thu 2025-02-06 10:35:11, Yafang Shao wrote:
> > On Thu, Feb 6, 2025 at 12:03 AM Petr Mladek wrote:
> > >
> > > On Wed 2025-02-05 10:54:47, Yafang Shao wrote:
> > > > On Tue, Feb 4, 2025 at 9:21 PM
On Fri, Feb 7, 2025 at 2:01 AM Song Liu wrote:
>
> On Wed, Feb 5, 2025 at 6:55 PM Yafang Shao wrote:
> [...]
> > > I think we should first understand why the trampoline is not
> > > freed.
> >
> > IIUC, the fexit works as follows,
> >
>
On Sat, Feb 8, 2025 at 10:49 AM Yafang Shao wrote:
>
> On Fri, Feb 7, 2025 at 7:01 PM Petr Mladek wrote:
> >
> > On Wed 2025-02-05 14:16:42, Yafang Shao wrote:
> > > On Tue, Feb 4, 2025 at 9:05 PM Petr Mladek wrote:
> > > >
> > > > On Mon 2025-
On Sun, Feb 9, 2025 at 11:57 AM Alexei Starovoitov
wrote:
>
> On Sat, Feb 8, 2025 at 11:32 AM Josh Poimboeuf wrote:
> >
> > On Sat, Feb 08, 2025 at 07:47:12AM -0800, Alexei Starovoitov wrote:
> > > On Fri, Feb 7, 2025 at 10:42 PM Yafang Shao wrote:
> > > >
On Tue, Feb 4, 2025 at 5:53 AM Song Liu wrote:
>
> On Mon, Feb 3, 2025 at 1:45 AM Yafang Shao wrote:
> [...]
> >
> > If you’re managing a large fleet of servers, this issue is far from
> > negligible.
> >
> > >
> > > > Can you provid
On Thu, Feb 6, 2025 at 1:59 AM Song Liu wrote:
>
> On Wed, Feb 5, 2025 at 6:43 AM Yafang Shao wrote:
> >
> > On Tue, Feb 4, 2025 at 5:53 AM Song Liu wrote:
> > >
> > > On Mon, Feb 3, 2025 at 1:45 AM Yafang Shao wrote:
> > > [...]
> > >
On Thu, Feb 6, 2025 at 12:03 AM Petr Mladek wrote:
>
> On Wed 2025-02-05 10:54:47, Yafang Shao wrote:
> > On Tue, Feb 4, 2025 at 9:21 PM Petr Mladek wrote:
> > >
> > > On Mon 2025-01-27 23:34:50, Yafang Shao wrote:
> > > > On Mon, J
On Fri, Feb 7, 2025 at 10:31 AM Josh Poimboeuf wrote:
>
> On Mon, Jan 27, 2025 at 02:35:26PM +0800, Yafang Shao wrote:
> > The atomic replace livepatch mechanism was introduced to handle scenarios
> > where we want to unload a specific livepatch without unloading others.
> &
On Mon, Jan 27, 2025 at 9:46 PM Petr Mladek wrote:
>
> On Mon 2025-01-27 14:35:24, Yafang Shao wrote:
> > The atomic replace livepatch mechanism was introduced to handle scenarios
> > where we want to unload a specific livepatch without unloading others.
> > However, it
pport it in kpatch[1]
Link:
https://lore.kernel.org/live-patching/CALOAHbA9WHPjeZKUcUkwULagQjTMfqAdAg+akqPzbZ7Byc=q...@mail.gmail.com/
[0]
Link: https://github.com/dynup/kpatch [1]
Yafang Shao (2):
livepatch: Add replaceable attribute
livepatch: Implement livepatch hybrid mode
include/li
Add a new attribute "replaceable" to allow the coexsist of both atomic
replace livepatch and non atomic replace livepatch. If the replaceable is
set to 0, the livepatch won't be replaced by a atomic replace livepatch.
This is a preparation for the followup patch.
Signed-off-
lore.kernel.org/live-patching/CALOAHbA9WHPjeZKUcUkwULagQjTMfqAdAg+akqPzbZ7Byc=q...@mail.gmail.com/
[0]
Signed-off-by: Yafang Shao
---
kernel/livepatch/core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 5e0c2caa0af8..f820b50c1b26
On Mon, Jan 27, 2025 at 10:31 PM Petr Mladek wrote:
>
> On Mon 2025-01-27 14:35:26, Yafang Shao wrote:
> > The atomic replace livepatch mechanism was introduced to handle scenarios
> > where we want to unload a specific livepatch without unloading others.
> > However, it
@jpoimboe/ [1]
Signed-off-by: Yafang Shao
---
include/linux/livepatch.h | 4 ++--
kernel/fork.c | 2 +-
kernel/livepatch/patch.c | 7 ++-
kernel/livepatch/transition.c | 35 ++-
kernel/livepatch/transition.h | 1 +
5 files changed, 24
the root cause is identified, I will submit the fix separately.
v1:
https://lore.kernel.org/live-patching/20250211062437.46811-1-laoar.s...@gmail.com/
Yafang Shao (2):
livepatch: Add comment to clarify klp_add_nops()
livepatch: Replace tasklist_lock with RCU
include/linux/livepatch.h |
Add detailed comments to clarify the purpose of klp_add_nops() function.
These comments are based on Petr's explanation[0].
Link: https://lore.kernel.org/all/z6xua7d0eu_yd...@pathway.suse.cz/ [0]
Suggested-by: Petr Mladek
Suggested-by: Josh Poimboeuf
Signed-off-by: Yafang Shao
---
k
On Wed, Feb 26, 2025 at 2:33 AM Josh Poimboeuf wrote:
>
> On Sun, Feb 23, 2025 at 02:20:46PM +0800, Yafang Shao wrote:
> > +++ b/kernel/livepatch/patch.c
> > @@ -95,7 +95,12 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> >
> > patc
Commit-ID: 6e662ae7bce6db602f79e57791f5fb887fb7d371
Gitweb: https://git.kernel.org/tip/6e662ae7bce6db602f79e57791f5fb887fb7d371
Author: Yafang Shao
AuthorDate: Wed, 21 Nov 2018 19:12:14 +0800
Committer: Ingo Molnar
CommitDate: Fri, 23 Nov 2018 07:58:23 +0100
x86/process: Avoid
Commit-ID: c382986fe178d02abdfcd6f4e7b9783c2922872c
Gitweb: https://git.kernel.org/tip/c382986fe178d02abdfcd6f4e7b9783c2922872c
Author: Yafang Shao
AuthorDate: Wed, 21 Nov 2018 19:12:14 +0800
Committer: Ingo Molnar
CommitDate: Thu, 22 Nov 2018 10:07:21 +0100
x86/process: Avoid
301 - 365 of 365 matches
Mail list logo
