All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: zhang warden <zhangwarden@gmail.com>
Cc: Yafang Shao <laoar.shao@gmail.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jiri Kosina <jikos@kernel.org>,
	mbenes@suse.cz, joe.lawrence@redhat.com,
	live-patching@vger.kernel.org
Subject: Re: [PATCH] livepatch: Avoid hard lockup caused by klp_try_switch_task()
Date: Fri, 31 Jan 2025 14:39:38 +0100	[thread overview]
Message-ID: <Z5zSmlRIv5qhuVja@pathway.suse.cz> (raw)
In-Reply-To: <A250B752-FFBF-4A53-B981-FE6D9A9F5C14@gmail.com>

On Fri 2025-01-31 21:22:13, zhang warden wrote:
> 
> 
> > On Jan 22, 2025, at 20:50, Petr Mladek <pmladek@suse.com> wrote:
> > 
> > With this patch, any operation which takes the tasklist_lock might
> > break klp_try_complete_transition(). I am afraid that this might
> > block the transition for a long time on huge systems with some
> > specific loads.
> > 
> > And the problem is caused by a printk() added just for debugging.
> > I wonder if you even use a slow serial port.
> > 
> > You might try to use printk_deferred() instead. Also you might need
> > to disable interrupts around the read_lock()/read_unlock() to
> > make sure that the console handling will be deferred after
> > the tasklist_lock gets released.
> > 
> > Anyway, I am against this patch.
> > 
> > Best Regards,
> > Petr
> 
> Hi, Petr.
> 
> I am unfamiliar with the function `rwlock_is_contended`, but it seems this function will not block and just only check the status of the rw_lock.
> 
> If I understand it right, the problem would raise from the `break` which will stop the process of `for_each_process_thread`, right?

You got it right. I am afraid that it might create a livelock
situation for the livepatch transition. I mean that the check
might almost always break on systems with thousands of processes
and frequently created/exited processes. It always has
to start from the beginning.

Best Regards,
Petr

  reply	other threads:[~2025-01-31 13:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-22  8:51 [PATCH] livepatch: Avoid hard lockup caused by klp_try_switch_task() Yafang Shao
2025-01-22 12:50 ` Petr Mladek
2025-01-22 13:46   ` Yafang Shao
2025-01-31 13:06     ` Miroslav Benes
2025-01-31 13:22   ` zhang warden
2025-01-31 13:39     ` Petr Mladek [this message]
2025-02-01  2:04       ` zhang warden
2025-02-05  8:39       ` Yafang Shao
2025-02-06 16:43         ` Petr Mladek
2025-02-07  2:16           ` Yafang Shao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z5zSmlRIv5qhuVja@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=zhangwarden@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.