Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <625994732c8eda9f36320192fb991cf89b5c1fa9.camel@t-2.net>
Subject: Re: [PATCH] ttyprintk: Add TTY hangup callback.
From:   Samo =?UTF-8?Q?Poga=C4=8Dnik?= <samo_pogacnik@t-2.net>
To:     Petr Mladek <pmladek@suse.com>
Cc:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        Jiri Slaby <jirislaby@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        John Ogness <john.ogness@linutronix.de>,
        linux-kernel@vger.kernel.org,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Date:   Tue, 27 Apr 2021 13:31:30 +0200
In-Reply-To: <YIfiiGVJqkWV/IDa@alley>
References: <17e0652d-89b7-c8c0-fb53-e7566ac9add4@i-love.sakura.ne.jp>
         <8043d41d48a0f4f13bd891b4c3e9ad28c76b430e.camel@t-2.net>
         <699d0312-ee68-8f05-db2d-07511eaad576@kernel.org>
         <ba5907e12a30ed8eb3e52a72ea84bf4f72a4c801.camel@t-2.net>
         <33461bad-ef57-9036-135d-95a60a8c88d5@i-love.sakura.ne.jp>
         <07c3c9015491ca9b42362098d5e90ca7480cf5ed.camel@t-2.net>
         <e7010c9e-1ac2-55a7-b505-802e03f13362@i-love.sakura.ne.jp>
         <9e8805a98d6c0d0f20e563c8e4db98b595826c13.camel@t-2.net>
         <YIaPQzktArmoWbLr@alley>
         <d4d0603716e5cb99a7a9a93d4f767278ac318557.camel@t-2.net>
         <YIfiiGVJqkWV/IDa@alley>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Dne 27.04.2021 (tor) ob 12:08 +0200 je Petr Mladek napisal(a):
> 
> I guess that you mean TPK_PREFIX + "[U] ".
yes

> 
> But you could do this already in tpk_write(). I mean that you could
> parse the given buffer, copy each line to a temporary buffer,
> and call printk(TPK_PREFIX "[U] %s\n", tmp_buf).
> 
> Why is it postponed to tpk_close()?
> 
> IMHO, the printk() in tpk_write() might simplify the logic a bit.
The string received in tpk_write() has no guaranties, that it represents a
complete output line. It has to be treated as a sub-string of a potentially
multi-line massage produced by the userspace code/process. 

The tpk_close() only produces additional output (flush), if the last tpk_write()
string does not end with some end-of-line indication.

> 
> 
> > > 
> > > If you call printk() directly, the caller_id would be from the process
> > > that really wrote the data/message.
> > 
> > It can be a kernel-code originating message printk-ed on behalf of a user
> > task
> > or a kernel-code originating message on behalf of a kernel task. Or it may
> > be a
> > user-code originating message on behalf of its task, when printk-ed via
> > ttyprintk.
> 
> Exactly. Now, I am not sure if you think that this good or bad.
> 
> IMHO, it is much better to use caller_id of the process/context that
> wrote the data/message instead of the process that caused the final
> tpk_close().
> 
IMHO, it is good that output provides info about all the above cases and
especially that particular output is not produced by the kernel code itself.

best regards, samo