mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Samo Pogačnik" <samo_pogacnik@t-2.net>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>
Cc: Petr Mladek <pmladek@suse.com>,
	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>
Subject: Re: How to handle concurrent access to /dev/ttyprintk ?
Date: Wed, 14 Apr 2021 18:15:23 +0200	[thread overview]
Message-ID: <31a4dec3d36ed131402244693cae180816ebd4d7.camel@t-2.net> (raw)
In-Reply-To: <095d5393-b212-c4d8-5d6d-666bd505cc3d@i-love.sakura.ne.jp>

Dne 14.04.2021 (sre) ob 20:11 +0900 je Tetsuo Handa napisal(a):
> On 2021/04/14 9:45, Tetsuo Handa wrote:
> > On 2021/04/12 21:04, Greg Kroah-Hartman wrote:
> > > > Since syzkaller is a fuzzer, syzkaller happily opens /dev/ttyprintk from
> > > > multiple threads. Should we update syzkaller to use CONFIG_TTY_PRINTK=n
> > > > ?
> > > 
> > > Why?  Can you not hit the same tty code paths from any other tty driver
> > > being open multiple times?  Why is ttyprintk somehow "special" here?
> > 
> > I found a simplified reproducer. If we call ioctl(TIOCVHANGUP) on
> > /dev/ttyprintk ,
> > "struct ttyprintk_port tpk_port".port.count cannot be decremented by
> > tty_port_close() from tpk_close() due to tty_hung_up_p() == true when
> > close() is called. As a result, tty->count and port count gets out of sync.
> > 
> > Then, when /dev/ttyprintk is opened again and then closed without calling
> > ioctl(TIOCVHANGUP), this message is printed due to tty_hung_up_p() == false.
> > 
> > If I replace /dev/ttyprintk with /dev/ttyS0 in the reproducer shown above,
> > this message is not printed.
> > 
> 
> The difference between /dev/ttyS0 and /dev/ttyprintk is that
> the former provides uart_hangup() as "struct tty_operations"->hangup
> while the latter does not provide "struct tty_operations"->hangup .
> 
> It seems to me that below patch avoids this message, but I'm not familiar
> with tty code. Is this fix correct? Don't we need to enforce all drivers
> to provide "struct tty_operations"->hangup in order to reset port count ?
> 
> diff --git a/drivers/char/ttyprintk.c b/drivers/char/ttyprintk.c
> index 6a0059e508e3..ff3b9a41b91b 100644
> --- a/drivers/char/ttyprintk.c
> +++ b/drivers/char/ttyprintk.c
> @@ -158,12 +158,26 @@ static int tpk_ioctl(struct tty_struct *tty,
>  	return 0;
>  }
>  
> +/*
> + * TTY operations hangup function.
> + */
> +static void tpk_hangup(struct tty_struct *tty)
> +{
> +	struct ttyprintk_port *tpkp = tty->driver_data;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&tpkp->port.lock, flags);
> +	tpkp->port.count = 0;
> +	spin_unlock_irqrestore(&tpkp->port.lock, flags);
> +}
> +
>  static const struct tty_operations ttyprintk_ops = {
>  	.open = tpk_open,
>  	.close = tpk_close,
>  	.write = tpk_write,
>  	.write_room = tpk_write_room,
>  	.ioctl = tpk_ioctl,
> +	.hangup = tpk_hangup,
>  };
>  
>  static const struct tty_port_operations null_ops = { };

Wish i could be of more help here, especially around locking.

If this addition is needed, i'd probably do something similar.
However, when comparing the code around other drivers it seems that
'tty_port_hangup()' should be used instead explicit 'port.count'
reset.

best regards, Samo



  reply	other threads:[~2021-04-14 16:16 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-03  4:14 [PATCH] tty: use printk_safe context at tty_msg() Tetsuo Handa
2021-04-03  6:52 ` kernel test robot
2021-04-03 10:11   ` [PATCH] printk: Make multiple inclusion of kernel/printk/internal.h safe Tetsuo Handa
2021-04-06  4:51 ` [PATCH] tty: use printk_safe context at tty_msg() Jiri Slaby
2021-04-06  5:31   ` Tetsuo Handa
2021-04-06  7:10     ` Greg Kroah-Hartman
2021-04-06 11:16       ` Tetsuo Handa
2021-04-06 13:42         ` Greg Kroah-Hartman
2021-04-06 15:10 ` Petr Mladek
2021-04-06 16:22   ` Tetsuo Handa
2021-04-06 19:10     ` Greg Kroah-Hartman
2021-04-07  9:20       ` Petr Mladek
2021-04-07 13:26     ` [PATCH v2] tty: use printk_deferred() " Tetsuo Handa
2021-04-07 13:48       ` Greg Kroah-Hartman
2021-04-07 14:24         ` Tetsuo Handa
2021-04-12 10:39           ` How to handle concurrent access to /dev/ttyprintk ? Tetsuo Handa
2021-04-12 10:44             ` Greg Kroah-Hartman
2021-04-12 11:25               ` Tetsuo Handa
2021-04-12 12:04                 ` Greg Kroah-Hartman
2021-04-14  0:45                   ` Tetsuo Handa
2021-04-14 11:11                     ` Tetsuo Handa
2021-04-14 16:15                       ` Samo Pogačnik [this message]
2021-04-15  0:22                         ` [PATCH] ttyprintk: Add TTY hangup callback Tetsuo Handa
2021-04-18 11:16                           ` Samo Pogačnik
2021-04-22 10:02                             ` Greg Kroah-Hartman
2021-04-23  4:22                             ` Jiri Slaby
2021-04-23  9:55                               ` Samo Pogačnik
2021-04-23 10:12                                 ` Tetsuo Handa
2021-04-23 19:47                                   ` Samo Pogačnik
2021-04-24  1:16                                     ` Tetsuo Handa
2021-04-24  9:57                                       ` Samo Pogačnik
2021-04-26 10:00                                         ` Petr Mladek
2021-04-26 16:42                                           ` Samo Pogačnik
2021-04-27 10:08                                             ` Petr Mladek
2021-04-27 11:31                                               ` Samo Pogačnik
2021-04-23 10:28                                 ` Jiri Slaby
2021-04-23 12:23                                   ` [PATCH] ttyprintk: Add TTY port shutdown callback Samo Pogačnik
2021-04-12 12:41             ` How to handle concurrent access to /dev/ttyprintk ? Samo Pogačnik
2021-04-13  9:41               ` Petr Mladek
2021-04-13 11:10                 ` Samo Pogačnik
2021-04-13 14:32                   ` Petr Mladek
2021-04-13 15:22                     ` Samo Pogačnik
2021-04-14 17:36                       ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=31a4dec3d36ed131402244693cae180816ebd4d7.camel@t-2.net \
    --to=samo_pogacnik@t-2.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®