hat
simple example you have complete control over the context of your
task. This is necessary to avoid things like priority inversion and
page-faults, and gives you control over things like affinity or cgroups.
John Ogness
[0]
https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/cyclic
a boolean that is set if any TR is
being processed by either the EMDA3CC or EDMA3TC. By polling
this register it is possible to ensure that the residue value
returned is valid for immediate processing.
Signed-off-by: John Ogness
---
arch/arm/common/edma.c | 17
-off-by: John Ogness
---
drivers/dma/edma.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 493c774..16bd193 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -585,6 +585,7 @@ static struct
never hit a moment where
no TR is being processed. To handle this, the SRC/DST is also
polled to see if it changes. And as a last resort, a max loop
count for the busy waiting exists to avoid an infinite loop.
Signed-off-by: John Ogness
---
v1-v2 changes
. rebased for next-20151016
. added
-off-by: John Ogness
---
v1-v2 changes
. rebased for next-20151016
drivers/dma/edma.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7eefbf1..f846935 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma
On 2015-10-16, Peter Ujfalusi wrote:
> On 10/16/2015 01:26 PM, John Ogness wrote:
>> When retrieving the residue value for cyclic transfers, the
>> SRC/DST fields of the active PaRAM are read. However, the AM335x
>> Technical Reference Manual states:
>>
>>
ority
conditions would cause the priority sorting to become invalid and thus
cause the spurious interrupt.
I'm not sure if we can/should do anything more than Sekhar's patch of
acknowledging the spurious interrupt so the priority sorting algorithm
can run again.
John Ogness
--
To unsubsc
00 00 4c 8b 4c 24 70 4c 8b 44 24 78 4c 89 74 24 18 e9 91 f9
> ff ff f6 45 4d 02 0f 84 fd f7 ff ff 48 8b 45 40 48 89 ef <48> 8b 80 d8 3f 00
> 00 48 89 44 24 20 e8 9b 97 eb ff 48 89 44 24
> RIP: do_task_stat+0x8b4/0xaf0 RSP: c9607cc8
> CR2: 3fd8
>
> Reported-by: &
k_struct.state -x 0xFFE80D8C2280
> state = 0x40
I am confused why this task is in the TASK_PARKED state. What kind of
task is this?
> In our build both patches are there ,
> fs/proc: report eip/esp in /prod/PID/stat for coredumping
>
> and also task.state has already set PF_DUMPCORE as it got the sigabrt
> signal.
John Ogness
going through dcache.c and related code; hopefully
> this time I will get the documentation into postable shape ;-/
Thank you for all your help in getting these changes cleaned and
correctly implemented so quickly.
I've reviewed your latest trylock loop removal patches and found only 1
minor issue. I'll post that separately.
John Ogness
continue;
> }
> -
> - inode = dentry->d_inode;
> - if (inode && unlikely(!spin_trylock(&inode->i_lock))) {
> - d_shrink_add(dentry, list);
> - spin_unlock(&dentry->d_lock);
> - if (parent)
> - spin_unlock(&parent->d_lock);
> - continue;
> - }
> -
> + d_shrink_del(dentry);
> + parent = dentry->d_parent;
> __dentry_kill(dentry);
> -
> + if (parent == dentry)
> + continue;
> /*
>* We need to prune ancestors too. This is necessary to prevent
>* quadratic behavior of shrink_dcache_parent(), but is also
John Ogness
bool can_free = false;
> + rcu_read_unlock();
> d_shrink_del(dentry);
> if (dentry->d_lockref.count < 0)
> can_free = dentry->d_flags & DCACHE_MAY_FREE;
> @@ -1054,6 +1050,7 @@ static void shrink_dentry_list(struct list_head *list)
> dentry_free(dentry);
> continue;
> }
> + rcu_read_unlock();
> d_shrink_del(dentry);
> parent = dentry->d_parent;
> __dentry_kill(dentry);
John Ogness
try to
squish CPU and Task IDs into 32 bits.
What about introducing a caller_id option to always only print the CPU
ID? Or do you really need Task _and_ CPU?
John Ogness
compact,
It is supported to provide loglevels for CONT messages. The loglevel is
then only used if the append fails:
pr_cont(KERN_INFO "message part");
I don't know if we want to go down that path. But it is supported.
John Ogness
This driver provides UIO access to memory of a peripheral connected
to the Freescale enhanced local bus controller (eLBC) interface
using the general purpose chip-select mode (GPCM).
Signed-off-by: John Ogness
---
There are currently drivers that use FCM and UPM modes. But there
are no drivers
transfer using a buffer
that is already setup to be used for a DMA transfer.
This patch adds a spinlock to synchronize the rx_running flag and
close the above mentioned window.
Signed-off-by: John Ogness
---
drivers/tty/serial/8250/8250_omap.c | 65 ++-
1 file
: John Ogness
---
drivers/dma/edma.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index bf09db7..88853af 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -300,8 +300,7 @@ static int edma_dma_pause(struct dma_chan
stopping channel it is
ensured that no completion event will be generated after the stop.
Signed-off-by: John Ogness
---
arch/arm/common/edma.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 5662a87..873dbfc 100644
--- a/arch/arm
ties as identified by the RT policy.
>>
>> DL is -1, 0 is still very much FIFO/FF
>
> but it can't be set. The lowest we can set is 1. Is this a bug then?
I think it is important to clarify if you are talking about userspace or
kernel. They are different. For userspace 1(low)-99(high) is
allowed. For kernel 0(high)-98(low) is used.
John Ogness
lock-up" [0]
I'm responding to it here because it really belongs in this thread.
On 2019-03-12, Petr Mladek wrote:
> On Tue 2019-03-12 09:17:49, John Ogness wrote:
>> The current printk implementation is handling all console printing as
>> best effort. Trying hard enou
nsole_sem->lock
>
> deadlock report from LG, if I'm not mistaken.
The main drawback of printk_safe is the safe buffers, which, aside from
bogus timestamping, may never make it back to the printk log buffer.
With the new ring buffer the safe buffers are not needed, even in the
recursive situation. As you are pointing out, the notification/wake
component of printk_safe will still be needed. I will leave that (small)
part in printk_safe.c.
John Ogness
t each of the above series as RFCv2 because I expect we still
need some discussion. Especially if I post the fully lockless version of
the ringbuffer.
I have taken a *lot* of notes about things that need changing during
this thread. I think a lot of great feedback has come out of this
RFC. Thank you to everyone that responded (publicly and privately)! I'll
need several weeks before the RFCv2 for the ringbuffer is ready.
John Ogness
k kernel thread.
>
> This series is somehow making worst when using ttyAMA0. I haven't see
> any mangling with 4.19-rt.
I will setup some tests using systemd on 4.19 and 5.0 to see if I can
see what is going on. It seems there may be some synchronization missing
between the printk kernel thread and /dev/console.
John Ogness
priorities are in the range from 1 to 99.
>
> Reported-by: John Ogness
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> Documentation/scheduler/sched-rt-group.txt | 2 +-
> include/linux/sched/prio.h | 2 +-
> kernel/sched/cpupri.h | 2
ly from
the ringbuffer. The proposed ringbuffer requires the reader (printk) to
have its own buffers.
We may be able to find an alternate solution here as well if that is
desired.
John Ogness
tput. With your proposal, it wouldn't be seen that
so many intermediate messages are dropped. Only at the end of the output
the user is presented with some huge dropped number.
With my implementation if you see 2 printk lines together you can be
sure that nothing was dropped between those two lines. I think that is
more valuable than having the possibility of maybe losing a few less
messages in a flood situation.
John Ogness
eq);
>
> This looks like an alien. The code is supposed to write one message
> from the given buffer. And some huge job is well hidden there.
This is a very simple implementation of a printk kthread. It probably
makes more sense to have a printk kthread per console. That would allow
fast consoles to not be penalized by slow consoles. Due to the
per-console seq tracking, the code would already support it.
> In addition, the code is actually recursive. It will become
> clear when it is deduplicated as suggested above. We should
> avoid it when it is not necessary. Note that recursive code
> is always more prone to mistakes and it is harder to think of.
Agreed.
> I guess that the motivation is to do everything from the printk
> kthread. Is it really necessary? register_console() takes
> console_lock(). It has to be sleepable context by definition.
It is not necessary. It is desired. Why should _any_ task be punished
with console writing? That is what the printk kthread is for.
John Ogness
;,
> + console_dropped_cnt);
> + console_dropped_cnt = 0;
> + }
> +
My only objection to this is that the "messages dropped" only comes if a
non-supressed message comes. So information about dropped information
may never get printed unless some task prints something non-supressed.
Imagine a situation where I am expecting a message to come, but don't
see it because it was dropped. But if no more non-supressed messages
come, I see neither the expected message nor the dropped message.
John Ogness
the logbuf,
> regardless of msg->level. IOW, if lost_messages was set then
> suppress_message_printing(msg->level) was not even invoked. Yes, that
> would sometimes print several "debugging noise" messages, but the main
> part was that I would have "%llu
here is a simple fix for this. We could print the warning
> also when all messages are proceed and we are about to leave the
> for-cycle.
Yes! That is the piece that was missing!
John Ogness
tk to important and non-important so that
we can optimize both. _That_ is the heart of this series.
John Ogness
cters from directly printed messages.
That is exactly what console_atomic_lock() (actually prb_lock) is!
John Ogness
[0] https://lkml.kernel.org/r/87pnrvs707@linutronix.de
() usage with prb_read_valid_*()
functions, which provide a start sequence number to search from.
Fixes: 896fbe20b4e2333fb55 ("printk: use the lockless ringbuffer")
Reported-by: kernel test robot
Reported-by: J. Avila
Signed-off-by: John Ogness
---
patch against next-20210211
v2: Abort and
the useless @active flag, I am not sure what else
you would want to change. Perhaps just fixup the comments/documentation
to clarify these interfaces and what their purpose is.
John Ogness
On 2021-02-24, John Ogness wrote:
> The @active flag is useless. It should be removed.
I would like to clarify my statement, because the @active flag _did_
protect the arch/um dumper until now. (Although it didn't actually
matter because arch/um does not have SMP or preemption suppo
On 2021-02-08, Sergey Senozhatsky wrote:
>> Can we please also ask the kernel test robot to test this patch?
Oliver Sang from LKP was able to verify that the RCU stall problem is
not seen anymore on their side. See his response below.
Thanks Oliver!
John Ogness
On 2021-02-10, Olive
* message it will notice and appropriately update
>* syslog_seq and reset syslog_partial.
>*/
> logbuf_unlock_irq();
> return 0;
> }
> if (info.seq != syslog_seq) {
> /* messages are gone, move to first one */
> syslog_seq = info.seq;
> syslog_partial = 0;
> }
John Ogness
The logic for finding records to fit into a buffer is the same for
kmsg_dump_get_buffer() and syslog_print_all(). Introduce a helper
function find_first_fitting_seq() to handle this logic.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 87 --
1
ck" only change to safe buffer usage
- fixup safe buffer usage and redundance in separate patches
(patches 13 and 14)
- update comments and commit messages as requested
John Ogness
[0] https://lkml.kernel.org/r/20210126211551.26536-1-john.ogn...@linutronix.de
John Ogness (14):
printk:
. This simplifies the
transition to removing @logbuf_lock. Once @logbuf_lock and the
safe buffers are removed, @syslog_lock can change to spin_lock.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 41 +
1 file changed, 37 insertions(+), 4 deletions
increase it to 4096. With a larger buffer size, multi-line
records that are nearly LOG_LINE_MAX in length will have a better
chance of being fully printed. (When formatting a record for the
console, each line of a multi-line record is prepended with a copy
of the prefix.)
Signed-off-by: John Ogness
The kmsg_dumper can be called from any context and CPU, possibly
from multiple CPUs simultaneously. Since a static buffer is used
to retrieve the kernel logs, this buffer must be protected against
simultaneous dumping.
Cc: Richard Weinberger
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
move this common logic into a
separate helper function.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
include/linux/kmsg_dump.h | 2 +-
kernel/printk/printk.c| 60 +--
2 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/include/linux
kmsg_dump_rewind_nolock() locklessly reads @clear_seq. However,
this is not done atomically. Since @clear_seq is 64-bit, this
cannot be an atomic operation for all platforms. Therefore, use
a seqcount_latch to allow readers to always read a consistent
value.
Signed-off-by: John Ogness
Reviewed
kmsg_dump_rewind() and kmsg_dump_get_line() are lockless, so there is
no need for _nolock() variants. Remove these functions and switch all
callers of the _nolock() variants.
The functions without _nolock() were chosen because they are already
exported to kernel modules.
Signed-off-by: John
by @console_lock.
Signed-off-by: John Ogness
---
kernel/printk/internal.h| 4 +-
kernel/printk/printk.c | 116
kernel/printk/printk_safe.c | 29 +++--
3 files changed, 47 insertions(+), 102 deletions(-)
diff --git a/kernel/printk/internal.h b
struct kmsg_dumper still contains some fields that were used to
iterate the old ringbuffer. They are no longer used. Remove them
and update the struct documentation.
Signed-off-by: John Ogness
---
include/linux/kmsg_dump.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a
.
Signed-off-by: John Ogness
---
arch/powerpc/kernel/nvram_64.c | 12 ++--
arch/powerpc/platforms/powernv/opal-kmsg.c | 3 +-
arch/powerpc/xmon/xmon.c | 6 +-
arch/um/kernel/kmsg_dump.c | 5 +-
drivers/hv/vmbus_drv.c | 5
buf_lock writer-protection of
ringbuffer")
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c7239d169bbe..411787b900ac 100644
--- a/kernel/printk/printk.c
+++ b/ke
@user->seq is indirectly protected by @logbuf_lock. Once @logbuf_lock
is removed, @user->seq will be no longer safe from an atomicity point
of view.
In preparation for the removal of @logbuf_lock, change it to
atomic64_t to provide this safety.
Signed-off-by: John Ogness
---
kernel/
Upon registering a console, safe buffers are activated when setting
up the sequence number to replay the log. However, these are already
protected by @console_sem and @syslog_lock. Remove the unnecessary
safe buffer usage.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 10 +++---
1
kmsg_dump() is open coding the kmsg_dump_rewind(). Call
kmsg_dump_rewind() instead.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 744b806d5457..23d525e885e7
that logbuf_lock_irqsave() should be replaced
with logbuf_lock_irq(). And then locking @syslog_lock will not need to
disable interrupts.
John Ogness
[0]
https://github.com/schwabe/davej-history/commit/f91c3404ba16c88cdb33824bf0249c6263cd4465#diff-84036d1e27f4207c783a3b876aef4e45340d30f43b1319bca382f5775a9b14beL348
intk, for rcutorture it would be
more appropriate to do something like:
dmesg > /tmpfile
cat /tmpfile > /dev/kmsg
to avoid the endless read/feed cycle.
John Ogness
These multi-timestamp lines are odd. And they are almost exactly 124
seconds apart. What is going on there? The investigation continues...
John Ogness
nder if it is something that we have already fixed.
Unfortunately when I switch to Linus's master, the error messages go
away. So it probably won't trigger.
However, I did forward port all printk changes and I am still seeing the
same behavior.
I think once I get at /dev/kmsg, there should be some clarity.
John Ogness
On 2021-01-28, John Ogness wrote:
> [ 903.189448][ T356] [ 778.825864] [ 655.250559] [ 531.607066] [
> 407.120936] tasks-torture:torture_onoff task: online 0 failed: errno -5
So I at least found out what these multi-timestamp messages are (thanks
to reading /dev/kmsg). lkp is dir
LE_LOG_MAX needs to be set to:
PREFIX_MAX * LOG_LINE_MAX + 1
and we should be specifying LOG_LINE_MAX instead of
CONSOLE_LOG_MAX. record_print_text() adds up to PREFIX_MAX for every
'\n' in the message.
I was initially confused by this, which led to my patch [0] to fix
it. But t
On 2021-01-29, Petr Mladek wrote:
>> The logic for finding records to fit into a buffer is the same for
>> kmsg_dump_get_buffer() and syslog_print_all(). Introduce a helper
>> function find_first_fitting_seq() to handle this logic.
>>
>> Signed-off-by: John Og
unmodified code
> above, and the comment, we proceed to the call to kmsg_dump_get_buffer()
> only in the panic path. Code in the panic path prior to invoking kmsg_dump()
> ensures that we are single-threaded on a single CPU. So I think everything
> is good here without the new spin lock. The subsequent call to
> hyperv_report_panic_msg() also assumes that we are single-threaded.
You are correct. I will withdraw this patch from the series. Thanks for
the feedback.
John Ogness
seq_read(void)
{
unsigned long flags;
raw_spin_lock_irqsave(&syslog_lock, flags);
seq = syslog_seq;
raw_spin_unlock_irqrestore(&syslog_lock, flags);
return seq;
}
Then change the code to:
error = wait_event_interruptible(log_wait,
prb_read_valid(prb, read_syslog_seq(), NULL));
register_console() could also make use of the function. (That is why I
am suggesting the flags variant.)
John Ogness
On 2021-02-01, Petr Mladek wrote:
>> Rather than store the iterator information into the registered
>> kmsg_dump structure, create a separate iterator structure. The
>> kmsg_dump_iter structure can reside on the stack of the caller,
>> thus allowing lockless use of the kmsg_dump functions.
>>
>>
lock to synchronize the
>> kmsg_dump call and temporary buffer usage.
>>
>> Signed-off-by: John Ogness
>> ---
>> arch/um/kernel/kmsg_dump.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/
o synchronize the
>>>> kmsg_dump call and temporary buffer usage.
>>>>
>>>> Signed-off-by: John Ogness
>>>> ---
>>>> arch/um/kernel/kmsg_dump.c | 8
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>
ng some
Kconfig settings from that subsystem. Headers exist to make information
available to external code. Kconfig (particularly for a subsystem) exist
to configure that subsystem.
But my feeling on this may be misguided. Is it generally accepted in the
kernel that any code can use Kconfig settings of any other code?
John Ogness
mit d43ff430f434
("printk: guard the amount written per line by devkmsg_read()") show any
motivation for using printk.h.
I am fine with moving them out. The only consequences could be
out-of-tree modules breaking, but do we care about that?
John Ogness
[0] https://lkml.kernel.org/r/202101262
On 2021-02-02, Petr Mladek wrote:
> On Tue 2021-01-26 22:21:50, John Ogness wrote:
>> Since the ringbuffer is lockless, there is no need for it to be
>> protected by @logbuf_lock. Remove @logbuf_lock.
>>
>> This means that printk_nmi_direct and printk_safe_flush_on_p
the
current situation is not pretty, I do not think it needs to be rushed
for 5.11. It is an inefficiency that occurs if the average message size
greatly exceeds 32 bytes and the ringbuffer is being blasted by new
messages and userspace is reading the ringbuffer.
John Ogness
[0] https://lkml.ker
The kmsg_dumper can be called from any context and CPU, possibly
from multiple CPUs simultaneously. Since a static buffer is used
to retrieve the kernel logs, this buffer must be protected against
simultaneous dumping. Skip dumping if another context is already
dumping.
Signed-off-by: John Ogness
pdate kmsg_dumpers to use their own kmsg_dump_iter (and
initialize it with kmsg_dump_rewind() if necessary)
John Ogness
[0] https://lkml.kernel.org/r/20210218081817.28849-1-john.ogn...@linutronix.de
[1] https://lkml.kernel.org/r/YDeZAA08NKCHa4s%2F@alley
John Ogness (15):
um: synchronize kmsg_dumper
. Release the
protection in between setting the buffer and the actual writing in
order for a possible panic (immediate write) to be written during
the scheduling of a previous oops (delayed write).
Signed-off-by: John Ogness
---
drivers/mtd/mtdoops.c | 12 +++-
1 file changed, 11 insertions
struct kmsg_dumper still contains some fields that were used to
iterate the old ringbuffer. They are no longer used. Remove them
and update the struct documentation.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
include/linux/kmsg_dump.h | 5 +++--
1 file changed, 3 insertions(+), 2
buf_lock writer-protection of
ringbuffer")
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 575a34b88936..77ae2704e979 100644
--- a/kernel/p
move this common logic into a
separate helper function.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
include/linux/kmsg_dump.h | 2 +-
kernel/printk/printk.c| 62 +--
2 files changed, 34 insertions(+), 30 deletions(-)
diff --git a/include/linux
@user->seq is indirectly protected by @logbuf_lock. Once @logbuf_lock
is removed, @user->seq will be no longer safe from an atomicity point
of view.
In preparation for the removal of @logbuf_lock, change it to
atomic64_t to provide this safety.
Signed-off-by: John Ogness
Reviewed-by
/powerpc/platforms/powernv/opal-kmsg.c
- drivers/hv/vmbus_drv.c
The other 2 kmsg_dump users also do not rely on @active:
(hard-code @active to always be true)
- arch/powerpc/xmon/xmon.c
- kernel/debug/kdb/kdb_main.c
Therefore, @active can be removed.
Signed-off-by: John Ogness
---
arch
Upon registering a console, safe buffers are activated when setting
up the sequence number to replay the log. However, these are already
protected by @console_sem and @syslog_lock. Remove the unnecessary
safe buffer usage.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk
kmsg_dump_rewind_nolock() locklessly reads @clear_seq. However,
this is not done atomically. Since @clear_seq is 64-bit, this
cannot be an atomic operation for all platforms. Therefore, use
a seqcount_latch to allow readers to always read a consistent
value.
Signed-off-by: John Ogness
Reviewed
kmsg_dump_rewind() and kmsg_dump_get_line() are lockless, so there is
no need for _nolock() variants. Remove these functions and switch all
callers of the _nolock() variants.
The functions without _nolock() were chosen because they are already
exported to kernel modules.
Signed-off-by: John
structure. For kmsg_dumpers, this also means adding a
call to kmsg_dump_rewind() to initialize the iterator.
All this is in preparation for removal of @logbuf_lock.
Signed-off-by: John Ogness
---
arch/powerpc/kernel/nvram_64.c | 14 +++---
arch/powerpc/platforms/powernv/opal-kmsg.c | 3
increase it to 4096. With a larger buffer size, multi-line
records that are nearly LOG_LINE_MAX in length will have a better
chance of being fully printed. (When formatting a record for the
console, each line of a multi-line record is prepended with a copy
of the prefix.)
Signed-off-by: John Ognes
The logic for finding records to fit into a buffer is the same for
kmsg_dump_get_buffer() and syslog_print_all(). Introduce a helper
function find_first_fitting_seq() to handle this logic.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 87
. This simplifies the
transition to removing @logbuf_lock. Once @logbuf_lock and the
safe buffers are removed, @syslog_lock can change to spin_lock.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 41 +
1 file changed, 37 insertions(+), 4 deletions
Since the ringbuffer is lockless, there is no need for it to be
protected by @logbuf_lock. Remove @logbuf_lock.
@console_seq, @exclusive_console_stop_seq, @console_dropped are
protected by @console_lock.
Signed-off-by: John Ogness
---
kernel/printk/internal.h| 4 +-
kernel/printk
n sleep,
causing the system to hang. Convert the spinlock_t to the
non-sleeping raw_spinlock_t.
Signed-off-by: John Ogness
---
arch/powerpc/platforms/powermac/low_i2c.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/low_i2c.c
team. But most likely we will just
re-instate the dumper parameter in the callback.
I apologize for the lack of care on my part.
John Ogness
On 2021-02-26, kernel test robot wrote:
> Hi John,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on next-20
ether it is
>safe to do more dumps in parallel. Only the callback knows
>whether it is called only during panic() when no locks
>are needed.
Agreed. I implemented this part for the v3 series.
John Ogness
e.
It looks like you have not applied the fix yet:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=08d60e5999540110576e7c1346d486220751b7f9
John Ogness
ry barriers was helpful for
identifying, proving, and testing a minimal set of pairs (on arm64), but
all will be folded into full cmpxchg()'s for the next version.
John Ogness
The .bss section for the h8300 is relatively small. A value of
CONFIG_LOG_BUF_SHIFT that is larger than 19 will create a static
printk ringbuffer that is too large. Limit the range appropriately
for the H8300.
Reported-by: kernel test robot
Signed-off-by: John Ogness
---
based on next-20200811
entation/admin-guide/kdump/vmcoreinfo.rst
> - scripts/gdb/linux/dmesg.py
>
> I believe this commit removed log_first_idx, so all of the above
> probably need to be fixed up, too.
Thanks for pointing this out! I will get to work on a patch for this.
John Ogness
like it
shouldn't add too much complexity.
I will continue to refine my working version and post a patch so that we
have something to work with. This looks to be the most promising way
forward. Thanks.
John Ogness
output generally, but
also addresses the lockless printk issue related to log_cont.
John Ogness
[0] https://lkml.kernel.org/r/20200717234818.8622-1-john.ogn...@linutronix.de
John Ogness (5):
printk: implement pr_cont_t
sysrq: use pr_cont_t for cont messages
workqueue: use pr_cont_t for con
Use the new pr_cont_t mechanism.
Signed-off-by: John Ogness
---
lib/locking-selftest.c | 85 ++
1 file changed, 44 insertions(+), 41 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 14f44f59e733..3131c517ae62 100644
--- a
Use the new pr_cont_t mechanism.
Signed-off-by: John Ogness
---
kernel/locking/lockdep.c | 463 +++
1 file changed, 275 insertions(+), 188 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 2fad21d345b0..3210f244cb94 100644
t");
pr_cont_append(&c, " continued");
pr_cont_end(&c);
Signed-off-by: John Ogness
---
include/linux/printk.h | 19 ++
kernel/printk/printk.c | 137 +
2 files changed, 156 insertions(+)
diff --git a/include/linux/printk.h b/
Use the new pr_cont_t mechanism.
Signed-off-by: John Ogness
---
drivers/tty/sysrq.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index a8e39b2cdd55..be2aa816c444 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
Use the new pr_cont_t mechanism.
Signed-off-by: John Ogness
---
kernel/workqueue.c | 71 +-
1 file changed, 39 insertions(+), 32 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c41c3c17b86a..472370f02001 100644
--- a/kernel
uffers and could even track the users
lockdep style.
But this discussion has little to do with the API. These are
implementation details that may end up under the hood of the current
mainline API.
John Ogness
On 2020-08-20, Joe Perches wrote:
> And here it seems like the 'for (j =...)' loop is superfluous.
AFAICT it is skipping duplicate entries. In the case of a duplicate,
only the first one is printed.
> Maybe something like this would be reasonable:
> ---
> drivers/tty/sysrq.c | 19 ++
1 - 100 of 561 matches
Mail list logo
