Re: v4.4-rc1: /dev/console open fails with -EIO

["bhe@redhat.com" <bhe@redhat.com>]

Hi Junichi,

A little earlier Peter Hurley has posted a patch to fix this problem.
https://lkml.org/lkml/2015/11/27/546

It may be found firstly on arm by Pratyush Anand <panand@redhat.com>.
I found it too this week on Fedora 23.

Anyway, it's great problem has been fixed very quickly. Just reply to
let you know this.

Thanks
Baoquan

On 12/16/15 at 06:32am, Junichi Nomura wrote:
> Since kernel v4.4-rc1, kdump capture service with Fedora23 / RHEL7.2
> almost always fails on my test system which uses serial console. It
> used to work fine until kernel v4.3.
> 
> Kdump fails with an error like this:
>   kdump.sh[1040]: /bin/kdump.sh: line 8: /dev/console: Input/output error
> 
> The line 8 of kdump.sh is doing this:
>   exec &> /dev/console
> (http://pkgs.fedoraproject.org/cgit/kexec-tools.git/tree/dracut-kdump.sh)
> 
> and the EIO is returned by this code in tty_reopen():
>         if (!tty->count)
>                 return -EIO;
> 
> Bisection tells that commit 79c1faa4511e ("tty: Remove
> tty_wait_until_sent_from_close()") is the first bad commit.
> Actually, after reverting the commit, kdump capture starts working
> again.
> 
> Open of /dev/console used to return -EIO when it races with close.
> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554172/comments/245)
> But the commit seems widening the race window.
> 
>   Before the commit:
>     tty_release()
>       tty_lock(tty)
>       tty->ops->close(tty, filp)
>         tty_unlock(tty)
>         tty_wait_until_sent()
>         // the window starts from here
>         tty_lock(tty)
>       decrement tty->count
>       tty_unlock(tty)
>       (releasing tty if count became zero)
> 
>   After the commit
>     tty_release()
>       // the window starts from here
>       tty_lock(tty)
>       tty->ops->close(tty, filp)
>         tty_wait_until_sent()
>       decrement tty->count
>       tty_unlock(tty)
>       (releasing tty if count became zero)
> 
> While it might be possible for user space to cope with the problem
> by retrying open(), there is no clue whether and how long it should.
> Also current situation makes shell scripting like the above kdump.sh
> fragile for this sort of timing change.
> 
> How about retrying tty_open in kernel instead, like the attached patch?
> If !tty->count in tty_reopen() means the race has happened, that
> seems reasonable.
> 
> ---
> Jun'ichi Nomura, NEC Corporation
> 
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index bcc8e1e..070ea66 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -1462,8 +1462,9 @@ static int tty_reopen(struct tty_struct *tty)
>  {
>  	struct tty_driver *driver = tty->driver;
>  
> +	/* We cannot re-open tty which is being released. */
>  	if (!tty->count)
> -		return -EIO;
> +		return -ERESTARTSYS;
>  
>  	if (driver->type == TTY_DRIVER_TYPE_PTY &&
>  	    driver->subtype == PTY_TYPE_MASTER)
> @@ -2087,6 +2088,11 @@ retry_open:
>  
>  	if (IS_ERR(tty)) {
>  		retval = PTR_ERR(tty);
> +		if (retval == -ERESTARTSYS && !signal_pending(current)) {
> +			tty_free_file(filp);
> +			schedule();
> +			goto retry_open;
> +		}
>  		goto err_file;
>  	}
>