Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1611720 > unrolled thread
| Started by | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> |
|---|---|
| First post | 2017-03-29 11:30 +0200 |
| Last post | 2017-04-04 10:30 +0200 |
| Articles | 9 on this page of 69 — 10 participants |
Back to article view | Back to linux.kernel
[RFC][PATCHv2 0/8] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-29 11:30 +0200
[RFC][PATCHv2 2/8] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-29 11:30 +0200
Re: [RFC][PATCHv2 2/8] printk: introduce printing kernel thread Petr Mladek <pmladek@suse.com> - 2017-04-04 11:10 +0200
Re: [RFC][PATCHv2 2/8] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-04 11:40 +0200
Re: [RFC][PATCHv2 2/8] printk: introduce printing kernel thread Pavel Machek <pavel@ucw.cz> - 2017-04-06 19:20 +0200
Re: [RFC][PATCHv2 2/8] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-07 07:20 +0200
Re: [RFC][PATCHv2 2/8] printk: introduce printing kernel thread Pavel Machek <pavel@ucw.cz> - 2017-04-07 09:30 +0200
Re: [RFC][PATCHv2 2/8] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-07 10:20 +0200
Re: [RFC][PATCHv2 2/8] printk: introduce printing kernel thread Pavel Machek <pavel@ucw.cz> - 2017-04-07 14:10 +0200
[RFC][PATCHv2 5/8] sysrq: switch to printk.emergency mode in unsafe places Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-29 11:30 +0200
Re: [RFC][PATCHv2 5/8] sysrq: switch to printk.emergency mode in unsafe places Petr Mladek <pmladek@suse.com> - 2017-03-31 17:40 +0200
Re: [RFC][PATCHv2 5/8] sysrq: switch to printk.emergency mode in unsafe places Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-04-01 02:10 +0200
[RFC][PATCHv2 1/8] printk: move printk_pending out of per-cpu Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-29 11:40 +0200
Re: [RFC][PATCHv2 1/8] printk: move printk_pending out of per-cpu Petr Mladek <pmladek@suse.com> - 2017-03-31 15:20 +0200
Re: [RFC][PATCHv2 1/8] printk: move printk_pending out of per-cpu Peter Zijlstra <peterz@infradead.org> - 2017-03-31 15:40 +0200
Re: [RFC][PATCHv2 1/8] printk: move printk_pending out of per-cpu Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-03 13:30 +0200
Re: [RFC][PATCHv2 1/8] printk: move printk_pending out of per-cpu Petr Mladek <pmladek@suse.com> - 2017-04-03 14:50 +0200
[RFC][PATCHv2 6/8] kexec: switch to printk.emergency mode in unsafe places Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-29 11:40 +0200
Re: [RFC][PATCHv2 6/8] kexec: switch to printk.emergency mode in unsafe places Petr Mladek <pmladek@suse.com> - 2017-03-31 17:40 +0200
[RFC][PATCHv2 8/8] printk: enable printk offloading Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-29 11:40 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-31 04:40 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-31 06:10 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Ye Xiaolong <xiaolong.ye@intel.com> - 2017-03-31 08:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-31 16:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage ebiederm@xmission.com (Eric W. Biederman) - 2017-03-31 17:40 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Jan Kara <jack@suse.cz> - 2017-04-03 11:40 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Petr Mladek <pmladek@suse.com> - 2017-04-03 12:10 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Pavel Machek <pavel@ucw.cz> - 2017-04-06 19:40 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-07 06:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Pavel Machek <pavel@ucw.cz> - 2017-04-07 09:20 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-07 09:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Pavel Machek <pavel@ucw.cz> - 2017-04-07 10:20 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-07 14:20 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Pavel Machek <pavel@ucw.cz> - 2017-04-07 14:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Steven Rostedt <rostedt@goodmis.org> - 2017-04-07 16:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-04-07 17:20 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Peter Zijlstra <peterz@infradead.org> - 2017-04-07 17:30 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-04-07 17:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage ebiederm@xmission.com (Eric W. Biederman) - 2017-04-09 20:30 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-10 06:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Pavel Machek <pavel@ucw.cz> - 2017-04-09 12:20 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-10 07:00 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Petr Mladek <pmladek@suse.com> - 2017-04-10 14:00 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-04-10 17:10 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Pavel Machek <pavel@ucw.cz> - 2017-04-10 20:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-11 03:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-04-11 18:30 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Pavel Machek <pavel@ucw.cz> - 2017-04-12 20:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-13 06:40 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-13 08:00 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-13 10:30 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Petr Mladek <pmladek@suse.com> - 2017-04-13 16:10 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-14 06:50 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Steven Rostedt <rostedt@goodmis.org> - 2017-04-07 16:40 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Pavel Machek <pavel@ucw.cz> - 2017-04-09 12:00 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-03 13:00 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Ye Xiaolong <xiaolong.ye@intel.com> - 2017-04-05 09:40 +0200
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-05 10:50 +0200
Re: [RFC][PATCHv2 8/8] printk: enable printk offloading Petr Mladek <pmladek@suse.com> - 2017-04-03 17:50 +0200
Re: [RFC][PATCHv2 8/8] printk: enable printk offloading Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-04-04 14:30 +0200
[RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-29 11:40 +0200
Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places Petr Mladek <pmladek@suse.com> - 2017-03-31 17:10 +0200
Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places Pavel Machek <pavel@ucw.cz> - 2017-04-06 19:30 +0200
Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places Andreas Mohr <andi@lisas.de> - 2017-04-09 13:00 +0200
Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places Petr Mladek <pmladek@suse.com> - 2017-04-10 14:30 +0200
Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-04-10 16:40 +0200
[RFC][PATCHv2 7/8] printk: add printk emergency_mode parameter Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-29 11:40 +0200
Re: [RFC][PATCHv2 7/8] printk: add printk emergency_mode parameter Petr Mladek <pmladek@suse.com> - 2017-04-03 17:30 +0200
Re: [RFC][PATCHv2 7/8] printk: add printk emergency_mode parameter Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-04-04 10:30 +0200
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> |
|---|---|
| Date | 2017-03-29 11:40 +0200 |
| Subject | [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places |
| Message-ID | <tqif8-4VF-35@gated-at.bofh.it> |
| In reply to | #1611720 |
It's not always possible/safe to wake_up() printk kernel
thread. For example, late suspend/early resume may printk()
while timekeeping is not initialized yet, so calling into the
scheduler may result in recursive warnings.
Another thing to notice is the fact PM at some point
freezes user space and kernel threads: freeze_processes()
and freeze_kernel_threads(), correspondingly. Thus we need
printk() to operate in old mode there and attempt to
immediately flush pending kernel message to the console.
This patch adds printk_emergency_begin/on sections.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
kernel/power/hibernate.c | 8 ++++++++
kernel/power/suspend.c | 4 ++++
2 files changed, 12 insertions(+)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index a8b978c35a6a..a8c6bb2dbcef 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -502,6 +502,7 @@ int hibernation_restore(int platform_mode)
{
int error;
+ printk_emergency_begin();
pm_prepare_console();
suspend_console();
pm_restrict_gfp_mask();
@@ -519,6 +520,7 @@ int hibernation_restore(int platform_mode)
pm_restore_gfp_mask();
resume_console();
pm_restore_console();
+ printk_emergency_end();
return error;
}
@@ -542,6 +544,7 @@ int hibernation_platform_enter(void)
goto Close;
entering_platform_hibernation = true;
+ printk_emergency_begin();
suspend_console();
error = dpm_suspend_start(PMSG_HIBERNATE);
if (error) {
@@ -589,6 +592,7 @@ int hibernation_platform_enter(void)
entering_platform_hibernation = false;
dpm_resume_end(PMSG_RESTORE);
resume_console();
+ printk_emergency_end();
Close:
hibernation_ops->end();
@@ -692,6 +696,7 @@ int hibernate(void)
goto Unlock;
}
+ printk_emergency_begin();
pm_prepare_console();
error = __pm_notifier_call_chain(PM_HIBERNATION_PREPARE, -1, &nr_calls);
if (error) {
@@ -759,6 +764,7 @@ int hibernate(void)
Exit:
__pm_notifier_call_chain(PM_POST_HIBERNATION, nr_calls, NULL);
pm_restore_console();
+ printk_emergency_end();
atomic_inc(&snapshot_device_available);
Unlock:
unlock_system_sleep();
@@ -868,6 +874,7 @@ static int software_resume(void)
goto Unlock;
}
+ printk_emergency_begin();
pm_prepare_console();
error = __pm_notifier_call_chain(PM_RESTORE_PREPARE, -1, &nr_calls);
if (error) {
@@ -884,6 +891,7 @@ static int software_resume(void)
Finish:
__pm_notifier_call_chain(PM_POST_RESTORE, nr_calls, NULL);
pm_restore_console();
+ printk_emergency_end();
atomic_inc(&snapshot_device_available);
/* For success case, the suspend path will release the lock */
Unlock:
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 15e6baef5c73..1f897b149fc0 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -433,6 +433,7 @@ int suspend_devices_and_enter(suspend_state_t state)
if (!sleep_state_supported(state))
return -ENOSYS;
+ printk_emergency_begin();
error = platform_suspend_begin(state);
if (error)
goto Close;
@@ -462,6 +463,7 @@ int suspend_devices_and_enter(suspend_state_t state)
Close:
platform_resume_end(state);
+ printk_emergency_end();
return error;
Recover_platform:
@@ -520,6 +522,7 @@ static int enter_state(suspend_state_t state)
#endif
pr_debug("PM: Preparing system for sleep (%s)\n", pm_states[state]);
+ printk_emergency_begin();
pm_suspend_clear_flags();
error = suspend_prepare(state);
if (error)
@@ -537,6 +540,7 @@ static int enter_state(suspend_state_t state)
Finish:
pr_debug("PM: Finishing wakeup.\n");
suspend_finish();
+ printk_emergency_end();
Unlock:
mutex_unlock(&pm_mutex);
return error;
--
2.12.2
[toc] | [prev] | [next] | [standalone]
| From | Petr Mladek <pmladek@suse.com> |
|---|---|
| Date | 2017-03-31 17:10 +0200 |
| Subject | Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places |
| Message-ID | <tr6lA-6eB-21@gated-at.bofh.it> |
| In reply to | #1611740 |
On Wed 2017-03-29 18:25:07, Sergey Senozhatsky wrote: > It's not always possible/safe to wake_up() printk kernel > thread. For example, late suspend/early resume may printk() > while timekeeping is not initialized yet, so calling into the > scheduler may result in recursive warnings. > > Another thing to notice is the fact PM at some point > freezes user space and kernel threads: freeze_processes() > and freeze_kernel_threads(), correspondingly. Thus we need > printk() to operate in old mode there and attempt to > immediately flush pending kernel message to the console. > > This patch adds printk_emergency_begin/on sections. > > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> It looks reasonable to me. Feel free to use: Reviewed-by: Petr Mladek <pmladek@suse.com> Well, it still would be great if people more familiar with this code look at it. Best Regards, Petr
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2017-04-06 19:30 +0200 |
| Subject | Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places |
| Message-ID | <ttjom-3R8-25@gated-at.bofh.it> |
| In reply to | #1611740 |
[Multipart message — attachments visible in raw view] — view raw
On Wed 2017-03-29 18:25:07, Sergey Senozhatsky wrote: > It's not always possible/safe to wake_up() printk kernel > thread. For example, late suspend/early resume may printk() > while timekeeping is not initialized yet, so calling into the > scheduler may result in recursive warnings. > > Another thing to notice is the fact PM at some point > freezes user space and kernel threads: freeze_processes() > and freeze_kernel_threads(), correspondingly. Thus we need > printk() to operate in old mode there and attempt to > immediately flush pending kernel message to the console. > > This patch adds printk_emergency_begin/on sections. > > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> I don't like this. It is symptom of printk getting much more fragile now. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | Andreas Mohr <andi@lisas.de> |
|---|---|
| Date | 2017-04-09 13:00 +0200 |
| Subject | Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places |
| Message-ID | <tuiJA-1J6-5@gated-at.bofh.it> |
| In reply to | #1618216 |
On Thu, Apr 06, 2017 at 07:20:52PM +0200, Pavel Machek wrote:
> On Wed 2017-03-29 18:25:07, Sergey Senozhatsky wrote:
> > It's not always possible/safe to wake_up() printk kernel
> > thread. For example, late suspend/early resume may printk()
> > while timekeeping is not initialized yet, so calling into the
> > scheduler may result in recursive warnings.
> >
> > Another thing to notice is the fact PM at some point
> > freezes user space and kernel threads: freeze_processes()
> > and freeze_kernel_threads(), correspondingly. Thus we need
> > printk() to operate in old mode there and attempt to
> > immediately flush pending kernel message to the console.
> >
> > This patch adds printk_emergency_begin/on sections.
> >
> > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>
> I don't like this. It is symptom of printk getting much more fragile
> now.
Sergey has mentioned it already:
"at some point freezes user space and kernel threads".
Well, this is the action which is *itself* causing thoroughly disrupting consequences,
which I'd think thus ought to be responsible to
ensure *itself* that all resulting consequences actually can be dealt with properly,
rather than having
weird *completely-unrelated-dependency* crap
("there happens to be some functionality called printk, and we need to bend it,
since we need to bend it, since otherwise it would not be bent" - ahem...)
leak into ("layer violation" keyword)
pm handling implementation specifics.
IOW, I would think that for any relevant kthread use in API user code,
such code ought to be able to
register kthread-API-provided callbacks (observer pattern, or whatever)
where the (back to current case:) printk kthread would then be able to
*implicitly*/*invisibly* switch the entire printk operation interface
(e.g. via a global interface struct) to
the "dumb"/"safe" fallback variant.
Potential interface: kthread_notify(callback_func, kthread_notification_type);
That way it could (hopefully) be ensured that
people could use a consistent "printk" *interface* universally regardless of which
"special" conditions happen to be in place at the moment.
(IOW, keep interface behaviour which is required/expected at user code
definitely isolated from
awkward "implementation aspects" necessity which is currently poisoning user code implementation).
Put differently,
handling preferrably ought to get consistently adapted (i.e., switched) *centrally*,
rather than
requiring weird helpers (printk_emergency_X()) at all user code sites.
...or so goes the theory.
(quite possibly such thoughts may hit roadblocks e.g. due to locking/atomicity issues)
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
[toc] | [prev] | [next] | [standalone]
| From | Petr Mladek <pmladek@suse.com> |
|---|---|
| Date | 2017-04-10 14:30 +0200 |
| Subject | Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places |
| Message-ID | <tuGCd-Cp-1@gated-at.bofh.it> |
| In reply to | #1619479 |
On Sun 2017-04-09 12:59:18, Andreas Mohr wrote:
> On Thu, Apr 06, 2017 at 07:20:52PM +0200, Pavel Machek wrote:
> > On Wed 2017-03-29 18:25:07, Sergey Senozhatsky wrote:
> > > It's not always possible/safe to wake_up() printk kernel
> > > thread. For example, late suspend/early resume may printk()
> > > while timekeeping is not initialized yet, so calling into the
> > > scheduler may result in recursive warnings.
> > >
> > > Another thing to notice is the fact PM at some point
> > > freezes user space and kernel threads: freeze_processes()
> > > and freeze_kernel_threads(), correspondingly. Thus we need
> > > printk() to operate in old mode there and attempt to
> > > immediately flush pending kernel message to the console.
> > >
> Sergey has mentioned it already:
> "at some point freezes user space and kernel threads".
> Well, this is the action which is *itself* causing thoroughly disrupting consequences,
> which I'd think thus ought to be responsible to
> ensure *itself* that all resulting consequences actually can be dealt with properly,
> rather than having
> weird *completely-unrelated-dependency* crap
> ("there happens to be some functionality called printk, and we need to bend it,
> since we need to bend it, since otherwise it would not be bent" - ahem...)
> leak into ("layer violation" keyword)
> pm handling implementation specifics.
> IOW, I would think that for any relevant kthread use in API user code,
> such code ought to be able to
> register kthread-API-provided callbacks (observer pattern, or whatever)
> where the (back to current case:) printk kthread would then be able to
> *implicitly*/*invisibly* switch the entire printk operation interface
> (e.g. via a global interface struct) to
> the "dumb"/"safe" fallback variant.
> Potential interface: kthread_notify(callback_func, kthread_notification_type);
Interesting idea. The power management area probably can be solved
by the existing notifiers framework, see register_pm_notifier().
I haven't checked it but if the notifiers are called on right
locations, it would be cleaner than adding the calls into
the pm code.
> That way it could (hopefully) be ensured that
> people could use a consistent "printk" *interface* universally regardless of which
> "special" conditions happen to be in place at the moment.
> (IOW, keep interface behaviour which is required/expected at user code
> definitely isolated from
> awkward "implementation aspects" necessity which is currently poisoning user code implementation).
> Put differently,
> handling preferrably ought to get consistently adapted (i.e., switched) *centrally*,
> rather than
> requiring weird helpers (printk_emergency_X()) at all user code sites.
Note that there already all many printk/console related "hacks"
in sensitive code paths. For example, see the use of
pm_prepare_console(), suspend_console(), console_level.
Best Regards,
Petr
[toc] | [prev] | [next] | [standalone]
| From | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> |
|---|---|
| Date | 2017-04-10 16:40 +0200 |
| Subject | Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places |
| Message-ID | <tuIE3-1UB-29@gated-at.bofh.it> |
| In reply to | #1619872 |
On (04/10/17 14:20), Petr Mladek wrote:
[..]
> > Sergey has mentioned it already:
> > "at some point freezes user space and kernel threads".
> > Well, this is the action which is *itself* causing thoroughly disrupting consequences,
> > which I'd think thus ought to be responsible to
> > ensure *itself* that all resulting consequences actually can be dealt with properly,
> > rather than having
> > weird *completely-unrelated-dependency* crap
> > ("there happens to be some functionality called printk, and we need to bend it,
> > since we need to bend it, since otherwise it would not be bent" - ahem...)
> > leak into ("layer violation" keyword)
> > pm handling implementation specifics.
> > IOW, I would think that for any relevant kthread use in API user code,
> > such code ought to be able to
> > register kthread-API-provided callbacks (observer pattern, or whatever)
> > where the (back to current case:) printk kthread would then be able to
> > *implicitly*/*invisibly* switch the entire printk operation interface
> > (e.g. via a global interface struct) to
> > the "dumb"/"safe" fallback variant.
> > Potential interface: kthread_notify(callback_func, kthread_notification_type);
>
> Interesting idea. The power management area probably can be solved
> by the existing notifiers framework.
good idea indeed.
wish we also had kexec and sysrq notifiers :) there is a
`panic_notifier_list', but that's not exactly what we need.
[..]
> > Put differently,
> > handling preferrably ought to get consistently adapted (i.e., switched) *centrally*,
> > rather than
> > requiring weird helpers (printk_emergency_X()) at all user code sites.
>
> Note that there already all many printk/console related "hacks"
> in sensitive code paths. For example, see the use of
> pm_prepare_console(), suspend_console(), console_level.
yep. I wonder if some of those can be moved to printk pm notifiers.
but that's out of the scope of this patch set.
-ss
[toc] | [prev] | [next] | [standalone]
| From | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> |
|---|---|
| Date | 2017-03-29 11:40 +0200 |
| Subject | [RFC][PATCHv2 7/8] printk: add printk emergency_mode parameter |
| Message-ID | <tqif8-4VF-39@gated-at.bofh.it> |
| In reply to | #1611720 |
This param permits user-space to forcibly on/off printk emergency
mode via /sys/module/printk/parameters/emergency_mode node.
We have annotated sections in the kernel that switch printk to
emergency, but there might be places/cases when user space would
want to have printk operate in emergency mode all the time.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
kernel/printk/printk.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1927b5cb5cbe..0d96839bb450 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -455,7 +455,7 @@ static struct task_struct *printk_kthread __read_mostly;
static atomic_t printk_emergency __read_mostly;
/*
* Disable printk_kthread permanently. Unlike `oops_in_progress'
- * it doesn't go back to 0.
+ * it doesn't go back to 0 (unless enforced by user-space).
*/
static bool printk_kthread_disabled __read_mostly;
@@ -483,6 +483,24 @@ void printk_emergency_end(void)
atomic_dec(&printk_emergency);
}
+static int printk_kthread_disabled_set(const char *val,
+ const struct kernel_param *kp)
+{
+ return param_set_bool(val, kp);
+}
+
+static const struct kernel_param_ops printk_kthread_disabled_ops = {
+ .set = printk_kthread_disabled_set,
+ .get = param_get_bool,
+};
+
+module_param_cb(emergency_mode,
+ &printk_kthread_disabled_ops,
+ &printk_kthread_disabled,
+ 0644);
+MODULE_PARM_DESC(emergency_mode,
+ "don't offload message printing to printk kthread");
+
/* Return log buffer address */
char *log_buf_addr_get(void)
{
--
2.12.2
[toc] | [prev] | [next] | [standalone]
| From | Petr Mladek <pmladek@suse.com> |
|---|---|
| Date | 2017-04-03 17:30 +0200 |
| Subject | Re: [RFC][PATCHv2 7/8] printk: add printk emergency_mode parameter |
| Message-ID | <tsc5z-cE-1@gated-at.bofh.it> |
| In reply to | #1611741 |
On Wed 2017-03-29 18:25:10, Sergey Senozhatsky wrote:
> This param permits user-space to forcibly on/off printk emergency
> mode via /sys/module/printk/parameters/emergency_mode node.
>
> We have annotated sections in the kernel that switch printk to
> emergency, but there might be places/cases when user space would
> want to have printk operate in emergency mode all the time.
Thanks a lot for the parameter.
> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> ---
> kernel/printk/printk.c | 20 +++++++++++++++++++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 1927b5cb5cbe..0d96839bb450 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -455,7 +455,7 @@ static struct task_struct *printk_kthread __read_mostly;
> static atomic_t printk_emergency __read_mostly;
> /*
> * Disable printk_kthread permanently. Unlike `oops_in_progress'
> - * it doesn't go back to 0.
> + * it doesn't go back to 0 (unless enforced by user-space).
> */
> static bool printk_kthread_disabled __read_mostly;
>
> @@ -483,6 +483,24 @@ void printk_emergency_end(void)
> atomic_dec(&printk_emergency);
> }
>
> +static int printk_kthread_disabled_set(const char *val,
> + const struct kernel_param *kp)
> +{
> + return param_set_bool(val, kp);
> +}
> +
> +static const struct kernel_param_ops printk_kthread_disabled_ops = {
> + .set = printk_kthread_disabled_set,
> + .get = param_get_bool,
> +};
> +
> +module_param_cb(emergency_mode,
> + &printk_kthread_disabled_ops,
> + &printk_kthread_disabled,
> + 0644);
> +MODULE_PARM_DESC(emergency_mode,
> + "don't offload message printing to printk kthread");
I wonder if we could make this easier. Something like:
static bool printk_force_emergency;
module_param_named(force_emergency, printk_force_emergency,
bool, S_IRUGO | S_IWUSR);
and use it instead of printk_kthread_disabled variable. It was
confusing anyway. You already mentioned that it did not
stop the kthread.
Also the relation between the sysfs entry and printk code
will be cleaner. People might thing that emergency_mode
shows the immediate value of printk_emergency variable.
Best Regards,
Petr
[toc] | [prev] | [next] | [standalone]
| From | Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> |
|---|---|
| Date | 2017-04-04 10:30 +0200 |
| Subject | Re: [RFC][PATCHv2 7/8] printk: add printk emergency_mode parameter |
| Message-ID | <tss0G-2lg-9@gated-at.bofh.it> |
| In reply to | #1615320 |
On (04/03/17 17:29), Petr Mladek wrote: [..] > > +module_param_cb(emergency_mode, > > + &printk_kthread_disabled_ops, > > + &printk_kthread_disabled, > > + 0644); > > +MODULE_PARM_DESC(emergency_mode, > > + "don't offload message printing to printk kthread"); > > I wonder if we could make this easier. Something like: > > static bool printk_force_emergency; > module_param_named(force_emergency, printk_force_emergency, > bool, S_IRUGO | S_IWUSR); yes, can do. thanks. > and use it instead of printk_kthread_disabled variable. It was > confusing anyway. You already mentioned that it did not > stop the kthread. yeah, I didn't like the `printk_kthread_disabled' naming, but at the same time didn't feel like having `printk_emergency' and `printk_forced_emergency'. will take a look. -ss
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | linux.kernel
csiph-web