[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151216142346.GA3187@x1.redhat.com>
Date: Wed, 16 Dec 2015 22:23:46 +0800
From: "bhe@...hat.com" <bhe@...hat.com>
To: Junichi Nomura <j-nomura@...jp.nec.com>
Cc: "peter@...leysoftware.com" <peter@...leysoftware.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"jslaby@...e.com" <jslaby@...e.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
panand@...hat.com
Subject: Re: v4.4-rc1: /dev/console open fails with -EIO
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@...hat.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;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists