On (10/25/18 08:28), Heiko Carstens wrote:
[..]
> > int loglevel_save = console_loglevel;
> > - console_unblank();
> > - oops_in_progress = 0;
> > - /*
> > -* OK, the message is on the console. Now we call printk()
> > -* without
On (10/25/18 08:28), Heiko Carstens wrote:
[..]
> > int loglevel_save = console_loglevel;
> > - console_unblank();
> > - oops_in_progress = 0;
> > - /*
> > -* OK, the message is on the console. Now we call printk()
> > -* without
On (10/24/18 22:27), Rafael David Tinoco wrote:
> static unsigned long location_to_obj(struct page *page, unsigned int obj_idx)
> {
> - unsigned long obj;
> + unsigned long obj, pfn;
> +
> + pfn = page_to_pfn(page);
> +
> + if (unlikely(OBJ_OVERFLOW(pfn)))
> + BUG();
On (10/24/18 22:27), Rafael David Tinoco wrote:
> static unsigned long location_to_obj(struct page *page, unsigned int obj_idx)
> {
> - unsigned long obj;
> + unsigned long obj, pfn;
> +
> + pfn = page_to_pfn(page);
> +
> + if (unlikely(OBJ_OVERFLOW(pfn)))
> + BUG();
On (10/24/18 13:30), Sergey Senozhatsky wrote:
> - * OK, the message is on the console. Now we call printk()
> - * without oops_in_progress set so that printk will give klogd
> - * a poke. Hold onto
On (10/24/18 13:30), Sergey Senozhatsky wrote:
> - * OK, the message is on the console. Now we call printk()
> - * without oops_in_progress set so that printk will give klogd
> - * a poke. Hold onto
eplace
that printk(" ").
Signed-off-by: Sergey Senozhatsky
---
arch/s390/mm/fault.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index 2b8f32f56e0c..244993dc3c70 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/faul
eplace
that printk(" ").
Signed-off-by: Sergey Senozhatsky
---
arch/s390/mm/fault.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index 2b8f32f56e0c..244993dc3c70 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/faul
On (10/23/18 21:04), Sergey Senozhatsky wrote:
>
> Seems that s390 is the only arch which defines its own bust_spinlocks().
> Not sure why... Just to play games with console_loglevel?
>
> ---
>
> void bust_spinlocks(int yes)
> {
> if (yes) {
>
On (10/23/18 21:04), Sergey Senozhatsky wrote:
>
> Seems that s390 is the only arch which defines its own bust_spinlocks().
> Not sure why... Just to play games with console_loglevel?
>
> ---
>
> void bust_spinlocks(int yes)
> {
> if (yes) {
>
On (10/23/18 20:54), Sergey Senozhatsky wrote:
> So I did look at what lib/bust_spinlocks.c does; and I agree that waking
> up klogd makes little sense, on the other hand it just sets per-cpu
> pending bit, so not a big deal. console_unlock() should do there the
>
On (10/23/18 20:54), Sergey Senozhatsky wrote:
> So I did look at what lib/bust_spinlocks.c does; and I agree that waking
> up klogd makes little sense, on the other hand it just sets per-cpu
> pending bit, so not a big deal. console_unlock() should do there the
>
On (10/23/18 13:07), Petr Mladek wrote:
> Though this looks a bit weird.
>
> I have just realized that console_unblank() is called by
> bust_spinlocks(0) and does basically the same as
> console_flush_on_panic(). Also it does not make much
> sense wake_up_klogd() there. Finally, it seems to be
>
On (10/23/18 13:07), Petr Mladek wrote:
> Though this looks a bit weird.
>
> I have just realized that console_unblank() is called by
> bust_spinlocks(0) and does basically the same as
> console_flush_on_panic(). Also it does not make much
> sense wake_up_klogd() there. Finally, it seems to be
>
On (10/16/17 10:15), Steven Rostedt wrote:
> On Mon, 16 Oct 2017 22:13:05 +0900
> Sergey Senozhatsky wrote:
>
> > just "brainstorming" it... with some silly ideas.
> >
> > pushing the data from NMI panic might look like we are replacing one
> > deadl
On (10/16/17 10:15), Steven Rostedt wrote:
> On Mon, 16 Oct 2017 22:13:05 +0900
> Sergey Senozhatsky wrote:
>
> > just "brainstorming" it... with some silly ideas.
> >
> > pushing the data from NMI panic might look like we are replacing one
> > deadl
On (10/16/18 14:54), Peter Zijlstra wrote:
>
> No, no wakups. irq_work to wake the printk-thread, at most.
>
There are cases when we probably prefer to be in "direct printk" mode.
E.g. sysrq or late PM stages (probably).
Doing irq_work->wake_up_process->printk_kthread from sysrq probably
might
On (10/16/18 14:54), Peter Zijlstra wrote:
>
> No, no wakups. irq_work to wake the printk-thread, at most.
>
There are cases when we probably prefer to be in "direct printk" mode.
E.g. sysrq or late PM stages (probably).
Doing irq_work->wake_up_process->printk_kthread from sysrq probably
might
On (10/19/18 19:35), Tetsuo Handa wrote:
> >
> > OK, that's a fair point. There was a patch from FB, which would allow us
> > to set a log_level on per-console basis. So the noise goes to heav^W net
> > console; only critical stuff goes to the serial console (if I recall it
> > correctly). I'm
On (10/19/18 19:35), Tetsuo Handa wrote:
> >
> > OK, that's a fair point. There was a patch from FB, which would allow us
> > to set a log_level on per-console basis. So the noise goes to heav^W net
> > console; only critical stuff goes to the serial console (if I recall it
> > correctly). I'm
On (10/21/18 11:09), Daniel Wang wrote:
>
> Just got back from vacation. Thanks for the continued discussion. Just so
> I understand the current state. Looks like we've got a pretty good explanation
> of what's going on (though not completely sure), and backporting Steven's
> patches is still the
On (10/21/18 11:09), Daniel Wang wrote:
>
> Just got back from vacation. Thanks for the continued discussion. Just so
> I understand the current state. Looks like we've got a pretty good explanation
> of what's going on (though not completely sure), and backporting Steven's
> patches is still the
On (10/18/18 20:58), Tetsuo Handa wrote:
> >
> > A knob might do.
> > As well as /proc/sys/kernel/printk tweaks, probably. One can even add
> > echo "a b c d" > /proc/sys/kernel/printk to .bashrc and adjust printk
> > console levels on login and rollback to old values in .bash_logout
> > May be.
On (10/18/18 20:58), Tetsuo Handa wrote:
> >
> > A knob might do.
> > As well as /proc/sys/kernel/printk tweaks, probably. One can even add
> > echo "a b c d" > /proc/sys/kernel/printk to .bashrc and adjust printk
> > console levels on login and rollback to old values in .bash_logout
> > May be.
On (10/18/18 09:56), Michal Hocko wrote:
> On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
> [...]
> > and let's hear from MM people what they can suggest.
> >
> > Michal, Andrew, Johannes, any thoughts?
>
> I have already stated my position. Let's
On (10/18/18 09:56), Michal Hocko wrote:
> On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
> [...]
> > and let's hear from MM people what they can suggest.
> >
> > Michal, Andrew, Johannes, any thoughts?
>
> I have already stated my position. Let's
On (10/18/18 14:26), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> > To my personal taste, "baud rate of registered and enabled consoles"
> > approach is drastically more relevant than hard coded 10 * HZ or
> > 60 * HZ magic numbers... But not in the form of that
On (10/18/18 14:26), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> > To my personal taste, "baud rate of registered and enabled consoles"
> > approach is drastically more relevant than hard coded 10 * HZ or
> > 60 * HZ magic numbers... But not in the form of that
On (10/18/18 11:46), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> >
> > int printk_ratelimit_interval(void)
> > {
> >int ret = DEFAULT_RATELIMIT_INTERVAL;
> >struct tty_driver *driver = NULL;
> >speed_t min_baud
On (10/18/18 11:46), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> >
> > int printk_ratelimit_interval(void)
> > {
> >int ret = DEFAULT_RATELIMIT_INTERVAL;
> >struct tty_driver *driver = NULL;
> >speed_t min_baud
On (10/17/18 11:04), Mathieu Desnoyers wrote:
> >>
> >>> if (WARN_ON(x))
> >>> return;
> >>
> >> Given that this somewhat MM-related, I'd may be say VM_WARN_ON().
>
> I notice that VM_WARN_ON() casts the result of WARN_ON() to (void), so it
> cannot be used in a if () statement.
>
On (10/17/18 11:04), Mathieu Desnoyers wrote:
> >>
> >>> if (WARN_ON(x))
> >>> return;
> >>
> >> Given that this somewhat MM-related, I'd may be say VM_WARN_ON().
>
> I notice that VM_WARN_ON() casts the result of WARN_ON() to (void), so it
> cannot be used in a if () statement.
>
On (10/17/18 09:57), Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 01:32:51PM +0900, Sergey Senozhatsky wrote:
> > This probably will be a bit more hairy. logbuf is written to by many
> > sources and is read from by many sides, including user-space [both read()
> > and writ
On (10/17/18 09:57), Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 01:32:51PM +0900, Sergey Senozhatsky wrote:
> > This probably will be a bit more hairy. logbuf is written to by many
> > sources and is read from by many sides, including user-space [both read()
> > and writ
On (10/17/18 12:28), Michal Hocko wrote:
> > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > that patch is appropriate because that patch does not ratelimit
> >
> > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d,
> > oom_score_adj=%hd\n"
> >
On (10/17/18 12:28), Michal Hocko wrote:
> > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > that patch is appropriate because that patch does not ratelimit
> >
> > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d,
> > oom_score_adj=%hd\n"
> >
On (10/16/18 14:04), Sergey Senozhatsky wrote:
>
> Fix this by setting oops_in_progress before console_flush_on_panic(),
> so re-entrant console drivers will trylock the port->lock instead of
> spinning on it forever.
>
Just a small note:
Regardless of what's going to ha
On (10/16/18 14:04), Sergey Senozhatsky wrote:
>
> Fix this by setting oops_in_progress before console_flush_on_panic(),
> so re-entrant console drivers will trylock the port->lock instead of
> spinning on it forever.
>
Just a small note:
Regardless of what's going to ha
On (10/16/18 14:54), Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 09:27:34PM +0900, Sergey Senozhatsky wrote:
> > per-CPU printk_safe _semi-magic_ makes some things simple to handle.
> > We can't just remove per-CPU buffers and add a wake_up_process() at
> > the b
On (10/16/18 14:54), Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 09:27:34PM +0900, Sergey Senozhatsky wrote:
> > per-CPU printk_safe _semi-magic_ makes some things simple to handle.
> > We can't just remove per-CPU buffers and add a wake_up_process() at
> > the b
Hi Mathieu,
On (10/16/18 15:17), Mathieu Desnoyers wrote:
>
> Therefore, only an internal kernel bug between vm_map_user_ram() and
> vm_unmap_user_ram() should trigger the BUG_ON(). No user input is passed
> to vm_unmap_user_ram().
>
> Now, let's look at vm_map_user_ram(). It calls
Hi Mathieu,
On (10/16/18 15:17), Mathieu Desnoyers wrote:
>
> Therefore, only an internal kernel bug between vm_map_user_ram() and
> vm_unmap_user_ram() should trigger the BUG_ON(). No user input is passed
> to vm_unmap_user_ram().
>
> Now, let's look at vm_map_user_ram(). It calls
On (10/16/18 14:30), Steven Rostedt wrote:
> > +void vm_unmap_user_ram(const void *mem, unsigned int count)
> > +{
> > + unsigned long size = (unsigned long)count << PAGE_SHIFT;
> > + unsigned long addr = (unsigned long)mem;
> > + struct vmap_area *va;
> > +
> > + might_sleep();
> > +
On (10/16/18 14:30), Steven Rostedt wrote:
> > +void vm_unmap_user_ram(const void *mem, unsigned int count)
> > +{
> > + unsigned long size = (unsigned long)count << PAGE_SHIFT;
> > + unsigned long addr = (unsigned long)mem;
> > + struct vmap_area *va;
> > +
> > + might_sleep();
> > +
On (10/16/18 09:27), Peter Zijlstra wrote:
>
> So I really _really_ hate all this. Utterly detest it.
I learned a new word today - detest. I can haz re-entrant consoles now please?
> That whole magic 'safe' printk buffer crap is just that crap.
No, I don't see it this way; printk_safe is
On (10/16/18 09:27), Peter Zijlstra wrote:
>
> So I really _really_ hate all this. Utterly detest it.
I learned a new word today - detest. I can haz re-entrant consoles now please?
> That whole magic 'safe' printk buffer crap is just that crap.
No, I don't see it this way; printk_safe is
On (10/16/18 09:23), Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 02:04:24PM +0900, Sergey Senozhatsky wrote:
> > Hello,
> >
> >
> > RFC
> >
> >
> > The patch set reduces the number of ways serial consoles
> > can deadlock t
On (10/16/18 09:23), Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 02:04:24PM +0900, Sergey Senozhatsky wrote:
> > Hello,
> >
> >
> > RFC
> >
> >
> > The patch set reduces the number of ways serial consoles
> > can deadlock t
Hi Mathieu,
On (10/10/18 15:19), Mathieu Desnoyers wrote:
[..]
> +SYSCALL_DEFINE4(cpu_opv, struct cpu_op __user *, ucpuopv, int, cpuopcnt,
> + int, cpu, int, flags)
> +{
[..]
> +again:
> + ret = cpu_opv_pin_pages(cpuopv, cpuopcnt, _ptrs);
> + if (ret)
> + goto end;
Hi Mathieu,
On (10/10/18 15:19), Mathieu Desnoyers wrote:
[..]
> +SYSCALL_DEFINE4(cpu_opv, struct cpu_op __user *, ucpuopv, int, cpuopcnt,
> + int, cpu, int, flags)
> +{
[..]
> +again:
> + ret = cpu_opv_pin_pages(cpuopv, cpuopcnt, _ptrs);
> + if (ret)
> + goto end;
Switch to uart_port_lock macros:
- use uart_port_lock_for_printk()/uart_port_unlock_after_printk() in
serial8250_console_write().
- use uart_port_lock_*()/uart_port_unlock_*() elsewhere.
Signed-off-by: Sergey Senozhatsky
---
drivers/tty/serial/8250/8250_core.c | 8 +--
drivers/tty/serial
Switch to uart_port_lock macros:
- use uart_port_lock_for_printk()/uart_port_unlock_after_printk() in
serial8250_console_write().
- use uart_port_lock_*()/uart_port_unlock_*() elsewhere.
Signed-off-by: Sergey Senozhatsky
---
drivers/tty/serial/8250/8250_core.c | 8 +--
drivers/tty/serial
ler. This macro should address the issue.
Signed-off-by: Sergey Senozhatsky
---
include/linux/serial_core.h | 48 +
1 file changed, 48 insertions(+)
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 047fa67d039b..acc6966fea8e 100644
Make printk_safe_enter_irqsave()/etc macros available to the
rest of the kernel.
Signed-off-by: Sergey Senozhatsky
---
include/linux/printk.h | 40 +
kernel/printk/internal.h| 37 --
kernel/printk/printk_safe.c | 6
ler. This macro should address the issue.
Signed-off-by: Sergey Senozhatsky
---
include/linux/serial_core.h | 48 +
1 file changed, 48 insertions(+)
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 047fa67d039b..acc6966fea8e 100644
Make printk_safe_enter_irqsave()/etc macros available to the
rest of the kernel.
Signed-off-by: Sergey Senozhatsky
---
include/linux/printk.h | 40 +
kernel/printk/internal.h| 37 --
kernel/printk/printk_safe.c | 6
RFC I modify only 8250 serial driver.
Sergey Senozhatsky (4):
panic: avoid deadlocks in re-entrant console drivers
printk: move printk_safe macros to printk header
seial: introduce uart_port locking helpers
tty: 8250: switch to uart_port locking helpers
drivers/tty/serial/8250/8250_cor
RFC I modify only 8250 serial driver.
Sergey Senozhatsky (4):
panic: avoid deadlocks in re-entrant console drivers
printk: move printk_safe macros to printk header
seial: introduce uart_port locking helpers
tty: 8250: switch to uart_port locking helpers
drivers/tty/serial/8250/8250_cor
NMI panic() on printing CPU) the system
deadlocks and does not reboot.
Fix this by setting oops_in_progress before console_flush_on_panic(),
so re-entrant console drivers will trylock the port->lock instead of
spinning on it forever.
Signed-off-by: Sergey Senozhatsky
---
kernel/panic.c |
NMI panic() on printing CPU) the system
deadlocks and does not reboot.
Fix this by setting oops_in_progress before console_flush_on_panic(),
so re-entrant console drivers will trylock the port->lock instead of
spinning on it forever.
Signed-off-by: Sergey Senozhatsky
---
kernel/panic.c |
On (10/12/18 11:01), Petr Mladek wrote:
> > Make "free" unsigned integer and use appropriate printk() specifier.
> >
> > Signed-off-by: Sergey Senozhatsky
>
> I have pushed this fix into printk.git, for-4.20 branch.
Thanks.
> Please note that this 2n
On (10/12/18 11:01), Petr Mladek wrote:
> > Make "free" unsigned integer and use appropriate printk() specifier.
> >
> > Signed-off-by: Sergey Senozhatsky
>
> I have pushed this fix into printk.git, for-4.20 branch.
Thanks.
> Please note that this 2n
On (10/12/18 10:27), Petr Mladek wrote:
> > Forked from "printk feature for syzbot". Let's have a separate
> > discussion thread.
> > A buch of pr_cont tweaks and cleanups, please see commits and
> > commits' messages for more details.
> >
> &
On (10/12/18 10:27), Petr Mladek wrote:
> > Forked from "printk feature for syzbot". Let's have a separate
> > discussion thread.
> > A buch of pr_cont tweaks and cleanups, please see commits and
> > commits' messages for more details.
> >
> &
On (10/10/18 22:10), Tetsuo Handa wrote:
> >> I've found at least 1 place that uses DEFAULT_RATELIMIT_INTERVAL*10:
> >> https://elixir.bootlin.com/linux/latest/source/fs/btrfs/extent-tree.c#L8365
> >> Probably we need something similar here.
>
> Since printk() is a significantly CPU consuming
On (10/10/18 22:10), Tetsuo Handa wrote:
> >> I've found at least 1 place that uses DEFAULT_RATELIMIT_INTERVAL*10:
> >> https://elixir.bootlin.com/linux/latest/source/fs/btrfs/extent-tree.c#L8365
> >> Probably we need something similar here.
>
> Since printk() is a significantly CPU consuming
On (10/10/18 14:29), Dmitry Vyukov wrote:
> >> A bit unrelated, but while we are at it:
> >>
> >> I like it when we rate-limit printk-s that lookup the system.
> >> But it seems that default rate-limit values are not always good enough,
> >> DEFAULT_RATELIMIT_INTERVAL / DEFAULT_RATELIMIT_BURST
On (10/10/18 14:29), Dmitry Vyukov wrote:
> >> A bit unrelated, but while we are at it:
> >>
> >> I like it when we rate-limit printk-s that lookup the system.
> >> But it seems that default rate-limit values are not always good enough,
> >> DEFAULT_RATELIMIT_INTERVAL / DEFAULT_RATELIMIT_BURST
On (10/10/18 13:35), Michal Hocko wrote:
> > Just flooding out of memory messages can trigger RCU stall problems.
> > For example, a severe skbuff_head_cache or kmalloc-512 leak bug is causing
>
> [...]
>
> Quite some of them, indeed! I guess we want to rate limit the output.
> What about the
On (10/10/18 13:35), Michal Hocko wrote:
> > Just flooding out of memory messages can trigger RCU stall problems.
> > For example, a severe skbuff_head_cache or kmalloc-512 leak bug is causing
>
> [...]
>
> Quite some of them, indeed! I guess we want to rate limit the output.
> What about the
nd log_buf_len=2G
boot param:
[0.075317] log_buf_len: -2147483648 bytes
[0.075319] early log buf free: 33549896(-28%)
Make "free" unsigned integer and use appropriate printk() specifier.
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/printk.c | 6 +++---
1 file changed, 3 ins
nd log_buf_len=2G
boot param:
[0.075317] log_buf_len: -2147483648 bytes
[0.075319] early log buf free: 33549896(-28%)
Make "free" unsigned integer and use appropriate printk() specifier.
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/printk.c | 6 +++---
1 file changed, 3 ins
On (10/10/18 19:38), Sergey Senozhatsky wrote:
> The way we calculate free logbuf free space percentage
> overflows signed integer:
>
> int free;
>
> free = __LOG_BUF_LEN - log_next_idx;
> pr_info("early log buf free: %u(%u%%)\n",
&g
On (10/10/18 19:38), Sergey Senozhatsky wrote:
> The way we calculate free logbuf free space percentage
> overflows signed integer:
>
> int free;
>
> free = __LOG_BUF_LEN - log_next_idx;
> pr_info("early log buf free: %u(%u%%)\n",
&g
0.075319] early log buf free: 33549896(-28%)
Make "free" unsigned integer.
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/printk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c3f0e3927e77.
0.075319] early log buf free: 33549896(-28%)
Make "free" unsigned integer.
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/printk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c3f0e3927e77.
On (10/10/18 10:09), Petr Mladek wrote:
> > > +#define LOG_BUF_LEN_MAX (u32)(1 << 31)
> > [..]
> > > + if (size > (u64)LOG_BUF_LEN_MAX) {
> > > + size = (u64)LOG_BUF_LEN_MAX;
> > > + pr_err("log_buf over 2G is not supported.\n");
> > > + }
> >
> > Why not INT_MAX?
>
> INT_MAX is
On (10/10/18 10:09), Petr Mladek wrote:
> > > +#define LOG_BUF_LEN_MAX (u32)(1 << 31)
> > [..]
> > > + if (size > (u64)LOG_BUF_LEN_MAX) {
> > > + size = (u64)LOG_BUF_LEN_MAX;
> > > + pr_err("log_buf over 2G is not supported.\n");
> > > + }
> >
> > Why not INT_MAX?
>
> INT_MAX is
On (10/09/18 15:05), Petr Mladek wrote:
> >
> > Yeah, I think we gonna have problems even with a 4G logbuf and a 32-bit
> > user-space doing syslog(int len).
> >
> > I agree on the "not motivated enough" part ;)
>
> OK, I have pushed an updated patch that has the limit 2GB
> into printk.git,
On (10/09/18 15:05), Petr Mladek wrote:
> >
> > Yeah, I think we gonna have problems even with a 4G logbuf and a 32-bit
> > user-space doing syslog(int len).
> >
> > I agree on the "not motivated enough" part ;)
>
> OK, I have pushed an updated patch that has the limit 2GB
> into printk.git,
On (10/09/18 10:14), Petr Mladek wrote:
> Just to be sure. The original purpose was to get full information
> including the metadata and dictionary via extended console drivers,
> see commit 6fe29354befe4c46e ("printk: implement support for extended
> console drivers").
Right.
> IMHO, only the
On (10/09/18 10:14), Petr Mladek wrote:
> Just to be sure. The original purpose was to get full information
> including the metadata and dictionary via extended console drivers,
> see commit 6fe29354befe4c46e ("printk: implement support for extended
> console drivers").
Right.
> IMHO, only the
On (10/09/18 10:39), Petr Mladek wrote:
> >
> > Signed-off-by: Sergey Senozhatsky
> > ---
> > kernel/printk/printk.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
>
> The patch makes perfect sense. It looks a bit hacky but I can't
>
On (10/09/18 10:39), Petr Mladek wrote:
> >
> > Signed-off-by: Sergey Senozhatsky
> > ---
> > kernel/printk/printk.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
>
> The patch makes perfect sense. It looks a bit hacky but I can't
>
On (10/09/18 10:42), Petr Mladek wrote:
> On Tue 2018-10-02 11:38:36, Sergey Senozhatsky wrote:
> > We have a proper 'overflow' check which tells us that we need to
> > split up existing cont buffer in separate records:
> >
> > if (cont.len + len > sizeof(cont.bu
On (10/09/18 10:42), Petr Mladek wrote:
> On Tue 2018-10-02 11:38:36, Sergey Senozhatsky wrote:
> > We have a proper 'overflow' check which tells us that we need to
> > split up existing cont buffer in separate records:
> >
> > if (cont.len + len > sizeof(cont.bu
On (10/08/18 15:59), Petr Mladek wrote:
> I tried this patch with log_buf_len=5G. The kernel did not crash
> but dmesg shown some mess. There are several 32-bit variables
> to store the size, for example:
>
> static u32 log_buf_len = __LOG_BUF_LEN;
> u32 log_buf_len_get(void)
> static u32
On (10/08/18 15:59), Petr Mladek wrote:
> I tried this patch with log_buf_len=5G. The kernel did not crash
> but dmesg shown some mess. There are several 32-bit variables
> to store the size, for example:
>
> static u32 log_buf_len = __LOG_BUF_LEN;
> u32 log_buf_len_get(void)
> static u32
On (10/04/18 10:36), Petr Mladek wrote:
>
> This looks like a reasonable explanation of what is happening here.
> It also explains why the console owner logic helped.
Well, I'm still a bit puzzled, frankly speaking. I've two theories.
Theory #1 [most likely]
Steven is a wizard and his code
On (10/04/18 10:36), Petr Mladek wrote:
>
> This looks like a reasonable explanation of what is happening here.
> It also explains why the console owner logic helped.
Well, I'm still a bit puzzled, frankly speaking. I've two theories.
Theory #1 [most likely]
Steven is a wizard and his code
On (10/04/18 16:44), Sergey Senozhatsky wrote:
> So... Just an idea. Can you try a very dirty hack? Forcibly increase
> oops_in_progress in panic() before console_flush_on_panic(), so 8250
> serial8250_console_write() will use spin_trylock_irqsave() and maybe
> avoid deadlock.
E.g. so
On (10/04/18 16:44), Sergey Senozhatsky wrote:
> So... Just an idea. Can you try a very dirty hack? Forcibly increase
> oops_in_progress in panic() before console_flush_on_panic(), so 8250
> serial8250_console_write() will use spin_trylock_irqsave() and maybe
> avoid deadlock.
E.g. so
On (10/03/18 11:37), Daniel Wang wrote:
> When `softlockup_panic` is set (which is what my original repro had and
> what we use in production), without the backport patch, the expected panic
> would hit a seemingly deadlock. So even when the machine is configured
> to reboot immediately after the
On (10/03/18 11:37), Daniel Wang wrote:
> When `softlockup_panic` is set (which is what my original repro had and
> what we use in production), without the backport patch, the expected panic
> would hit a seemingly deadlock. So even when the machine is configured
> to reboot immediately after the
Correct vnprintf() typo + several aspell corrections.
Signed-off-by: Sergey Senozhatsky
---
lib/seq_buf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/seq_buf.c b/lib/seq_buf.c
index 11f2ae0f9099..738b4e92780c 100644
--- a/lib/seq_buf.c
+++ b/lib/seq_buf.c
Correct vnprintf() typo + several aspell corrections.
Signed-off-by: Sergey Senozhatsky
---
lib/seq_buf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/seq_buf.c b/lib/seq_buf.c
index 11f2ae0f9099..738b4e92780c 100644
--- a/lib/seq_buf.c
+++ b/lib/seq_buf.c
Oh, Cc-ing Andrew
message id: lkml.kernel.org/r/20181003105114.ga24...@embeddedor.com
---
On (10/03/18 21:26), Sergey Senozhatsky wrote:
> On (10/03/18 12:51), Gustavo A. R. Silva wrote:
> Replace "fallthru" with a proper "fall through" annotation.
>
> This fi
Oh, Cc-ing Andrew
message id: lkml.kernel.org/r/20181003105114.ga24...@embeddedor.com
---
On (10/03/18 21:26), Sergey Senozhatsky wrote:
> On (10/03/18 12:51), Gustavo A. R. Silva wrote:
> Replace "fallthru" with a proper "fall through" annotation.
>
> This fi
On (10/03/18 12:51), Gustavo A. R. Silva wrote:
> Replace "fallthru" with a proper "fall through" annotation.
>
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
Hmm, comments as annotations?
> Signed-off-by: Gustavo A. R. Silv
On (10/03/18 12:51), Gustavo A. R. Silva wrote:
> Replace "fallthru" with a proper "fall through" annotation.
>
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
Hmm, comments as annotations?
> Signed-off-by: Gustavo A. R. Silv
801 - 900 of 6882 matches
Mail list logo
