On Tue, 7 Oct 2014 06:43:29 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Tue, Oct 07, 2014 at 09:29:42AM +0200, Jiri Pirko wrote:
[ ... snip ... ]
Paul, Tehun, how do you propose to fix this on older kernels which do
not have rcu_note_voluntary_context_switch? I'm
there are other higher priority tasks to run, so force a
quiescent RCU state between work items with cond_resched_rcu_qs.
Signed-off-by: Joe Lawrence joe.lawre...@stratus.com
Link:
https://lkml.kernel.org/r/20140926105227.01325...@jlaw-desktop.mno.stratus.com
Link:
https://lkml.kernel.org/r
there are other higher priority tasks to run, so force a
quiescent RCU state between work items.
Signed-off-by: Joe Lawrence joe.lawre...@stratus.com
Link:
https://lkml.kernel.org/r/20140926105227.01325...@jlaw-desktop.mno.stratus.com
Link:
https://lkml.kernel.org/r/20140929115445.40221...@jlaw
v2 - split into two patches: the first inlines the cond_resched_rcu_qs
macro suitable for stable backport, the second converts to using
cond_resched_rcu_qs.
Joe Lawrence (2):
workqueue: add quiescent state between work items
workqueue: use cond_resched_rcu_qs macro
kernel/workqueue.c |5
Tidy up and use cond_resched_rcu_qs when calling cond_resched and
reporting potential quiescent state to RCU.
Signed-off-by: Joe Lawrence joe.lawre...@stratus.com
---
kernel/workqueue.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/workqueue.c b/kernel
Hello Tejun,
(RHEL7 kernel, see config below)
I'm debugging an RCU stall where it seems that the culprit is a kworker
workqueue function that decides to reschedule itself over and over via
schedule_delayed_work with a 0 jiffy delay. If I watch rcudata, I can
see that the CPU currently running
On Sun, 28 Sep 2014, Tejun Heo wrote:
Hello, Joe.
On Fri, Sep 26, 2014 at 10:52:27AM -0400, Joe Lawrence wrote:
...
I was wondering if such behavior was expected on !PREEMPT kernels,
especially after b22ce2785d97 workqueue: cond_resched() after
processing each work item
On 12/29/2014 12:25 PM, Nicholas Mc Guire wrote:
wait_for_completion_timeout reaching timeout was being ignored,
this probably also should fail if timeout condition occurs ?
this was only compile tested with
x86_64_defconfig + CONFIG_SCSI_LOWLEVEL=y + CONFIG_SCSI_MPT2SAS=m
patch is
On 12/30/2014 11:19 AM, Nicholas Mc Guire wrote:
wait_for_completion_timeout reaching timeout was being ignored,
this also should fail if timeout condition occurs.
Thanks to Joe Lawrence joe.lawre...@stratus.com for confirmation.
How about this instead:
Acked-by: Joe Lawrence joe.lawre
On 11/29/2018 04:44 AM, Petr Mladek wrote:
> Hi,
>
> I have an updated present for your mailboxes.
>
> The atomic replace allows to create cumulative patches. They
> are useful when you maintain many livepatches and want to remove
> one that is lower on the stack. In addition it is very useful
On Thu, Nov 29, 2018 at 10:44:29AM +0100, Petr Mladek wrote:
> User documentation for the atomic replace feature. It makes it easier
> to maintain livepatches using so-called cumulative patches.
>
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
> Documentation/li
^
s/handle situation/handle a situation
> (ops->func_stack) is being removed.
>
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
> Documentation/livepatch/cumulative-patches.txt | 11 ++
> Documentation/livepatch/livepatch.txt | 30 ---
&
On Thu, Nov 29, 2018 at 10:44:31AM +0100, Petr Mladek wrote:
> From: Joe Lawrence
>
> Add a few livepatch modules and simple target modules that the included
> regression suite can run tests against:
>
> - basic livepatching (multiple patches, atomic replace)
>
called
> asynchronously. We could not wait for them easily. Fortunately, we do
> not have to. Any further access can be avoided by removing them from
> the dynamic lists.
>
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
-- Joe
On 12/06/2018 07:37 AM, Petr Mladek wrote:
> On Thu 2018-12-06 11:15:55, Petr Mladek wrote:
>> On Thu 2018-12-06 10:32:00, Miroslav Benes wrote:
>>>
> I don't have many code comments as the changes appear to safely and
> correctly do what the say. (We are at v14 after all :) I mainly
On 12/06/2018 05:14 AM, Petr Mladek wrote:
> On Thu 2018-12-06 10:23:40, Miroslav Benes wrote:
>> On Thu, 6 Dec 2018, Petr Mladek wrote:
>>
>>> On Wed 2018-12-05 14:32:53, Joe Lawrence wrote:
>>>>> diff --git a/kernel/livepatch/core.c b/kernel/li
On 11/28/2018 11:24 PM, Steven Rostedt wrote:
> On Wed, 28 Nov 2018 22:29:36 -0500
> Steven Rostedt wrote:
>
>> Does this patch fix it for you?
>
> Take 2. I realized that the reason for the interrupts being traced is
> because it is more likely to interrupt when the depth is already 0,
>
On 11/29/2018 11:17 AM, Steven Rostedt wrote:
> On Thu, 29 Nov 2018 10:08:55 -0500
> Joe Lawrence wrote:
>
>> With the "take 2" patch, I only see smp_irq_work_interrupt() graph when
>> the graph_function is in progress.. for example:
>
> In other words
t; we block only modules that might still be in use after a forced
> transition. Newly loaded livepatches might be eventually completely
> removed later.
>
> It is not a big deal. But the code is at least consistent with
> the reality.
>
> Signed-off-by: Petr Mladek
Acked-by: Joe Lawrence
-- Joe
on is asynchronous already when the first
> klp_try_complete_transition() fails and another call
> is queued with a delay.
>
> Suggested-by: Josh Poimboeuf
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
> Documentation/livepatch/l
> [pmla...@suse.com: Initialize lists before init calls]
> Signed-off-by: Petr Mladek
> Cc: Josh Poimboeuf
> Cc: Jessica Yu
> Cc: Jiri Kosina
> Cc: Miroslav Benes
> ---
Acked-by: Joe Lawrence
-- Joe
he removal is done by a special function. It combines actions done by
> __disable_patch() and klp_complete_transition(). But it is a fast
> track without all the transaction-related stuff.
>
> Signed-off-by: Jason Baron
> [pmla...@suse.com: Split, reuse existing code, simplified
atch does not modify the existing behavior.
>
> Suggested-by: Josh Poimboeuf
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
-- Joe
rd declarations.
>
> This patch does not change the code except of two forward declarations.
^
s/except of/except for
>
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
-- Joe
r own flag to track that the kobject was successfully
added to the hierarchy. Note that kobj.state_initialized only
indicates that kobject has been initialized, not whether is has been
added (and needs to be removed on cleanup).
>
> Signed-off-by: Petr Mladek
> Cc: Josh Poi
On 12/06/2018 03:15 AM, Petr Mladek wrote:
> On Wed 2018-12-05 14:02:20, Joe Lawrence wrote:
>> On Thu, Nov 29, 2018 at 10:44:23AM +0100, Petr Mladek wrote:
>>> The code for freeing livepatch structures is a bit scattered and tricky:
>>>
>>> [ ... snip ...
ould need to be done to be confident that it is safe? Is matching on
".text.*" too inclusive?
Thanks,
-- Joe
Joe Lawrence (1):
scripts/recordmcount.{c,pl}: support -ffunction-sections .text.*
section names
scripts/recordmcount.c | 2 +-
scripts/recordmcount.pl | 13 +
mp --reloc --section __mcount_loc test_module.o
OFFSET TYPE VALUE
R_X86_64_64 .text.test_module_do_work
0008 R_X86_64_64 .text.test_module_wq_func
0010 R_X86_64_64 .init.text
Signed-off-by: Joe Lawrence
---
scripts/
On 11/20/2018 03:19 PM, Joe Lawrence wrote:
> Hi Steve,
>
> I noticed that ftrace does not currently support functions built with
> the -ffunction-sections option as they end up in .text.
> ELF sections, never making into the __mcount_loc section.
>
> I modified the
On 11/27/2018 09:09 PM, Steven Rostedt wrote:
> On Tue, 27 Nov 2018 15:27:14 -0500
> Joe Lawrence wrote:
>
>> Gentle ping... I took a dive through the rhkl-archives and found a few
>> older discussions:
>
> Thanks for the reminder, my INBOX is totally out of contr
On Wed, Nov 21, 2018 at 07:28:01PM -0500, Steven Rostedt wrote:
>
> [ ... snip ... ]
>
> Feel free to test this! I'll be pushing this to linux-next and let it
> sit there a week or so before pushing it to Linus.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
>
On Tue, Apr 02, 2024 at 11:09:54AM +0800, zhangwar...@gmail.com wrote:
> From: Wardenjohn
>
> In livepatch, using KLP_UNDEFINED is seems to be confused.
> When kernel is ready, livepatch is ready too, which state is
> idle but not undefined. What's more, if one livepatch process
> is finished,
On 4/4/24 11:17, Petr Mladek wrote:
> On Tue 2024-04-02 09:52:31, Joe Lawrence wrote:
>> On Tue, Apr 02, 2024 at 11:09:54AM +0800, zhangwar...@gmail.com wrote:
>>> From: Wardenjohn
>>>
>>> In livepatch, using KLP_UNDEFINED is seems to be confused.
>>>
Commit-ID: e9ca267096674eadd1fd479279bcb58df1486049
Gitweb: https://git.kernel.org/tip/e9ca267096674eadd1fd479279bcb58df1486049
Author: Joe Lawrence <joe.lawre...@redhat.com>
AuthorDate: Mon, 19 Mar 2018 14:35:55 -0400
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate:
Commit-ID: a8c024cd9b9683d25ae1f459525dd2c6bec75e79
Gitweb: https://git.kernel.org/tip/a8c024cd9b9683d25ae1f459525dd2c6bec75e79
Author: Joe Lawrence <joe.lawre...@redhat.com>
AuthorDate: Mon, 19 Mar 2018 14:35:54 -0400
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate:
Commit-ID: a8c024cd9b9683d25ae1f459525dd2c6bec75e79
Gitweb: https://git.kernel.org/tip/a8c024cd9b9683d25ae1f459525dd2c6bec75e79
Author: Joe Lawrence
AuthorDate: Mon, 19 Mar 2018 14:35:54 -0400
Committer: Ingo Molnar
CommitDate: Tue, 20 Mar 2018 09:30:09 +0100
sched/debug: Fix per-task
Commit-ID: e9ca267096674eadd1fd479279bcb58df1486049
Gitweb: https://git.kernel.org/tip/e9ca267096674eadd1fd479279bcb58df1486049
Author: Joe Lawrence
AuthorDate: Mon, 19 Mar 2018 14:35:55 -0400
Committer: Ingo Molnar
CommitDate: Tue, 20 Mar 2018 09:30:09 +0100
sched/debug: Adjust
Commit-ID: 7eaf51a2e094229b75cc0c315f1cbbe2f3960058
Gitweb: https://git.kernel.org/tip/7eaf51a2e094229b75cc0c315f1cbbe2f3960058
Author: Joe Lawrence
AuthorDate: Fri, 17 May 2019 14:51:17 -0400
Committer: Thomas Gleixner
CommitDate: Sun, 19 May 2019 11:43:22 +0200
stacktrace: Unbreak
601 - 638 of 638 matches
Mail list logo
