On 2020/05/13 21:19, Petr Mladek wrote: > On Wed 2020-05-13 20:24:24, Tetsuo Handa wrote: >> On 2020/05/13 19:49, Michal Hocko wrote: >>> On Wed 13-05-20 12:04:13, Petr Mladek wrote: >>>> What is so special about OOM dump task so that it would deserve such >>>> complications? > >> I don't think dump_tasks() is important information to be printed on >> consoles. >> But since somebody might think dump_tasks() is important information to be >> printed on consoles, I suggest switching KERN_NO_CONSOLES using e.g. sysctl. > > You might achieve the same with DEBUG loglevel. Or do I miss anything?
Use of KERN_DEBUG affects userspace syslog daemon. We will have to ask administrators to configure syslog daemon not to filter KERN_DEBUG messages. And administrators will be bothered by needless KERN_DEBUG messages. Also, > > [*] It will have no effect when it was disabled by a sysfs knob. we will have to ask people to "don't make pr_debug() no-op" or "use KERN_DEBUG instead of pr_debug()". Your suggestion to change KERN_$LOGLEVEL keeps bothering people. That's bad. > I know that it is meant as a modifier, like LOGLEVEL_SCHED and > KERN_CONT. Right. KERN_NO_CONSOLES is a modifier. > But this is another reason to avoid it. We already have > huge pain with these two modifiers. They both do not work well. KERN_NO_CONSOLES can not cause pains like LOGLEVEL_SCHED because KERN_NO_CONSOLES is to say "no need to call console drivers" while LOGLEVEL_SCHED is to say "don't call console drivers now but have to call console drivers later". On 2020/05/13 21:34, Petr Mladek wrote: > On Wed 2020-05-13 20:03:53, Tetsuo Handa wrote: >> On 2020/05/13 19:04, Petr Mladek wrote: >>>> What is wrong with adding NO_CONSOLES ? >>> >>> How does it differ from KERN_DEBUG? The debug messages: >>> >>> + can be disabled via sysfs >>> + might reach console when this loglevel is enabled >> >> KERN_NO_CONSOLES is different from KERN_DEBUG in that KERN_NO_CONSOLES >> itself does not affect userspace daemon's judgement (whether to filter >> KERN_$LOGLEVEL messages). > > And that is the evil thing about it. It goes around the loglevel > filtering. > > The administrator wants to decide what messages are important for him. Right. > NO_CONSOLES would mess with this decision. Some messages would suddenly > get hidden on console but appear in userspace. Wrong. Console loglevel is already hiding some messages. > Users would need to > investigate what the hell is happening. They would need to find the > new sysfs knob to restore the expected behavior, etc. That's part of deciding what messages are important for him, as well as deciding what KERN_$LOGLEVEL messages are worth printing to consoles.
