* [PATCH serial] sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()
From: Mao Wenan @ 2019-03-08 14:09 UTC (permalink / raw)
To: gregkh, jslaby, linux-serial, kernel-janitors, linux-kernel
Add the missing uart_unregister_driver() and i2c_del_driver() before return
from sc16is7xx_init() in the error handling case.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
drivers/tty/serial/sc16is7xx.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 268098681856..114e94f476c6 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1509,7 +1509,7 @@ static int __init sc16is7xx_init(void)
ret = i2c_add_driver(&sc16is7xx_i2c_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx i2c --> %d\n", ret);
- return ret;
+ goto err_i2c;
}
#endif
@@ -1517,10 +1517,18 @@ static int __init sc16is7xx_init(void)
ret = spi_register_driver(&sc16is7xx_spi_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx spi --> %d\n", ret);
- return ret;
+ goto err_spi;
}
#endif
return ret;
+
+err_spi:
+#ifdef CONFIG_SERIAL_SC16IS7XX_I2C
+ i2c_del_driver(&sc16is7xx_i2c_uart_driver);
+#endif
+err_i2c:
+ uart_unregister_driver(&sc16is7xx_uart);
+ return ret;
}
module_init(sc16is7xx_init);
--
2.20.1
^ permalink raw reply related
* [PATCH serial] sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()
From: Mao Wenan @ 2019-03-08 14:08 UTC (permalink / raw)
To: gregkh, jslaby, linux-serial, kernel-janitors, linux-kernel
Add the missing uart_unregister_driver() and i2c_del_driver() before return
from sc16is7xx_init() in the error handling case.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
drivers/tty/serial/sc16is7xx.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 268098681856..114e94f476c6 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1509,7 +1509,7 @@ static int __init sc16is7xx_init(void)
ret = i2c_add_driver(&sc16is7xx_i2c_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx i2c --> %d\n", ret);
- return ret;
+ goto err_i2c;
}
#endif
@@ -1517,10 +1517,18 @@ static int __init sc16is7xx_init(void)
ret = spi_register_driver(&sc16is7xx_spi_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx spi --> %d\n", ret);
- return ret;
+ goto err_spi;
}
#endif
return ret;
+
+err_spi:
+#ifdef CONFIG_SERIAL_SC16IS7XX_I2C
+ i2c_del_driver(&sc16is7xx_i2c_uart_driver);
+#endif
+err_i2c:
+ uart_unregister_driver(&sc16is7xx_uart);
+ return ret;
}
module_init(sc16is7xx_init);
--
2.20.1
^ permalink raw reply related
* Re: [RFC PATCH v1 25/25] printk: remove unused code
From: Sebastian Andrzej Siewior @ 2019-03-08 14:02 UTC (permalink / raw)
To: John Ogness
Cc: linux-kernel, Peter Zijlstra, Petr Mladek, Sergey Senozhatsky,
Steven Rostedt, Daniel Wang, Andrew Morton, Linus Torvalds,
Greg Kroah-Hartman, Alan Cox, Jiri Slaby, Peter Feiner,
linux-serial, Sergey Senozhatsky
In-Reply-To: <20190212143003.48446-26-john.ogness@linutronix.de>
On 2019-02-12 15:30:03 [+0100], John Ogness wrote:
you removed the whole `irq_work' thing. You can also remove the include
for linux/irq_work.h.
Sebastian
^ permalink raw reply
* Re: [PATCH serial] sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()
From: maowenan @ 2019-03-08 13:58 UTC (permalink / raw)
To: gregkh, jslaby, linux-serial, kernel-janitors, linux-kernel
In-Reply-To: <20190308140933.55262-1-maowenan@huawei.com>
sorry for duplicate mail, please ignore this one.
On 2019/3/8 22:09, Mao Wenan wrote:
> Add the missing uart_unregister_driver() and i2c_del_driver() before return
> from sc16is7xx_init() in the error handling case.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> drivers/tty/serial/sc16is7xx.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
> index 268098681856..114e94f476c6 100644
> --- a/drivers/tty/serial/sc16is7xx.c
> +++ b/drivers/tty/serial/sc16is7xx.c
> @@ -1509,7 +1509,7 @@ static int __init sc16is7xx_init(void)
> ret = i2c_add_driver(&sc16is7xx_i2c_uart_driver);
> if (ret < 0) {
> pr_err("failed to init sc16is7xx i2c --> %d\n", ret);
> - return ret;
> + goto err_i2c;
> }
> #endif
>
> @@ -1517,10 +1517,18 @@ static int __init sc16is7xx_init(void)
> ret = spi_register_driver(&sc16is7xx_spi_uart_driver);
> if (ret < 0) {
> pr_err("failed to init sc16is7xx spi --> %d\n", ret);
> - return ret;
> + goto err_spi;
> }
> #endif
> return ret;
> +
> +err_spi:
> +#ifdef CONFIG_SERIAL_SC16IS7XX_I2C
> + i2c_del_driver(&sc16is7xx_i2c_uart_driver);
> +#endif
> +err_i2c:
> + uart_unregister_driver(&sc16is7xx_uart);
> + return ret;
> }
> module_init(sc16is7xx_init);
>
>
^ permalink raw reply
* Re: [RFC PATCH v1 19/25] printk: introduce emergency messages
From: Petr Mladek @ 2019-03-08 10:31 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: John Ogness, linux-kernel, Peter Zijlstra, Steven Rostedt,
Daniel Wang, Andrew Morton, Linus Torvalds, Greg Kroah-Hartman,
Alan Cox, Jiri Slaby, Peter Feiner, linux-serial,
Sergey Senozhatsky
In-Reply-To: <20190307073029.GA489@jagdpanzerIV>
On Thu 2019-03-07 16:30:29, Sergey Senozhatsky wrote:
> On (02/12/19 15:29), John Ogness wrote:
> [..]
> > +static bool console_can_emergency(int level)
> > +{
> > + struct console *con;
> > +
> > + for_each_console(con) {
> > + if (!(con->flags & CON_ENABLED))
> > + continue;
> > + if (con->write_atomic && level < emergency_console_loglevel)
> > + return true;
> > + if (con->write && (con->flags & CON_BOOT))
> > + return true;
> > + }
> > + return false;
> > +}
> > +
> > +static void call_emergency_console_drivers(int level, const char *text,
> > + size_t text_len)
> > +{
> > + struct console *con;
> > +
> > + for_each_console(con) {
> > + if (!(con->flags & CON_ENABLED))
> > + continue;
> > + if (con->write_atomic && level < emergency_console_loglevel) {
> > + con->write_atomic(con, text, text_len);
> > + continue;
> > + }
> > + if (con->write && (con->flags & CON_BOOT)) {
> > + con->write(con, text, text_len);
> > + continue;
> > + }
> > + }
> > +}
> > +
> > +static void printk_emergency(char *buffer, int level, u64 ts_nsec, u16 cpu,
> > + char *text, u16 text_len)
> > +{
> > + struct printk_log msg;
> > + size_t prefix_len;
> > +
> > + if (!console_can_emergency(level))
> > + return;
> > +
> > + msg.level = level;
> > + msg.ts_nsec = ts_nsec;
> > + msg.cpu = cpu;
> > + msg.facility = 0;
> > +
> > + /* "text" must have PREFIX_MAX preceding bytes available */
> > +
> > + prefix_len = print_prefix(&msg,
> > + console_msg_format & MSG_FORMAT_SYSLOG,
> > + printk_time, buffer);
> > + /* move the prefix forward to the beginning of the message text */
> > + text -= prefix_len;
> > + memmove(text, buffer, prefix_len);
> > + text_len += prefix_len;
> > +
> > + text[text_len++] = '\n';
> > +
> > + call_emergency_console_drivers(level, text, text_len);
>
> So this iterates the console list and calls consoles' callbacks, but what
> prevents console driver to be rmmod-ed under us?
>
> CPU0 CPU1
>
> printk_emergency() rmmod netcon
> call_emergency_console_drivers()
> con_foo->flags & CON_ENABLED == 1
> unregister_console(con_foo)
> con_foo->flags &= ~CON_ENABLED
> __exit // con_foo gone ?
> con_foo->write()
>
> We use console_lock()/console_trylock() in order to protect the list and
> console drivers; but this brings scheduler to the picture, with all its
> locks.
Great catch!
I think that it is doable to guard the list using RCU.
Best Regards,
Petr
^ permalink raw reply
* Re: [RFC PATCH v1 20/25] serial: 8250: implement write_atomic
From: Petr Mladek @ 2019-03-08 10:28 UTC (permalink / raw)
To: John Ogness
Cc: linux-kernel, Peter Zijlstra, Sergey Senozhatsky, Steven Rostedt,
Daniel Wang, Andrew Morton, Linus Torvalds, Greg Kroah-Hartman,
Alan Cox, Jiri Slaby, Peter Feiner, linux-serial,
Sergey Senozhatsky
In-Reply-To: <87a7i6ovt3.fsf@linutronix.de>
On Fri 2019-03-08 05:05:12, John Ogness wrote:
> On 2019-02-27, Petr Mladek <pmladek@suse.com> wrote:
> >>>> Implement a non-sleeping NMI-safe write_atomic console function in
> >>>> order to support emergency printk messages.
> >>>
> >>> OK, it would be safe when prb_lock() is the only lock taken
> >>> in the NMI handler.
> >>
> >> Which is the case. As I wrote to you already [0], NMI contexts are
> >> _never_ allowed to do things that rely on waiting forever for other
> >> CPUs.
> >
> > Who says _never_? I agree that it is not reasonable. But the
> > history shows that it happens.
>
> Right, which is why it would need to become policy.
>
> The emergency messages (aka write_atomic) introduce a new requirement to
> the kernel because this callback must be callable from any context. The
> console drivers must have some way of synchronizing. The CPU-reentrant
> spin lock is the only solution I am aware of.
I am not in position to decide if this requirement is acceptable
or not. We would need an opinion from Linus at minimum.
But it is not acceptable from my point of view. Note that
many spinlocks might be safely used in NMI in principle.
You want to introduce a single spinlock just because
printk() could be called anywhere. Most other subsystems
do not have this problem because they a more self-contained.
> If the ringbuffer was fully lockless
Exactly, I think that a solution would be fully lockless logbuffer.
> we should be able to have per-console CPU-reentrant spin locks
> as long as the ordering is preserved, which I expect shouldn't
> be a problem. If any NMI context needed a spin lock for its own
> purposes, it would need to use the CPU-reentrant spin lock of
> the first console so as to preserve the ordering in case of a panic.
IMHO, this is not acceptable. It would be nice to have direct output
from NMI but the cost looks to high here.
A solution would be to defer the console to irq_work or so.
We might also consider using trylock in NMI and have
the irq_work just as a fallback.
Best Regars,
Petr
^ permalink raw reply
* Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread
From: Petr Mladek @ 2019-03-08 10:04 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: John Ogness, linux-kernel, Peter Zijlstra, Steven Rostedt,
Daniel Wang, Andrew Morton, Linus Torvalds, Greg Kroah-Hartman,
Alan Cox, Jiri Slaby, Peter Feiner, linux-serial,
Sergey Senozhatsky
In-Reply-To: <20190308013134.GB4063@jagdpanzerIV>
On Fri 2019-03-08 10:31:34, Sergey Senozhatsky wrote:
> On (03/07/19 13:06), John Ogness wrote:
> > On 2019-03-04, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
> > > This, theoretically, creates a whole new world of possibilities for
> > > console drivers. Now they can do GFP_KERNEL allocations and stall
> > > printk_kthread during OOM; or they can explicitly reschedule from
> > > ->write() callback (via console_conditional_schedule()) because
> > > console_lock() sets console_may_schedule.
> >
> This can stall the entire printing pipeline
>
> OOM -> printk_kthread() -> console_lock() -> con_foo() -> kmalloc(GFP_KERNEL) -> OOM
>
> > Although, as I mentioned in a previous response[0], perhaps we should
> > not loosen the requirements on write().
>
> Right. Console drivers better stay restricted; very restricted.
I agree here.
> > It is exactly that disable_preempt() that is so harmful for realtime tasks.
> I'll reply in another email (later today, or tomorrow).
I see. But I have troubles to imagine a preemtible direct console
output. The result would be mixed messages on a single line.
Best Regards,
Petr
^ permalink raw reply
* Re: [RFC PATCH v1 00/25] printk: new implementation
From: Petr Mladek @ 2019-03-08 10:00 UTC (permalink / raw)
To: John Ogness
Cc: Sergey Senozhatsky, linux-kernel, Peter Zijlstra, Steven Rostedt,
Daniel Wang, Andrew Morton, Linus Torvalds, Greg Kroah-Hartman,
Alan Cox, Jiri Slaby, Peter Feiner, linux-serial,
Sergey Senozhatsky
In-Reply-To: <87lg1rggcz.fsf@linutronix.de>
On Thu 2019-03-07 10:53:48, John Ogness wrote:
> On 2019-03-04, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
> > If there are setups which can be fully !atomic (in terms of console
> > output) then we, essentially, have a fully preemptible kthread printk
> > implementation.
>
> Correct. I've mentioned in another response[0] some ideas about what
> could be done to aid this.
>
> I understand that fully preemptible kthread printing is unacceptable for
> you. Since all current console drivers are already irq safe, I'm
> wondering if using irq_work to handle the emergency printing for console
> drivers without write_atomic() would help. (If the printk caller is in a
> context that write() supports, then write() could be called directly.)
> This would also demand that the irq-safe requirements for write() are
> not relaxed. The printk-kthread might still be faster than irq_work, but
> it might increase reliability if an irq_work is triggered as an extra
> precaution.
It is getting more and more complicated. The messages would be pushed
directly, from irq, and kthread. It would depend how the code would
look like but I am not much optimistic.
Note that you could not pass any data to the irq_work handler.
It would need to iterate over the logbuffer and take care of
all non-handled emergency messages.
Anyway, we could solve this later. We need to keep the current
console_unlock() handling as a fallback until enough consoles
support the direct mode anyway.
Best Regards,
Petr
^ permalink raw reply
* Re: -Wsometimes-uninitialized Clang warning in drivers/tty/serial/qcom_geni_serial.c
From: Greg Kroah-Hartman @ 2019-03-08 8:40 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Andy Gross, David Brown, Karthikeyan Ramasubramanian,
Douglas Anderson, Ryan Case, linux-arm-msm, linux-serial,
linux-kernel, Nick Desaulniers, clang-built-linux
In-Reply-To: <20190308004526.GA11580@archlinux-ryzen>
On Thu, Mar 07, 2019 at 05:45:26PM -0700, Nathan Chancellor wrote:
> Hi all,
>
> We are trying to get Clang's -Wsometimes-uninitialized turned on for the
> kernel as it can catch some bugs that GCC can't. This warning came up:
>
> drivers/tty/serial/qcom_geni_serial.c:1079:6: warning: variable 'baud' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
> if (options)
> ^~~~~~~
> drivers/tty/serial/qcom_geni_serial.c:1082:37: note: uninitialized use occurs here
> return uart_set_options(uport, co, baud, parity, bits, flow);
> ^~~~
> drivers/tty/serial/qcom_geni_serial.c:1079:2: note: remove the 'if' if its condition is always true
> if (options)
> ^~~~~~~~~~~~
> drivers/tty/serial/qcom_geni_serial.c:1053:10: note: initialize the variable 'baud' to silence this warning
> int baud;
> ^
> = 0
> 1 warning generated.
>
> While this is probably not an issue in practice (I assume baud is always
> supplied as an option), we should clean up this warning. I would fix it
> myself but I have no idea what baud's initial value should be as it
> seems it is dependent on the driver. Your input would be much
> appreciated.
this function can be called with the option variable set to NULL, so
there could not be a default baud rate set, nice catch.
As for the default, let's just be sane and set it to 9600 as that's a
normal default baudrate.
Do you want to make up a patch for this, or do you need me to?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/9] serial: uapi: add SER_RS485_DELAY_IN_USEC flag to struct serial_rs485
From: Martin Kepplinger @ 2019-03-08 7:36 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland, jslaby, corbet, richard.genoud,
nicolas.ferre, alexandre.belloni, ludovic.desroches,
mcoquelin.stm32, alexandre.torgue, linux-serial, devicetree,
linux-arm-kernel, linux-stm32
Cc: linux-kernel
In-Reply-To: <20190221171758.10322-1-martin.kepplinger@ginzinger.com>
[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]
On 21.02.19 18:17, Martin Kepplinger wrote:
> This extends the user interface for rs485 communication:
>
> We add a new flag, SER_RS485_DELAY_IN_USEC, to struct serial_rs485 that
> indicates that delay_rts_before_send and delay_rts_after_send values are
> interpreted in microsecond units.
>
> Up until now, the code comment defined these values to hold the delays in
> millisecond units. Especially with fast data rates (1Mbaut or more) that
> are not too uncommon for RS485, 1ms become quite long. Users need to be
> able to set shorter delays than 1 ms in order not to slow down the channel
> unnecessarily.
>
> So when delays are needed, but not as long as 1ms, this enables faster
> communication channels without changing the baudrate.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
> ---
>
> revision history
> ----------------
> v2: re-send as a proper series after fixing my mailserver
> v1: initial implementation idea
>
>
> So have this totally quirky patch that uses udelay() in our tree
> for a looong time now because of the above reasons - and because we are lazy.
> This is an attempt to get rid of said patch on our side and fix this properly.
>
> What do you thing about adding a flag in general?
>
> The following patches should integrate this idea in devicetree and drivers.
> These changes are NOT tested on hardware but should behave predictably
> enough. I use the delays in a driver that doesn't implement them yet at
> all. I'll do that after this (or something similar) is merged - it's a 2-liner
> then.
>
> Also, a patch to the rs485conf tool, that is sometimes used instead of
> ioctl() directly, will be prepared as well.
>
any objections of questions about having microsecond delays and this
series of changes?
thanks
martin
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3616 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v1 20/25] serial: 8250: implement write_atomic
From: John Ogness @ 2019-03-08 4:17 UTC (permalink / raw)
To: Petr Mladek
Cc: linux-kernel, Peter Zijlstra, Sergey Senozhatsky, Steven Rostedt,
Daniel Wang, Andrew Morton, Linus Torvalds, Greg Kroah-Hartman,
Alan Cox, Jiri Slaby, Peter Feiner, linux-serial,
Sergey Senozhatsky
In-Reply-To: <87a7i6ovt3.fsf@linutronix.de>
On 2019-03-08, John Ogness <john.ogness@linutronix.de> wrote:
> If the ringbuffer was fully lockless, we should be able to have
> per-console CPU-reentrant spin locks as long as the ordering is
> preserved, which I expect shouldn't be a problem. If any NMI context
> needed a spin lock for its own purposes, it would need to use the
> CPU-reentrant spin lock of the first console so as to preserve the
> ordering in case of a panic.
This point is garbage. Sorry. I do not see how we could safely have
multiple CPU-reentrant spin locks. Example of a deadlock:
CPU0 CPU1
printk printk
console2.lock console1.lock
NMI NMI
printk printk
console1.lock console2.lock
>> ... it should not be a common lock for the ring buffer and all
>> consoles.
>
> If the ring buffer becomes fully lockless, then we could move to
> per-console CPU-reentrant spin locks.
A fully lockless ring buffer will reduce the scope of the one, global
CPU-reentrant spin lock. But I do not see how we can safely have
multiple of these. If it is part of printk, it is already implicitly on
every line of code.
John Ogness
^ permalink raw reply
* Re: [RFC PATCH v1 20/25] serial: 8250: implement write_atomic
From: John Ogness @ 2019-03-08 4:05 UTC (permalink / raw)
To: Petr Mladek
Cc: linux-kernel, Peter Zijlstra, Sergey Senozhatsky, Steven Rostedt,
Daniel Wang, Andrew Morton, Linus Torvalds, Greg Kroah-Hartman,
Alan Cox, Jiri Slaby, Peter Feiner, linux-serial,
Sergey Senozhatsky
In-Reply-To: <20190227135504.gqtcsdwpy4rd7xvs@pathway.suse.cz>
On 2019-02-27, Petr Mladek <pmladek@suse.com> wrote:
>>>> Implement a non-sleeping NMI-safe write_atomic console function in
>>>> order to support emergency printk messages.
>>>
>>> OK, it would be safe when prb_lock() is the only lock taken
>>> in the NMI handler.
>>
>> Which is the case. As I wrote to you already [0], NMI contexts are
>> _never_ allowed to do things that rely on waiting forever for other
>> CPUs.
>
> Who says _never_? I agree that it is not reasonable. But the
> history shows that it happens.
Right, which is why it would need to become policy.
The emergency messages (aka write_atomic) introduce a new requirement to
the kernel because this callback must be callable from any context. The
console drivers must have some way of synchronizing. The CPU-reentrant
spin lock is the only solution I am aware of.
> In principle, there is nothing wrong in using spinlock in NMI
> when it is used only in NMI.
The CPU-reentrant spin lock _will_ be used in NMI context and
potentially could be used from any line of NMI code (if, for example, a
panic is triggered). The problem is when you have 2 different spin locks
in NMI context and their ordering cannot be guaranteed. And since I am
introducing an implicit spin lock that potentially could be locked from
any line of code, any explicit use of a spin lock in NMI could would
really be adding a 2nd spin lock and thus deadlock potential.
If the ringbuffer was fully lockless, we should be able to have
per-console CPU-reentrant spin locks as long as the ordering is
preserved, which I expect shouldn't be a problem. If any NMI context
needed a spin lock for its own purposes, it would need to use the
CPU-reentrant spin lock of the first console so as to preserve the
ordering in case of a panic.
>>> 2. I am afraid that we need to add some locking between CPUs
>>> to avoid mixing characters from directly printed messages.
>>
>> That is exactly what console_atomic_lock() (actually prb_lock) is!
>
> Sure. But it should not be a common lock for the ring buffer and
> all consoles.
As long as the ring buffer requires a CPU-reentrant spin lock, I expect
that it _must_ be a common lock for all. Consider the situation that the
ring buffer writer code causes a panic. I think it is beneficial if at
least 1 level of printk recursion is supported so that even these
backtraces make it out on the emergency consoles.
If the ring buffer becomes fully lockless, then we could move to
per-console CPU-reentrant spin locks.
John Ogness
^ permalink raw reply
* Re: [PATCH 4/4] printk: Add a device attribute for the per-console loglevel
From: Sergey Senozhatsky @ 2019-03-08 3:11 UTC (permalink / raw)
To: Calvin Owens
Cc: Sergey Senozhatsky, Petr Mladek, Sergey Senozhatsky,
Steven Rostedt, Greg Kroah-Hartman, Jonathan Corbet,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
In-Reply-To: <20190304191006.GA51516@calvinowens-mba.dhcp.thefacebook.com>
On (03/04/19 19:10), Calvin Owens wrote:
> On Monday 03/04 at 17:06 +0900, Sergey Senozhatsky wrote:
> > On (03/01/19 16:48), Calvin Owens wrote:
> > > +static struct attribute *console_sysfs_attrs[] = {
> > > + &dev_attr_loglevel.attr,
> > > + NULL,
> > > +};
> > > +ATTRIBUTE_GROUPS(console_sysfs);
> > > +
> > > static struct bus_type console_subsys = {
> > > .name = "console",
> > > + .dev_groups = console_sysfs_groups,
> > > };
> >
> > Do we really need to change this dynamically? Console options are
> > traditionally static (boot param or DT). Can we also be happy with
> > the static per-console loglevel?
>
> It really does need to be runtime configurable: there are a lot of usecases
> that enables, like turning the fast console up to KERN_DEBUG on a pile of
> machines you want to take a closer look at. The 'kernel.printk' global
> loglevel is also already changable at runtime, and since that setting
> interacts with this one it would be strange if only the former were able
> to be changed.
Fair enough.
-ss
^ permalink raw reply
* Re: [PATCH 1/4] printk: Introduce per-console loglevel setting
From: Sergey Senozhatsky @ 2019-03-08 3:10 UTC (permalink / raw)
To: Calvin Owens
Cc: Petr Mladek, Sergey Senozhatsky, Steven Rostedt,
Greg Kroah-Hartman, Jonathan Corbet, linux-kernel, linux-serial
In-Reply-To: <06cd267ef5439a9391368423b608959f5f1b1a63.1551486732.git.calvinowens@fb.com>
On (03/01/19 16:48), Calvin Owens wrote:
[..]
> msg = log_from_idx(console_idx);
> - if (suppress_message_printing(msg->level)) {
> - /*
> - * Skip record we have buffered and already printed
> - * directly to the console when we received it, and
> - * record that has level above the console loglevel.
> - */
> - console_idx = log_next(console_idx);
> - console_seq++;
> - goto skip;
> - }
>
> /* Output to all consoles once old messages replayed. */
> if (unlikely(exclusive_console &&
> @@ -2405,7 +2402,7 @@ void console_unlock(void)
> console_lock_spinning_enable();
>
> stop_critical_timings(); /* don't trace print latency */
> - call_console_drivers(ext_text, ext_len, text, len);
> + call_console_drivers(ext_text, ext_len, text, len, msg->level);
> start_critical_timings();
So it seems that now we always format the text and ext message (if
needed) and only then check if there is at least one console we can
print that message on.
Can we iterate the consoles first and check if msg is worth
the effort (per console suppress_message_printing()) and only
if it is do all the formatting and call console drivers?
-ss
^ permalink raw reply
* Re: [PATCH 3/4] printk: Add consoles to a virtual "console" bus
From: John Ogness @ 2019-03-08 2:56 UTC (permalink / raw)
To: Calvin Owens
Cc: Petr Mladek, Sergey Senozhatsky, Steven Rostedt,
Greg Kroah-Hartman, Jonathan Corbet, linux-kernel, linux-serial
In-Reply-To: <087b13f7812b32cc7c3f9efea71c9bcf324dd031.1551486732.git.calvinowens@fb.com>
On 2019-03-02, Calvin Owens <calvinowens@fb.com> wrote:
> This patch embeds a device struct in the console struct, and registers
> them on a "console" bus so we can expose attributes in sysfs.
I expect that "class" would be more appropriate than "bus". These
devices really are grouped together based on their function and not the
medium by which they are accessed.
John Ogness
^ permalink raw reply
* Re: Serial console is causing system lock-up
From: John Ogness @ 2019-03-08 2:36 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Petr Mladek, Nigel Croxon, Theodore Y. Ts'o,
Greg Kroah-Hartman, John Stoffel, Steven Rostedt,
Sergey Senozhatsky, dm-devel, Mikulas Patocka, linux-serial
In-Reply-To: <20190308013952.GA9085@jagdpanzerIV>
On 2019-03-08, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
>>> Perhaps a proper solution would be to drop excessive messages to
>>> serial console unless Oops or BUG has happened?
>>
>> Technically, we can have a per-console loglevel configuration. We
>> have several use cases for this already.
>
> JFI,
>
> lore.kernel.org/r/cover.1551486732.git.calvinowens@fb.com
FWIW, I support the patch. It makes consoles into actual objects rather
than just a collection of callbacks. I feel like Calvin is pushing in a
similar direction to what I would like to see: decoupling of console
drivers to allow for individual behavior and performance tuning. As we
move into the highly SMP systems of the future, I am convinced this is
inevitable.
John Ogness
^ permalink raw reply
* [PATCH] Disable kgdboc failed by echo space to /sys/module/kgdboc/parameters/kgdboc
From: 王 文涛 @ 2019-03-08 1:54 UTC (permalink / raw)
To: jason.wessel@windriver.com, daniel.thompson@linaro.org,
gregkh@linuxfoundation.org, jslaby@suse.com
Cc: kgdb-bugreport@lists.sourceforge.net,
linux-serial@vger.kernel.org
From 66d39c0de0abd45ddca7aa8fc08632b01d669d7b Mon Sep 17 00:00:00 2001
From: Wentao Wang <“witallwang@gmail.com”>
Date: Mon, 4 Mar 2019 21:58:33 +0800
Subject: [PATCH] Disable kgdboc failed by echo space to
/sys/module/kgdboc/parameters/kgdboc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Echo "" to /sys/module/kgdboc/parameters/kgdboc will fail with write
error: No such device
This is caused by function "configure_kgdboc" who init err to ENODEV when
the config is empty (legal input) the code go out with ENODEV returned.
Fixes: 2dd453168643d ("kgdboc: Fix restrict error")
Signed-off-by: Wentao Wang <“witallwang@gmail.com”>
---
drivers/tty/serial/kgdboc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c
index 6fb312e..bfe5e9e 100644
--- a/drivers/tty/serial/kgdboc.c
+++ b/drivers/tty/serial/kgdboc.c
@@ -148,8 +148,10 @@ static int configure_kgdboc(void)
char *cptr = config;
struct console *cons;
- if (!strlen(config) || isspace(config[0]))
+ if (!strlen(config) || isspace(config[0])) {
+ err = 0;
goto noconfig;
+ }
kgdboc_io_ops.is_console = 0;
kgdb_tty_driver = NULL;
--
2.7.4
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
^ permalink raw reply related
* Re: Serial console is causing system lock-up
From: Sergey Senozhatsky @ 2019-03-08 1:39 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Petr Mladek, Nigel Croxon, Theodore Y. Ts'o,
Sergey Senozhatsky, John Ogness, Greg Kroah-Hartman, John Stoffel,
Steven Rostedt, Sergey Senozhatsky, dm-devel, linux-serial
In-Reply-To: <20190308012242.GA4063@jagdpanzerIV>
On (03/08/19 10:22), Sergey Senozhatsky wrote:
> > Perhaps a proper solution would be to drop excessive messages to serial
> > console unless Oops or BUG has happened?
>
> Technically, we can have a per-console loglevel configuration. We have
> several use cases for this already.
JFI,
lore.kernel.org/r/cover.1551486732.git.calvinowens@fb.com
-ss
^ permalink raw reply
* Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread
From: Sergey Senozhatsky @ 2019-03-08 1:31 UTC (permalink / raw)
To: John Ogness
Cc: Sergey Senozhatsky, linux-kernel, Peter Zijlstra, Petr Mladek,
Steven Rostedt, Daniel Wang, Andrew Morton, Linus Torvalds,
Greg Kroah-Hartman, Alan Cox, Jiri Slaby, Peter Feiner,
linux-serial, Sergey Senozhatsky
In-Reply-To: <87va0uopmd.fsf@linutronix.de>
On (03/07/19 13:06), John Ogness wrote:
> On 2019-03-04, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
> >> + /* the printk kthread never exits */
> >> + for (;;) {
> >> + ret = prb_iter_wait_next(&iter, buf,
> >> + PRINTK_RECORD_MAX, &master_seq);
> >> + if (ret == -ERESTARTSYS) {
> >> + continue;
> >> + } else if (ret < 0) {
> >> + /* iterator invalid, start over */
> >> + prb_iter_init(&iter, &printk_rb, NULL);
> >> + continue;
> >> + }
> >> +
> >> + msg = (struct printk_log *)buf;
> >> + format_text(msg, master_seq, ext_text, &ext_len, text,
> >> + &len, printk_time);
> >> +
> >> + console_lock();
> >> + if (len > 0 || ext_len > 0) {
> >> + call_console_drivers(ext_text, ext_len, text, len);
> >> + boot_delay_msec(msg->level);
> >> + printk_delay();
> >> + }
> >> + console_unlock();
> >> + }
> >
> > This, theoretically, creates a whole new world of possibilities for
> > console drivers. Now they can do GFP_KERNEL allocations and stall
> > printk_kthread during OOM; or they can explicitly reschedule from
> > ->write() callback (via console_conditional_schedule()) because
> > console_lock() sets console_may_schedule.
>
> This was the intention.
This can stall the entire printing pipeline
OOM -> printk_kthread() -> console_lock() -> con_foo() -> kmalloc(GFP_KERNEL) -> OOM
> Although, as I mentioned in a previous response[0], perhaps we should
> not loosen the requirements on write().
Right. Console drivers better stay restricted; very restricted.
> It is exactly that disable_preempt() that is so harmful for realtime tasks.
I'll reply in another email (later today, or tomorrow).
-ss
^ permalink raw reply
* Re: Serial console is causing system lock-up
From: Sergey Senozhatsky @ 2019-03-08 1:22 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Petr Mladek, Nigel Croxon, Theodore Y. Ts'o, John Ogness,
Greg Kroah-Hartman, John Stoffel, Steven Rostedt,
Sergey Senozhatsky, dm-devel, linux-serial
In-Reply-To: <alpine.LRH.2.02.1903070918110.6122@file01.intranet.prod.int.rdu2.redhat.com>
On (03/07/19 09:26), Mikulas Patocka wrote:
> On Thu, 7 Mar 2019, John Stoffel wrote:
>
> > The real problem is the disconnect between serial console speed and
> > capacity in bits/sec and that of the regular console. Serial, esp at
> > 9600 baud is just a slow and limited resource which needs to be
> > handled differently than a graphical console.
> >
> > I'm also big on ratelimiting messages, even critical warning
> > messages. Too much redundant info doesn't help anyone. And what a
> > subsystem thinks is critical, may not be critical to the system as a
> > whole.
>
> Perhaps a proper solution would be to drop excessive messages to serial
> console unless Oops or BUG has happened?
Technically, we can have a per-console loglevel configuration. We have
several use cases for this already. Slower consoles will filter out more
messages and print only ERR/CRIT/ALERT/EMERG.
dm-integrity uses WARN level, which is below ERR; so it seems that
per-console loglevel can do the trick.
-ss
^ permalink raw reply
* -Wsometimes-uninitialized Clang warning in drivers/tty/serial/qcom_geni_serial.c
From: Nathan Chancellor @ 2019-03-08 0:45 UTC (permalink / raw)
To: Andy Gross, David Brown, Greg Kroah-Hartman,
Karthikeyan Ramasubramanian, Douglas Anderson, Ryan Case
Cc: linux-arm-msm, linux-serial, linux-kernel, Nick Desaulniers,
clang-built-linux
Hi all,
We are trying to get Clang's -Wsometimes-uninitialized turned on for the
kernel as it can catch some bugs that GCC can't. This warning came up:
drivers/tty/serial/qcom_geni_serial.c:1079:6: warning: variable 'baud' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (options)
^~~~~~~
drivers/tty/serial/qcom_geni_serial.c:1082:37: note: uninitialized use occurs here
return uart_set_options(uport, co, baud, parity, bits, flow);
^~~~
drivers/tty/serial/qcom_geni_serial.c:1079:2: note: remove the 'if' if its condition is always true
if (options)
^~~~~~~~~~~~
drivers/tty/serial/qcom_geni_serial.c:1053:10: note: initialize the variable 'baud' to silence this warning
int baud;
^
= 0
1 warning generated.
While this is probably not an issue in practice (I assume baud is always
supplied as an option), we should clean up this warning. I would fix it
myself but I have no idea what baud's initial value should be as it
seems it is dependent on the driver. Your input would be much
appreciated.
Cheers,
Nathan
^ permalink raw reply
* Re: Serial console is causing system lock-up
From: Petr Mladek @ 2019-03-07 15:35 UTC (permalink / raw)
To: John Ogness
Cc: Nigel Croxon, Theodore Y. Ts'o, Sergey Senozhatsky,
Greg Kroah-Hartman, Steven Rostedt, Sergey Senozhatsky, dm-devel,
Mikulas Patocka, linux-serial
In-Reply-To: <87r2biojcx.fsf@linutronix.de>
On Thu 2019-03-07 15:21:50, John Ogness wrote:
> On 2019-03-07, Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
> >>> The CPU which spins on prb_lock() can have preemption disabled and,
> >>> additionally, can have local IRQs disabled, or be under RCU read
> >>> side lock. If consoles are busy, then there are CPUs which printk()
> >>> data and keep prb_lock contended; prb_lock() does not seem to be
> >>> fair. What am I missing?
> >>
> >> You are correct. Making prb_lock fair might be something we want to
> >> look into. Perhaps also based on the loglevel of what needs to be
> >> printed. (For example, KERN_ALERT always wins over KERN_CRIT.)
> >
> > Good.
> >
> > I'm not insisting, but I have a feeling that touching watchdogs after
> > call_console_drivers() might be too late, sometimes. When we spin in
> > prb_lock() we wait for all CPUs which are before/ahead of us to
> > finish their call_console_drivers(), one by one. So if CPUZ is very
> > unlucky and is in atomic context, then prb_lock() for that CPUZ can
> > last for N * call_console_drivers(). And depending on N (which also
> > includes unfairness) and call_console_drivers() timings NMI watchdog
> > may pay CPUZ a visit before it gets its chance to touch watchdogs.
> >
> > *May be* sometimes we might want to touch watchdogs in prb_lock().
>
> This is an excellent point. The handling of the watchdogs needs to be
> more carefully considered/placed.
>
> > So, given the design of new printk(), I can't help thinking about the
> > fact that current
> > "the winner takes it all"
> > may become
> > "the winner waits for all".
>
> I am open to looking at implementing a fair prb_cpulock(). I think
> without it, your observation for these "multi-CPU emergency message
> flood" cases is correct.
This should be rather discussed in the thread about the new printk
implementation.
Anyway, the first version should be acceptable even with the unfair
lock. Please, do not spend time on this now.
There is a bigger problem with the lock. It is not NMI safe as I wrote
in
https://lkml.kernel.org/r/20190227135504.gqtcsdwpy4rd7xvs@pathway.suse.cz
Therefore I am not sure if we could use it at all.
> In a previous response[0] to Petr, I talk about defining _all_ console
> printing as emergency and requiring userspace to handle informational
> messages. With that definition, one could argue that the atomic consoles
> are enough and we could avoid the printk-kthread(s) altogether. I am not
> absolutely against this idea. But there (most likely) will be consoles
> that cannot support atomic. And how should they be handled? We could
> keep the current (quite complex) implementation in place just for
> them. But I really wonder if all that is necessary just for those (few?)
> consoles.
We must keep it as a fallback as long as the "few" group is important
enough for users.
> printk-kthreads seem to me to be the ideal solution
> (particularly when dealing with PREEMPT_RT, where nearly everything
> important becomes a kthread).
This can be solved by a configuration setting. Real-time kernels
might do the offloading more aggressively.
Best Regards,
Petr
^ permalink raw reply
* Re: Serial console is causing system lock-up
From: Petr Mladek @ 2019-03-07 15:16 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Nigel Croxon, Theodore Y. Ts'o, Greg Kroah-Hartman,
Steven Rostedt, Sergey Senozhatsky, dm-devel, linux-serial
In-Reply-To: <alpine.LRH.2.02.1903061157530.3129@file01.intranet.prod.int.rdu2.redhat.com>
On Wed 2019-03-06 12:11:10, Mikulas Patocka wrote:
>
>
> On Wed, 6 Mar 2019, Theodore Y. Ts'o wrote:
>
> > On Wed, Mar 06, 2019 at 11:07:55AM -0500, Mikulas Patocka wrote:
> > > This bug only happens if we select large logbuffer (millions of
> > > characters). With smaller log buffer, there are messages "** X printk
> > > messages dropped", but there's no lockup.
> > >
> > > The kernel apparently puts 2 million characters into a console log buffer,
> > > then takes some lock and than tries to write all of them to a slow serial
> > > line.
> >
> > What are the messages; from what kernel subsystem? Why are you seeing
> > so many log messages?
> >
> > - Ted
>
> The dm-integity subsystem (drivers/md/dm-integrity.c) can be attached to a
> block device to provide checksum protection. It will return -EILSEQ and
> print a message to a log for every corrupted block.
>
> Nigel Croxon was testing MD-RAID recovery capabilities in such a way that
> he activated RAID-5 array with one leg replaced by a dm-integrity block
> device that had all checksums invalid.
>
> The MD-RAID is supposed to recalculate data for the corrupted device and
> bring it back to life. However, scrubbing the MD-RAID device resulted in a
> lot of reads from the device with bad checksums, these were reported to
> the log and killed the machine.
>
>
> I made a patch to dm-integrity to rate-limit the error messages. But
> anyway - killing the machine in case of too many log messages seems
> bad. If the log messages are produced faster than the kernel can write them,
> the kernel should discard some of them, not kill itself.
printk() could not easily detect where the messages come from and
if it is acceptable to drop them.
In general, an "unlimited" output of messages that are not much useful
looks like a bug on the caller side. Some rate-limiting in
dm-integrity code looks appropriate here.
Even better might be to stop printing the messages after X occurrences
until the check is completed. It might do something like:
int errors_count = 0;
while(find_error()) {
errors_count++;
if (errors_count <= 10)
pr_err("...");
else if (errors_count == 11)
pr_error(¨Too many errors. Continuing check silently\n");
}
if (errors_count)
pr_error("Check finished. %d errors detected\n", errors_count);
Note that rate-limit is a bit ugly. It does not have feedback from
printk/consoles how long it takes to get the messages out. It might
not be enough if the console is very slow and if there are other
printk() users at the same time.
That said. I agree that printk() should not kill the system. It should
survive these "mistakes". On the other hand, printk() users must
cooperate. The log buffer and console bandwith is a limited resource.
Best Regards,
Petr
^ permalink raw reply
* Re: Serial console is causing system lock-up
From: Mikulas Patocka @ 2019-03-07 14:26 UTC (permalink / raw)
To: John Stoffel
Cc: Petr Mladek, Nigel Croxon, Theodore Y. Ts'o, John Ogness,
Greg Kroah-Hartman, Steven Rostedt, Sergey Senozhatsky, dm-devel,
linux-serial
In-Reply-To: <23681.9703.524330.948156@quad.stoffel.home>
On Thu, 7 Mar 2019, John Stoffel wrote:
> The real problem is the disconnect between serial console speed and
> capacity in bits/sec and that of the regular console. Serial, esp at
> 9600 baud is just a slow and limited resource which needs to be
> handled differently than a graphical console.
>
> I'm also big on ratelimiting messages, even critical warning
> messages. Too much redundant info doesn't help anyone. And what a
> subsystem thinks is critical, may not be critical to the system as a
> whole.
Perhaps a proper solution would be to drop excessive messages to serial
console unless Oops or BUG has happened?
> In this case, if these checksum messages are telling us that there's
> corruption, why isn't dm-integrity going readonly and making the block
> device get the filesystem to also go readonly and to stop the damage
> right away?
Because we don't want to kill the filesystem. dm-integrity detects an
error and returns the error code to md-raid5. md-raid5 recalculates the
correct data from the remaining disks. And then, md-raid5 submits the
correct data to the filesystem and also writes the correct data to the
device that had the error.
In a real-life scenario, there would be few errors. When we are testing
it, we deliberately create a device with all errorneous sectors.
> If it's just a warning for the niceness, then please rate limit them,
> or summarize them in some more useful way. Or even log them to
> somewhere else than the console once the problem is noted.
>
> John
I made a patch that rate-limits the message. But still, killing the
machine is wrong.
Mikulas
^ permalink raw reply
* Re: Serial console is causing system lock-up
From: John Ogness @ 2019-03-07 14:21 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Petr Mladek, Nigel Croxon, Theodore Y. Ts'o,
Sergey Senozhatsky, Greg Kroah-Hartman, Steven Rostedt, dm-devel,
Mikulas Patocka, linux-serial
In-Reply-To: <20190307122642.GA10415@tigerII.localdomain>
On 2019-03-07, Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
>>> The CPU which spins on prb_lock() can have preemption disabled and,
>>> additionally, can have local IRQs disabled, or be under RCU read
>>> side lock. If consoles are busy, then there are CPUs which printk()
>>> data and keep prb_lock contended; prb_lock() does not seem to be
>>> fair. What am I missing?
>>
>> You are correct. Making prb_lock fair might be something we want to
>> look into. Perhaps also based on the loglevel of what needs to be
>> printed. (For example, KERN_ALERT always wins over KERN_CRIT.)
>
> Good.
>
> I'm not insisting, but I have a feeling that touching watchdogs after
> call_console_drivers() might be too late, sometimes. When we spin in
> prb_lock() we wait for all CPUs which are before/ahead of us to
> finish their call_console_drivers(), one by one. So if CPUZ is very
> unlucky and is in atomic context, then prb_lock() for that CPUZ can
> last for N * call_console_drivers(). And depending on N (which also
> includes unfairness) and call_console_drivers() timings NMI watchdog
> may pay CPUZ a visit before it gets its chance to touch watchdogs.
>
> *May be* sometimes we might want to touch watchdogs in prb_lock().
This is an excellent point. The handling of the watchdogs needs to be
more carefully considered/placed.
> So, given the design of new printk(), I can't help thinking about the
> fact that current
> "the winner takes it all"
> may become
> "the winner waits for all".
I am open to looking at implementing a fair prb_cpulock(). I think
without it, your observation for these "multi-CPU emergency message
flood" cases is correct.
> [...]
>
> And this brings us to another pessimistic scenario: a very unlucky
> CPUZ has to spin in prb_lock() waiting for other CPUs to print out
> the very same 2 million chars. Which in terms of printk() latency
> looks to me just like current printk.
If the prb_cpulock() is fair, they are both taking turns printing. The
prb_cpulock() is taken for _each_ printk() call and not (like in the
current printk) for the complete unprinted contents of the ringbuffer.
> John, sorry to ask this, does new printk() design always provide
> latency guarantees good enough for PREEMPT_RT?
Yes, because it is assumed that emergency messages will never occur for
a correctly running system. We've run tests where we pr_info() from all
contexts and the console_loglevel is set such that KERN_INFO is printed
to the console. The storage of the messages into the printk ringbuffer
do not cause any unacceptable latencies. And printing those messages to
the consoles via the fully preemptible printk-kthread also causes no
unacceptable latencies.
Obviously as soon as any emergency message appears, an _unacceptable_
latency occurs. But that is considered OK because the system is no
longer running correctly and it is worth the price to pay to get those
messages with such high reliability.
In a previous response[0] to Petr, I talk about defining _all_ console
printing as emergency and requiring userspace to handle informational
messages. With that definition, one could argue that the atomic consoles
are enough and we could avoid the printk-kthread(s) altogether. I am not
absolutely against this idea. But there (most likely) will be consoles
that cannot support atomic. And how should they be handled? We could
keep the current (quite complex) implementation in place just for
them. But I really wonder if all that is necessary just for those (few?)
consoles. printk-kthreads seem to me to be the ideal solution
(particularly when dealing with PREEMPT_RT, where nearly everything
important becomes a kthread). My RFC series implements a very simple
(naive) approach to kthread printing. I believe there is a lot[1][2] we
can do to make the printk-kthread printing more reliable.
John Ogness
[0] https://lkml.kernel.org/r/87k1hbbq2m.fsf@linutronix.de
[1] https://lkml.kernel.org/r/87o96p9gtx.fsf@linutronix.de
[2] https://lkml.kernel.org/r/87lg1rggcz.fsf@linutronix.de
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox