linux-kernel - Re: [RFC][PATCH 1/4] printk: introduce printing kernel thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170323051242.GE2519@jagdpanzerIV.localdomain>
Date:   Thu, 23 Mar 2017 14:12:42 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Jan Kara <jack@...e.cz>
Subject: Re: [RFC][PATCH 1/4] printk: introduce printing kernel thread

On (03/22/17 17:40), Petr Mladek wrote:
[..]
> > +void console_printing_thread_off(void)
> > +{
> > +	printk_kthread_disable++;
> > +	barrier();
> > +}
> > +
> > +/* This re-enables printk_kthread offloading. */
> > +void console_printing_thread_on(void)
> > +{
> > +	barrier();
> > +	printk_kthread_disable--;
> > +}
> 
> I really like that these functions are re-entrant. It will make
> our life much easier.
>
> Just a small nitpicking. I would prefer to use the name
> console_printk_kthread_off()/on(). I was several times confused
> by "printing_thread" when searching the sources. The common
> sub-string "printk_kthread" for all the related stuff would
> make my life easier ;-)

well, I guess I can rename it.

one observation here is that those functions neither turn off nor
disable printk_kthread. we mark the point after which we will not
wake_up printk_kthread, but that does not mean that printk_kthread
is already or soon will be inactive. it actually can be in running
state. so the name

console_do_not_offload_printing_to_printk_kthread_unless_its_already_running()

will describe it better.  :)

---

overall the whole need of off()/on() sections is slightly worrisome.
there are probably not so many cases when we need to forcibly avoid
wake_up(printk_kthread) calls, but we don't have any checks/mechanisms
to verify it (like, for example, might_sleep()). so it's case by case.

> Just an idea. printk() and printk_deferred() behave the same way
> when the kthread is enabled. I wonder if we should make it more
> explicit by using names like:
> 
>    printk_deferred_mode_disabled++;
>    printk_deferred_mode_off();
>    printk_deferred_mode_on();

hm, I certainly see what you meant here, but I suspect this naming may
be a bit misleading - "so printk_deferred_mode_off() disables printk_deferred()?"

> Also it is an already know term and a more generic name. This API
> is used globally while the kthread is an implementation detail.
> The offloading might be done another way in the future.

yes, this is why I avoided mentioning "printk_kthread" (directly)
in API naming. console_printing_thread is sort of neutral (well,
sort of). not insisting that the naming is perfect, of course.

> Finally, I think about using this variable instead of the ugly
> LOGLEVEL_SCHED. The catch is that LOGLEVEL_SCHED forces
> the deferred mode while these functions force the opposite.

hm, sorry. not sure I see how we can do this.
LOGLEVEL_SCHED hack is... hacky. yes.

when we examine `printk_kthread_disable' we decide wether we must
	a) wake_up() printk_kthread
or
	b) do console_trylock()

the LOGLEVEL_SCHED thing is completely different tho. it tells us that
neither of the above is safe -- both wake_up() and console_trylock()
can potentially call into the scheduler. so I'm not sure we can easily
replace LOGLEVEL_SCHED with `printk_kthread_disable'.

	-ss